rcompat - JavaScript interoperability and runtime compatibility layer for servers

[upbeat cradle]

for the whatwg http wrapper for node, @whatwg-node/server already exists and well-established

[delicate drift]

node.js too...

[upbeat cradle]

wdym "env"?

nodejs has --env-file

[delicate drift]

and process.loadEnv(".env") too

[upbeat cradle]

the only thing node is lacking is whatwg web server

honestly

https://github.com/rcompat/rcompat/blob/master/packages/fs/src/node/text.ts

here u use fs/promises which is slow

u should use readFileSync

ok?

ok blue

u won 🤠

https://github.com/rcompat/rcompat/blob/master/packages/fs/src/bun/json.ts

why u make this unknown not any

did u do it in other modules too

if yes, i'm too tired to do more than 1 xd

https://github.com/rcompat/rcompat/pull/28

[wide forge]

1 simple reason: performance
If you know what you are doing, writting your own implementations for each runtime will beat any type of wrapper

Leightweight means nothing when it comes to performance, + abstractions are not needed when doing things by hand yourself, and the moment you are against code duplication without even exploring what it trully means just shows how little you really care about performance in this scenarios.
And no, before you think something wrong, this is not an attack on your project, i think things like this are good for people who are just bad/new programmers but you asked for a reason and i gave you one with enphasis on "if they know what they are doing"

It is realistic because majority of projects do not care about this issue, and jquery only existed because of microsoft being stupid with IE, but i digress

If its a lib yes, if its a personal project idk its preference

Bun does not work in some systems... and some people just want to for whatever reason

[last nimbus]

I think rcompat is a good solution

[flint ivy]

[upbeat cradle]

what is the "r"

i think recompat is nicer

ok

[lost hearth]

Imagine you want to support Node, Deno and Bun
no
bun? yes
node? ok, sure maybe
deno? hell nah get out

[delicate drift]

Based

[lost hearth]

well, ask didas 😄

they decided to invent deno after calling node a failure, why now it should be my responsibility to support it exclusively

not my fault that they made the mistake

it's like if you shot someone then I got to the prison for your mistake

[lost hearth]

considering deno is not even any better nor that much different, even uses the same JS engine so they did almost nothing

just different API

[upbeat cradle]

oh man you're a hater just like me frfr

[lost hearth]

when it comes to deno yes I don't like it

[upbeat cradle]

yes because its shallow to node

i agree

[lost hearth]

v8 API is just garbage

so they can't do much

and need to use JS/weird stuff

while bun just uses JSC

[upbeat cradle]

ryan doesn't even maintain deno anymore too

xd

[lost hearth]

trol

so they're just gone?

[upbeat cradle]

he just makes presentations on youtube

about deno and jsr and deploy deploy and shit

but doesn't actually code

[lost hearth]

jsr, why does it even exist

[wide forge]

To brainrot who doesnt know better

[lost hearth]

lol

[upbeat cradle]

pov i wanted to upvote him and i can't react to his message because he blocked me

emotional 🙏

[lost hearth]

sure, if I pay no further runtime checks I'd take it

https://github.com/rcompat/rcompat/blob/04e6e0153e5fded344484919acb652a51898f699/packages/http/src/bun/serve.ts#L9 why not just fetch: handler

[unique lion]

serve.ts — (L9-L9)

    fetch: request => handler(request),

[lost hearth]

(well, only the this binding and maybe if bun passes more args would change)