51–60 of 235 posts
Is it just a side-effect of using V8 engine for the heavy lifting, or is it some part of the ECMAScript specification which forbids multithreaded implementations of the language?
Interestingly, Deno and Node were both originally developed by the same person, Ryan Dahl. Why did he feel the need to build a competitor to his own product? Whatever features are supposed to make Deno "better" than Node...why didn't he just work on integrating them into Node? I understand that sometimes changes to software can be infeasible, especially if they are large fundamental/foundational changes, but this is…
Sometimes you do need to reset the foundations, then build compatibility on top.
Earlier quoted context omitted.
> If node.js decided to include functionality similar to what is available on Bun/Deno, both projects would probably lose traction quickly. I believe this too. The big appeal for me is not having to install typescript, eslint, jest AND then set up all the configs. deno has nice defaults, though the importing via URLS and browser compatible API do make deno very tempting
that feels like a really weak value prop to me. how often do you have to install that stuff? how hard is it actually? can you really not use, e.g. for react, the typical vite starter and it's done?
Whereas with Deno you can compile to a single binary and let them install that if they trust you. Or they can `deno install https://raw.githubusercontent.com/.../cli.ts`, or clone the repo and just run `deno task install` or `deno task run`. For those they need to install Deno, but nothing else.
Would love to see the compile situation fixed - the generated executables are ~90MB+ at this stage and do now allow compression without erroring out. Deploying ala Golang is not feasible at that level but could well be down the line if this dev branch is picked up again! The exe output grew from from ~50MB to plus ~90MB from 2021 to 2024: https://github.com/denoland/deno/discussions/9811 which mean Deno is worse than…
If you really are pressed for space, you could use upx, or store 7z compressed code and embed the 7z library to decompress before passing it along to QuickJS.
Here's a proof of concept: https://github.com/ijustlovemath/jescx
It is interesting to me that none of the new NodeJS alternatives support multithreading. Why is that? Is it just a side-effect of using V8 engine for the heavy lifting, or is it some part of the ECMAScript specification which forbids multithreaded implementations of the language?
Interestingly, Deno and Node were both originally developed by the same person, Ryan Dahl. Why did he feel the need to build a competitor to his own product? Whatever features are supposed to make Deno "better" than Node...why didn't he just work on integrating them into Node? I understand that sometimes changes to software can be infeasible, especially if they are large fundamental/foundational changes, but this is…
He also can't unilaterally change them in NodeJS because at that point it wasn't a solo project of his anymore.
Would love to see the compile situation fixed - the generated executables are ~90MB+ at this stage and do now allow compression without erroring out. Deploying ala Golang is not feasible at that level but could well be down the line if this dev branch is picked up again! The exe output grew from from ~50MB to plus ~90MB from 2021 to 2024: https://github.com/denoland/deno/discussions/9811 which mean Deno is worse than…
While I agree with you that it's not optimal and should get fixed, 90MB doesn't sounds like it can stop you from deploying it either.
Interestingly, Deno and Node were both originally developed by the same person, Ryan Dahl. Why did he feel the need to build a competitor to his own product? Whatever features are supposed to make Deno "better" than Node...why didn't he just work on integrating them into Node? I understand that sometimes changes to software can be infeasible, especially if they are large fundamental/foundational changes, but this is…
You can join the waitlist in the sneak peak of JSR linked in the end of the article: https://jsr.io/waitlist I'm curious on what the Deno team is building here.
I have a deno app in production and it is working just fine. However, I still think node is superior when you self host when you are not using docker. Deno afaik still doesn't support any way of running one process for every CPU like the cluster module in Node.js. I like to run my shit on the metal and without Docker and it feels like Deno was designed to run on Docker or some other kind of virtual containerized envi…
OTOH Deno can produce self-contained binaries. For me this is a plus, it makes distribution so much easier. I don't care if it's 100MB, I just want to have one file which I can throw on my server,