71–80 of 112 posts
I do wonder about the long-term effects of Deno being Node-compatible; will it result in only Node programming being done since "Deno will handle it fine" and thus Deno specific stuff will not be developed?
Deno supports typescript out of the box. This alone greatly simplifies any deployment, and even if Deno did not offered anything else it would already take the lead in developer experience.
Earlier quoted context omitted.
Nodejs is the de facto platform and ecosystem to write JS backend, and it seemed to me a bit weird that one would want to compete with it without being compatible with it which meant throwing away the very large ecosystem and existing code bases with no good reasons if you wanted to migrate. So congrats to them to have made it now, Deno can still compete on speed or tooling for example. Good Deno ideas will indeed pr…
> can someone explain why it's a good idea to have isolation at the interpreter level rather than relying on OS features? (or VMs). Those technologies are platform-specific and difficult to use. For example, provide the command line for running a Node.js program in Linux without file system access. In deno, it's deno run main.ts Or, to enable fs access: deno run --allow-read --allow-write main.ts --- That said, I agr…
> docker run -it --rm -v "$PWD":/app -w /app node:18 node main.js
It's a tad longer but it's more flexible too ;)
Earlier quoted context omitted.
I think you can analogize these server JS runtimes (Node, Deno) to browser runtimes (V8, JavaScriptCore, SpiderMonkey) and to the APIs that ship with those. When one browser JS engine invents and exposes a novel feature + API surface for it that the other engines don't, what happens? If there's any demand at all for doing what the feature does, then devs will tend to write polyfills to make the feature "work" (for so…
Having a feature is not the same thing as having API compatibility with Node's implementation of the feature. I think people are worried that an exciting project that aimed to have a different approach and a different set of trade-offs from Node will end up having to support everything that Node does, possibly inheriting its trade-offs and losing the freedom to innovate that they started with. Even if there's no tech…
It doesn't mean the application at its core will be more node based so much as wanting to be able to use a given NPM module.
I do wonder about the long-term effects of Deno being Node-compatible; will it result in only Node programming being done since "Deno will handle it fine" and thus Deno specific stuff will not be developed?
> and thus Deno specific stuff will not be developed? Deno supports typescript out of the box. This alone greatly simplifies any deployment, and even if Deno did not offered anything else it would already take the lead in developer experience.
Slowly Deno is just becoming Node written in Rust with some added flexibility in certain areas. Not necessarily a bad thing but it feels like its three years too late to get major traction. Native TS is neat, but we also have TS compilers that are measured in milliseconds now.
In deno you can just open your ide, add some imports to the import map and you're ready to code.
I do wonder about the long-term effects of Deno being Node-compatible; will it result in only Node programming being done since "Deno will handle it fine" and thus Deno specific stuff will not be developed?
Nah, Deno is just another runtime. Now we have the browser runtimes and multiple server runtimes. Not to mention we also have server runtimes like Cloudflare Workers that are "almost" Node in the sense that they run on V8, but without access to filesystem APIs. People will make sure to distribute their library so that it works on all of them. They might even use `deno compile` to bundle the library into a single file…
Slowly Deno is just becoming Node written in Rust with some added flexibility in certain areas. Not necessarily a bad thing but it feels like its three years too late to get major traction. Native TS is neat, but we also have TS compilers that are measured in milliseconds now.
I don't think the speed matters persa, what annoys me is when starting a node project I have to install typescript, jest, eslint (any plugins) then whatever dependences I am using and then set up a tsconfig and what every else also needs a config file. In deno you can just open your ide, add some imports to the import map and you're ready to code.
At this point, given the state of module loading on node and other ecosystem problems, my reasons for switching to deno (or bun) are dwindling.
Uhh do you not realize deno has an entirely different import system where you import by direct resource URL, or one level of indirection through an import map (just like the web)? There's no complex node_modules resolution, no .mjs extension nonsense, no package.json bits to flip. Imports are radically simpler in deno.
Earlier quoted context omitted.
> can someone explain why it's a good idea to have isolation at the interpreter level rather than relying on OS features? (or VMs). Those technologies are platform-specific and difficult to use. For example, provide the command line for running a Node.js program in Linux without file system access. In deno, it's deno run main.ts Or, to enable fs access: deno run --allow-read --allow-write main.ts --- That said, I agr…
Something along the lines of > docker run -it --rm -v "$PWD":/app -w /app node:18 node main.js It's a tad longer but it's more flexible too ;)
Deno is not supporting node.js built-ins. It's deno deploy. Meaning that this will not work on other hosting platforms, right... or?