14 ms·
Node.js built-ins on Deno Deploy
- lucacasonato 3y agoHey folks - I worked on this. AMA
- whoisthis4chan 3y agono question; just wanted to say thank you for your time & effort :)
- lucacasonato 3y agothanks! :D
- ignoramous 3y agoHi, thanks for this. Question: Do all Node APIs work as-is? For instance, I opened an issue for Deno stdlib's Conn interface to expose more state (like the ones available in Node: ready, half-open, writable, pause, resume, closed etc) for sockets, but those are unimplemented: https://github.com/denoland/deno/issues/13636 https://github.com/denoland/deno/issues/13636
- lucacasonato 3y agoMost Node APIs work just like they do in Node, yes. Some are not yet implemented (like the ones you mentioned). We'll be addressing them in priority order based on user feedback and how many NPM packages are blocked by the given feature.
- brazzledazzle 3y agoI listened to the SE Radio episode on Deno you did that covered compatibility. Just wanted to say it was a solid episode and gave me a lot of food for thought.
- deleted 3y ago[deleted]
- endisneigh 3y agoironically, the more node js goes into Deno, the less likely I am to switch. imho they should stay the course and not include too much node stuff.
- progx 3y agodeno has some benefits (fast, included ts, linter, formatter, etc.), but without node compatibility, i will not switch to deno.
- endisneigh 3y agoI am not saying deno does not have benefits. I am saying you can get many of those things with node already. I see deno more and more as an opinionated set of things + node. This is not a bad thing. but if you already have a huge legacy node project why would you switch to deno? or are we all going to pretend to forget why Deno was even created?
- lolinder 3y agoYep. I saw Deno as intended to be a platform for new projects that want to start fresh without all the legacy cruft from Node. Somewhere along the way they decided it was a priority to be able to transition legacy Node projects to Deno, and I'm afraid that what's going to happen is it will freeze the ecosystem's development of independent solutions in favor of just using Node libraries for everything.
- lucacasonato 3y agoI don't think this will happen. People _love_ cutting edge innovation. Cutting edge innovation happens on cutting edge platforms, not in the legacy.
- endisneigh 3y agoI disagree. people love a robust ecosystem, not innovation for innovation's sake.
- shrubble 3y agoI 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?
- eterm 3y agoDeno being Node compatible is the "Embrace" in "Embrace, Extend, Extinguish".
- pavlov 3y agoMicrosoft’s original successful application of this 3E strategy was predicated on them being the 300 kg gorilla in the market. Deno doesn’t seem to have that. When you’re the underdog, people don’t end up using your extensions without thinking.
- eknkc 3y agoI could also work if Deno had to offer more than what Node does, while being compatible. People would start using Deno and then start using Deno specific things which are not compatible with Node. Long shot though.
- endisneigh 3y agoyes. however Deno is the opposite of that. Typescript for example got adoption so fast because it was extremely easy to use typescript + javascript. Deno, however, inherently was against the node and npm sort of model. this makes sense in some sense since node does have a bunch of legacy cruft. however node is extremely popular and for adoption they need to support certain node features, and thus inherent the cruft. with each new adoption it makes less sense to use deno. I expect deno to convert all of their features to node modules and simply be an opinionated stack, similar to create-react-app vs. next.js. The path they're entertaining now isn't really tenable.
- endisneigh 3y ago
- robust-cactus 3y agoAt this point, given the state of module loading on node and other ecosystem problems, my reasons for switching to deno (or bun) are dwindling.
- qbasic_forever 3y agoUhh 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.
- robust-cactus 3y agoThat's my point. They fixed and defined the ecosystem which is great. I feel like everyone is forgetting what a mess Node is right now.
- bartlomieju 3y agoJust to clarify - we do have support for node_modules/ resolution (with all of its quirks and gotchas), otherwise we wouldn't be able to load npm packages. However we made a hard stance that CommonJS is only supported in npm dependencies and cannot be used in user code (ie. you must use ESM in your application code).
- tracker1 3y agoUntil you try to build a TS project that imports an .mjs from node_modules that doesn't work right. Oh, set the project to type=module, nope, then other crap breaks. I mean, you can get it all working, but simple and easy are two words I would not use for modern node, especially when working with typescript.
- andrewmcwatters 3y agoPst, you can do the same thing in Node.js. Nothing is stopping you.
- lolinder 3y agoDeno is moving into a similar space as Kotlin started at by adding all this interop—they're trying to be the "better Node". Meanwhile Kotlin is frantically trying to differentiate itself because Java is closing the gap, but it's hard for them to do because they've spent so long piggybacking on the Java ecosystem. Deno is very vulnerable to the same fate. Yes, it's easier to get adoption if you can plug into an ecosystem that is already popular, but then it's not your ecosystem and the behemoth that actually owns the ecosystem will feel the threat and adapt. If you don't prioritize interop, your initial adoption will be much much slower, but if you make it out of the early stages you have an ecosystem of your own that has its own distinct advantages. The incumbent can't just pull in a few good features and thereby take your mind share.
- jrsj 3y agoDeno Deploy is the killer feature for me, and it’s ultimately the main product of Deno, Inc. too. Node support just makes it easier to get existing software running there. I don’t think it will suffer the same fate as Kotlin because a lot of the value add is in Deploy, Deno KV, etc.
- sisve 3y agoWhat do you mean by "same fate as kotlin"? I would say Kotlin is doing great. Anything I missed?
- triyambakam 3y agoYou missed the parent comment this is in reply to
- sisve 3y agoYeah i guess i kind of did., I should have asked the parent comment. I'm not a java/kotlin developer but for me it looks like kotlin is thriving. Is that not how it looks for insider's?
- lucasyvas 3y agoThere are many people that feel having Node support harms Deno's goals, but I don't agree. To me, this is like complaining that you can mix JS into TypeScript projects. The only reason the latter is successful is because you can migrate from the former in a first-class way. I don't think Deno has the community support to make it on its own steam - that said, I think it's a huge value add in terms of DX. I support them on this 100%. Node is trying to add in some capabilities of Deno. We'll see which one comes out ahead.
- endisneigh 3y agothe comparison doesn't make sense. typescript inherently has advantages over javascript (well, unless Javascript officially supports types which isn't happening anytime soon (https://github.com/tc39/proposal-type-annotations https://github.com/tc39/proposal-type-annotations)). deno does not have any inherent advantages over node if they continue to support node functionality. I won't be surprised if package.json support is next. literally the purpose and sole advantage of deno was that they did not have node cruft. things like speed are not inherent advantages. it's true deno is written in rust, but node is basically v8, which has its own advantages.
- paulddraper 3y ago> deno does not have any inherent advantages over node if they support node Could you be more specific about how this harms deno? It is just "cruft"?
- endisneigh 3y agofor one the security model is incompatible with node APIs. as a result even with this post, deno doesn't support all npm packages. however if deno were to support all npm packages, it would necessarily basically have to implement the entire node api, including support for pre async/await (aka callbacks). this is but a single example. deno was able to ignore all of that because compatibility was not an original design decision
- skybrian 3y agoI recently got a simple edge function working on Netlify for a tiny hobbyist project, with some minor confusion but it was fine. I'm wondering how Deno Deploy compares?
- geysersam 3y agoHave not tried Netlify so can't exactly compare. But Deno Deploy is a very convenient FaaS. No discernible cold starts. Fast automatic deployment on push. No build step hassle. I'm really excited for when they also get state (Deno kv).
- mrwnmonm 3y agoCould you please explain what Deno is like I am five? (three actually)
- giraffe_lady 3y agoMostly like node but made by someone else and not actually node.
- user432678 3y agoWell, technically it’s made by the same initial author.
- shilangyu 3y agoExcept it's made by the same person
- lagniappe 3y agosame author, arguably same purpose, but this time with rust and typescript.
- kyle-rb 3y agoRyan Dahl created Node.js, had regrets, and started from scratch with Deno to address those issues [0] [0] https://www.youtube.com/watch?v=M3BM9TB-8yA https://www.youtube.com/watch?v=M3BM9TB-8yA
- mrwnmonm 3y agoThanks
- strangescript 3y agoSlowly 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.
- vorticalbox 3y agoI 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.
- mark_and_sweep 3y agoNote that import maps are optional. I mostly just open my editor for a Deno project and I'm good to go. :)
- tracker1 3y agoThis is it for me too... with Deno, I can write a fully contained one-off script with a shebang and use it for general shell scripting.. with node, it was never that simple. Though having to use the `#!/usr/bin/env -S -- deno run ...` is still a little more awkward. Direct imports that the runtime caches for you, vs node_modules is way easier to deal with most of the time.
- sisve 3y agoAm I the only one reading this right or am I the only one reading it wrong. Deno is not supporting node.js built-ins. It's deno deploy. Meaning that this will not work on other hosting platforms, right... or?
- tracker1 3y agoDeno has already been seeing increasing support for Node's API and built-ins... this means, they are now also available for running in Deno Deploy (cloud environment)... if you were using something where you deployed your own Deno (docker, etc) then you could already to this. Note: Cloudflare Workers is also starting to support a lot of Node APIs as well (opt-in), so bundles will likely be able to run in both of them and others. Can't speak specifically to it, but Bun will probably also largely work.
- sisve 3y agoThanks. That explains it. See that it was added to deno in jan. I guess the last version on deno made it ready to be used on deno deploy.