Let's say a company were to adopt this tech over Node, well, it seems like it would be slightly better, but probably not much of a game-changer.
I'll leave it to y'all to talk about what tech is truly interesting as I don't want to seem ideological/biased, I just don't see how Deno is particularly notable.
In that, Deno reminds me of the once-hyped Meteor.js. Meteor.js also though that funding could be the answer, but it wasn't. They're both clever, great for demos, but not sufficiently so to overcome the sheer inertia of Node+NPM et al. When something truly 10X better arrives, it will be quite apparent. Just like how React spawned a new generation of frameworks, nothing has unseated it yet because all the competition is React-like and not 10X better.
I first saw Ryan Dahl's talk about his Node.js regrets[0] during the early days of the pandemic. I thought I'd be eager to try Deno when it became more mature, but I still haven't tried it. I guess I'm not convinced that it's 10x better than Node.js.
In substance they are similar in that they both want/ed tighter "vertical integration" of tools ("DX") in an opinionated way, with the money-making plan being convenient paid hosting. "Look how easy and fun it is to make powerful stuff; we hope you give us money to host it for you!" So far the only company that's had success with this pitch is Amazon of all people, by offering a staggering array of partially specialized EC2 instances behind an API.
For whatever reason, it does seem like devs really like their app authoring tools to be independent of their distribution mechanisms. Maybe AWS doesn't trigger this because it doesn't feel like hosting (even though it is). When a whole diverse community seems to act coherently in this way, it's probably a good idea to listen to them. (Alternatively, when a community acts coherently, its ALSO a good idea to try something new.)
Deno is quite good. It may even be 10x node, if only because it avoids npm and has a much more thoughtful module system. It's a (much) better DX, too. Can they make money? Time will tell and, luckily, that's not my problem!
I think NextJS and Vercel probably fall into this bucket as well.
I agree with the overall sentiment, but this is a bad example. SVN was pretty successful at replacing CVS, even though it was not 10x better.
Until, of course the new generation came in (git, mercurial...).
xckd is full of examples of much "better" it happens to be in reality.
I think the place they can really sell me is:
- source maps
- debugging
It’s an absolutely PITA to get those two things working across a JavaScript stack. There are so many runtime contexts to deal with:
1) the browser
2) your API server
3) your frontend test env
4) your API server test env
5) browser and backend for your end to end/integration tests
6) pre-packaged code from secondary repos you are importing into all of the above
7) All of the above in CI
8) Special production builds of much of the above
It’s truly a nightmare. I’ve been trying to set up a fresh JavaScript full stack and it’s so much work. Every step of the way I need to take days off to do deep research into how to set this stuff up.
And it starts to make sense why no company I’ve ever worked at had all of that stuff working. You just deal with wrong stack traces and use console.log instead of a debugger in the places where it doesn’t work.
If Deno can provide all of those runtimes in an integrated way, with debugging and source maps working automatically that’s a total game changer.
And I’m honestly not sure who else could do it. Maybe like Next/Nuxt and all them? But do those projects handle build/packaging across multiple repos? I don’t think so…
Deno can nail that because they own packaging, and they can just skip the whole build/sourcemap step entirely and just distribute .ts files.
Deno Deploy (and Cloudflare Workers) is a big deal. At least for a small tech shop like ours, I've come to found it useful for >50% of the solutions we have to implement. Its simplicity and cost-effectiveness reminds me of S3 back when it launched: 5 APIs and pay-what-you-use billing. Sure, right now, Deno Deploy's capabilities are limited, but there's nothing stopping them from building a platform around it as they go along, and now they've got $21M reasons to keep at it.
I see parallels of Zeit/Vercel meteoric rise (no pun) in Deno.
I agree here, but
> Let's say a company were to adopt this tech over Node, well, it seems like it would be slightly better, but probably not much of a game-changer.
If I'm starting a new project, Deno will be compelling if it means zero configuration with sufficiently sane defaults. It's like Rails vs Ruby. With Node.JS, you can pick and choose then configure things like TypeScript, but then you have to manage configuration files for TypeScript, linting, and all these things not relevant to the app code.
As far as I'm concerned, as of right now Deno is _not_ better that node due to reasons above. It has the potential to be, and I wish the authors massive success and root for them. But I'm not gonna start a project on Deno due to lack of a proper ecosystem yet.
If there’s any area of modern software development that could benefit from a clean slate like Deno is attempting, it’s JS development.
Deno is working on the runtime, the cloud infrastructure, the dx, and a framework (fresh). Nobody is doing that afaik. I think this is where the value lies.
If I remember my Javascript-of-the-week-drama correctly, didn't Deno become a thing because a couple node/npm devs were upset that there was someone in the core node/npm team who did a bad thing?
Am I remembering this right?