It’s not really surprising that using node ecosystem from deno is hard. Idealistically (but maybe not maximally practically) deno initially set to create a different, better ecosystem.
But, if you are in “dependencies are generally a liability” camp, you probably will find deno production ready at this point, and quite delightful. I’ve recently migrated my blog from Jekyll to a hand-written deno script, and deno does seem like a dependable scripting environment, something that “Python as a glue language” should have been.
Speaking for myself, I find the compile step from TypeScript to JavaScript a frequent source of friction in Node projects. I appreciate working in an environment that handles that for me in a way that feels as if I’m running my TypeScript directly. Subjectively, I’ve also found that it tends lives up to its performance claims of being faster than Node when, for example, reading large amounts of data from disk or over a network.
I really like Deno, but I think they made a mistake chasing full NPM compatibility.
Now to be considered ‘primetime’ or ‘production ready’ they have to beat Node at its own game, i.e. running Node packages.
They should stick with what make Deno so appealing: a JS runtime and ecosystem with none of the baggage of Node and the same ecosystem and conventions as browsers.
The appeal of JavaScript at this point is not the browser, but a huuuge ecosystem. Any runtime missing that, creating their own and trying to fragment this will fail I think. I also hope it will happen, because a less nice, but hugely compatible ecosystem I think is way better than lots of small neat languages and ecosystems.
When I hear people talk about what they hate about JavaScript, my feeling is that most of the time they’re actually talking about things they hate about Node and NPM. The NPM ecosystem is a tooling miasma resulting from the mixed CommonJS and ESM ecosystem, and a conflation of the Node runtime with JavaScript in general.
One of the absolute best things about Deno is getting that out of your hair.
Yeah, I found Deno very exciting because it sounded like the benefits of JS/TS without all the NPM crap (YMMV, I’ve stayed away from it for years, for reasons). Now it’s a bit muddled and I can see the same things happening again.
It’s not really surprising that using node ecosystem from deno is hard. Idealistically (but maybe not maximally practically) deno initially set to create a different, better ecosystem.
But, if you are in “dependencies are generally a liability” camp, you probably will find deno production ready at this point, and quite delightful. I’ve recently migrated my blog from Jekyll to a hand-written deno script, and deno does seem like a dependable scripting environment, something that “Python as a glue language” should have been.
What can Deno do in term of dependency packaging that a docker container can’t do?
Work without docker?
I am definitely in this camp. Can you elaborate on why I will like Deno?
Sadly, this text area is a bit too small for this, so
https://matklad.github.io/2023/02/12/a-love-letter-to-deno.html
:)
My guy I beg you to left-align your text on your blog. Full width justification is frustrating to read.
Reads fine to me.
I will consider doing that after browsers ship Kunth-Plass or otherwise fix horrible line breaking.
Speaking for myself, I find the compile step from TypeScript to JavaScript a frequent source of friction in Node projects. I appreciate working in an environment that handles that for me in a way that feels as if I’m running my TypeScript directly. Subjectively, I’ve also found that it tends lives up to its performance claims of being faster than Node when, for example, reading large amounts of data from disk or over a network.
The magic of Deno is being able to start a programming in Typescript by creating a single .ts file.
It has a built in formatter, LSP, test runner, and benchmarking system. It has all the web APIs like
fetchbuilt in without having to polyfill them.As of node 18, node finally has fetch too.
That is good, and the work the unidici team is doing is great. But
fetchis just one item in a long list of Web APIs these kinds of runtimes can support: https://deno.land/manual@v1.30.3/runtime/web_platform_apisI really like Deno, but I think they made a mistake chasing full NPM compatibility.
Now to be considered ‘primetime’ or ‘production ready’ they have to beat Node at its own game, i.e. running Node packages.
They should stick with what make Deno so appealing: a JS runtime and ecosystem with none of the baggage of Node and the same ecosystem and conventions as browsers.
The appeal of JavaScript at this point is not the browser, but a huuuge ecosystem. Any runtime missing that, creating their own and trying to fragment this will fail I think. I also hope it will happen, because a less nice, but hugely compatible ecosystem I think is way better than lots of small neat languages and ecosystems.
Speak for yourself! 😄
When I hear people talk about what they hate about JavaScript, my feeling is that most of the time they’re actually talking about things they hate about Node and NPM. The NPM ecosystem is a tooling miasma resulting from the mixed CommonJS and ESM ecosystem, and a conflation of the Node runtime with JavaScript in general.
One of the absolute best things about Deno is getting that out of your hair.
Yeah, I found Deno very exciting because it sounded like the benefits of JS/TS without all the NPM crap (YMMV, I’ve stayed away from it for years, for reasons). Now it’s a bit muddled and I can see the same things happening again.