9 ms·

Deno's Decline

208 points by enz 1y ago

HideousKojima 1y ago
Someone in a thread here a few months back described webdevs and their constant obsession with changing tooling, frameworks, etc. as "mayflies debating politics" or something to that effect and it has stuck with me since. Do all these new frameworks really have some sort of inherent flaws that require rebuilding everything from the ground up every 5 years or less? Or is it just something inherent in the language/web (and/or the sorts of people who become webdevs) that causes this phenomenon? Or when JS devs suddenly discover concepts like "serverside rendering" and reinvent PHP and ASP.NET.
- Alupis 1y ago
  I think it's mostly due to nobody solving "it" yet. If you look at the various frameworks, they approach the same problems in wildly different ways, even if the underlying ideas are similar. Take Svelte vs. Angular vs NextJS for example - they all sort of do same thing (create web apps), but take very different approaches. People choose these various frameworks for reasons, including what style makes the most sense to them, which one is easier to use, which one might be more performant for their use, etc. There's no clear "right" answer to which framework is best - in other words... the field has not yet been min-maxed. Regarding server-side rendering - I'd assert today's SSR is not really the same thing as classical SSR. Today's SSR is almost always a hybrid with some sort of client-side payload backed by server-side stuff, giving you the best of both worlds.
  - ho_lee_phuk 1y ago
    People are going to downvote me for saying this, but because JavaScript's built-in batteries are so weak, everyone re-invents them all the time in slightly different ways. - How do you build a Rust project? With cargo - How about the Go project? With the Go tool - How do you build a backend JavaScript project? - node, yarn (with different incompatible yarn versions), bun, and 5 other types of tools I manage a 100+ engineer team, and any time an engineer complains about our Python stack being unwieldy, I propose they work on frontend tooling for a week. JavaScript tooling makes Python tooling fragmentation look sane.
    - steezeburger 1y ago
      How can you possibly realistically manage a 100+ engineer team? 100+ direct reports? Also, the Python landscape is just as bad as frontend! And I enjoy writing both quite a bit. Pip, pipenv, pyenv, poetry, conda, virtualenv, uv, ruff, black, pep8, etc, etc. They both need massive improvements.
      - ho_lee_phuk 1y ago
        > How can you possibly realistically manage a 100+ engineer team? 100+ direct reports? They report to engineering managers who report to me. > Also, the Python landscape is just as bad as frontend! And I enjoy writing both quite a bit. Pip, pipenv, pyenv, poetry, conda, virtualenv, uv, ruff, black, pep8, etc, etc. They both need massive improvements. Yeah, it is bad, but a notch better. Most things in Python land are 5-year-olds. 5-year-old React or Vue codebases (the two most popular frameworks) are not backward-compatible with the current release. And we cannot stay on old versions as we have a government as a customer who requires SBOM, and SBOM declaring unmaintained dependencies creates even more trouble than upgrading frontends regularly!
- LikeAnElephant 1y ago
  > mayflies debating politics Well said to that person. I think about this a lot, and have wondered if it's the advent of code school? Which itself was a result of the insane FAANG hiring sprees + salaries (where was a result of 0% interest rates among other things). A developer going through code school in the last ~decade was taught React, GraphQL, Redux, or whatever the cool framework was at that moment with the goal of getting hired (not learning how to build well). I'm fortunate to have entered the market in the early 2000's juuuust before that wave started. I'm only now getting a few gray hairs in my beard and am glad I was taught to understand _all_ parts of a system. I don't know if that'd be the case if I started in the mid-2010's.
- leptons 1y ago
  ASP.NET supports JScript, I was doing "serverside rendering" with Javascript and ASP.NET about 7 years before nodejs was a thing. ASP.NET and PHP were reinventions of previous tech. As for webdevs and tech-churn, there are a lot of people that want to make their mark on the industry in one way or another. And it's human nature to want to make a better mousetrap. Combine that with the ease of publishing to npm and you get a lot of people reinventing a lot of wheels. I wouldn't really say the previous tech is "flawed" but anyone can find a reason to dislike anything, and that's especially so for nerds. I'm not much of an early adopter. I can create solutions with existing tech just fine. I'd maybe take a look at Deno once AWS has it as runtime option in Lambda, but that seems unlikely to happen.
  - joshstrange 1y ago
    > I'd maybe take a look at Deno once AWS has it as runtime option in Lambda, but that seems unlikely to happen. Are you using lambda currently for node? If so can I ask (at a high level) what your stack/deploy process is? I'm interested to know what someone who doesn't identify as an early adopter is using for lambda. I constantly waffle my decision to go with lambda (Typescript/nodeJS) for my company. In some ways it's amazing, in other it's blow-your-brains-out frustrating. I've benefited from my use of it overall I think but I often wonder if Express/NestJS/other would have been the better route (if not going all the way back to my roots with PHP). I'm using SST 2 (which uses CDK, which uses CloudFormation) to deploy my functions (1 function per endpoint). Unfortunately SST v3 decided to drop CDK and move to terraform but the upgrade path is almost non-existent. Essentially "Just spin up new infra with v3 then turn off your v2 stuff". I understand their decision and it was probably the right decision, it still burned me pretty bad. Needless to say, this has soured me (I already moved from Serverless Framework to SST a couple years ago and made it through the v1 -> v2 transition) and I'm considering alternatives. Ideally ones that don't require a complete rewrite but due to the fact that I'm not using any kind of framework (only my homegrown code/scaffolding) it might not be that hard to replace the "leaves" (endpoints) of my stack while keeping most of the other code the same.
    - leptons 1y ago
      >I'm interested to know what someone who doesn't identify as an early adopter is using for lambda. I was actually an early adopter of Lambda. At the time I didn't realize it was new, I was just looking for a way to host a new nodejs project in a scalable way. I did not want to spin up an EC2 instance for an Express based project and then have to manage load balancing and everything else that comes with it when the project needed to scale. I thought, why not make it scalable from the start? So I searched and found Lambda, which had launched only a few months earlier. It seemed great and exactly what I was looking for. I didn't realize it at the time that it was so new. I found it during Christmas vacation 2014 where I had a couple of weeks of "downtime" away from work to focus on my personal project and Lambda quickly won me over. Lambda was released in November 2014, so it was really new and I was unknowingly a very early adopter of it. There was no "Serverless" project at the time. So I created my own toolchain that I still use to this day. It's very simple. The dev program I created simply watches a folder for file changes, and then .ZIPs up the files, sends them to S3, then a companion Lambda function does "npm install" within a Lambda instance, then .ZIPs up the entire package and then updates the Lambda function I'm working on - this is done so any dependencies that require compilation will compile for the Lambda environment and not my local dev machine environment. It just works. I've added support for Layers when those became a thing, but other than that it's very simple and has withstood the test of time. I did try "Serverless" last year for another project, and it was not to my liking at all. I don't like giving "Serverless" access to my AWS account, and lots of other things made it not a good fit for me. YMMV. Yeah, there are some frustrating times with Lambda, but those are usually related to getting stuff running like a headless browser, or ffmpeg, or other heavier lifts to run inside a Lambda. But, I've got all that stuff working, and once it works, it just keeps working. I haven't touched some of the older Lambdas in years, some are still running on node v12. The only thing I kind of dislike is decommissioning of older nodejs runtimes so they aren't available at all for new Lambdas anymore. It's not that big a deal until I run into a situation where updating an older Lambda requires me to update the runtime, and there would be breaking changes due to different runtimes. But, it really is best if my code is updated to run on the latest nodejs version, although when I sometimes fall into this situation I start to question my choice of using Lambda. My regret is always short lived though, because Lambda is great in so many other ways.
- ianbicking 1y ago
  In one way or another they are all circling around a concept of "one runtime environment that is as close as possible to the browser JavaScript runtime" So in a sense, yes, they need to converge on the concept of a singular runtime, something which is achieved by fiat with server-side rendering.
- ho_lee_phuk 1y ago
  > Do all these new frameworks really have some sort of inherent flaws that require rebuilding everything from the ground up every 5 years or less? These frameworks are JavaScript frameworks in the sense that English and French are written using the Latin script. They are far apart from each other for day-to-day work.
- pjmlp 1y ago
  That is the only thing that makes me happy about Next.js, when I would rather be using ASP.NET or Spring/Quarkus.
andrewmcwatters 1y ago
I said it back when Deno was released, and I'll say it again: I'm not doing another JavaScript rugpull. Node.js is here to stay, it's mature, and if you want performance, leave it behind for Go. It was telling when you saw that basically all of Deno's interfaces were inspired by Go. I'm so glad that as an industry we're saying "No," to all of these JavaScript authors who try to yank entire ecosystems along with them as they go try and monetize their spin-offs. I'm too busy shipping to care.
- RainyDayTmrw 1y ago
  I dunno. How much do you value isomorphism and code sharing?
  - behnamoh 1y ago
    I legit read your comment as "I deno" :)
  - deleted 1y ago
    [deleted]
- josephg 1y ago
  That’s fair but - I replaced node with bun a few months ago and I haven’t looked back. All my JavaScript projects run with no changes. Performance is on par or better compared to nodejs. It can run typescript directly without needing to be compiled. It also has a built in bundler & minifier (bun build), and some other goodies. The command line is a bit different - you need to “bun run” to run scripts. But eh. Nodejs still works fine, of course. But being able to run typescript directly is killer.
  - croes 1y ago
    Wasn’t the USP of deno the baked in security features? How are bun and nodejs on that side?
    - nicce 1y ago
RainyDayTmrw 1y ago
This is sad news. I always found NodeJS' APIs to be a bit deficient, and liked Deno's better - with the caveat that they openly admit to copying designs from Go[1], so it's not necessarily original. [1]: https://deno.land/std@0.164.0 https://deno.land/std@0.164.0
MortyWaves 1y ago
I'm not convinced. The author has had a pretty negative view of Deno, JSR, etc since the beginning.
- knowitnone 1y ago
  I don't know the history the aurthor said he went all in on Deno. That doesn't seem negative at all.
- dbushell 1y ago
  My original view on Deno and JSR was positive and optimistic (it's all there on my blog). I've been using it for years and I still use Deno because it has more convenient/ergonomic APIs than Node. If Deno halving the Deploy regions twice from 35 to 12, and 12 to 6 doesn't convince you then I don't know what will
  - MortyWaves 1y ago
    It doesn’t convince me. You seem to be determined to conflate two very different things. If I use Deno it’s because it’s a language runtime. Deno Deploy is as the name says. The title should be, if anything, “the decline of an after thought deployment tool”.
crowcroft 1y ago
I don't intent this to be mean to Deno, but did it ever really get traction? Hard to describe something as a decline if it never really held a significant position.
- theThree 1y ago
  Maybe at some point. Their vsCode extension has 1M downloads, while Bun has 155k.
  - lioeters 1y ago
    That might be because Bun doesn't need an editor extension. It has type definitions and works fine with the built-in TypeScript language server, formatter, etc.
joshstrange 1y ago
I really want to like Deno. I started to watch "just a few minutes" of their keynote (I assume it was the most recent one, this was a month or so ago) and was intrigued by it and ended up watching the whole thing. Then I went to go play with it add... I ran into odd compatibility issues (no, I don't remember them, I'm sorry) and tried Bun and everything "just worked". I'm sure Bun is not perfect but so far, every one-off script I've thrown at it has "just worked" which is amazing for me since I greatly prefer to work in TypeScript and (until recently with the type-stripping stuff in node) that was way harder than it needed to be. If I never see an error about how I should change my "type" to "module" only to do it have it complain about 10 other things I will die happy. I love Javascript, I love TypeScript, I feel like I'm primed to love Deno but all the parts of it felt half-baked. The comments in this article about things like Fresh and K/V store ring very true. I kept looking for things like "What backend framework should I use?" and the answers were all over the place and not very mature options. It felt like I was building on sand. I hope I'm 100% wrong, I hope deno turns it around, I want more things like deno to exist, but the closing of data centers is not encouraging.
- davidkwast 1y ago
  Maybe Deno is the PyPy (from Python) to the JavaScript
  - pjmlp 1y ago
    To me Bun and Deno are more like egcs.
- dimal 1y ago
  I feel like they bit off more than they can chew. I want to like it, too. But they’re trying to create a whole new JavaScript ecosystem from the ground up, and a lot of it depends on maintaining a seamless compatibility layer that’s always a moving target. It’s not just node. They have Fresh, which depends on Preact, which is a compatibility layer over the React API. Why? To save a few K on bundle size? They have JSR. Why? The sales pitch is great: Typescript that just works. But in my experience, it didn’t “just work”. I tried building something with Fresh and ran into issues immediately. I bailed out.
evbogue 1y ago
The article mentions a decline in the number of regions Deno Deploy has in production. It isn't criticizing the runtime, but the confusion is understandable since they have similar product names. I wonder if there's a reason why there's a decline that the Deno people could weigh in on? Perhaps it's not a money issue, but some other reason why they decided to scale back the number of regions.
rglover 1y ago
I wired up some custom middleware on Bunny using Deno and it was the first time I really saw the value of it. It was really nice to just hot load dependencies via a URL, write my code, and go. Beyond that use case, though, not much has stood out.
- tough 1y ago
  sorry but what’s Bunny?
  - simonw 1y ago
    https://bunny.net/ https://bunny.net/ - a CDN, it has nothing to do with https://bun.sh/ https://bun.sh/ as far as I can tell. They use Deno for their edge scripting feature: https://bunny.net/blog/introducing-bunny-edge-scripting-a-better-way-to-build-and-deploy-applications-at-the-edge/ https://bunny.net/blog/introducing-bunny-edge-scripting-a-be...
    - tough 1y ago
      Oh okay thanks yeah I only found that CDN thing on google too but was wondering. fun fact I was considering making a bun-first CLI framework and current working name was Bunny
techgnosis 1y ago
At first I thought this was from a site called "DBUS Hell" and I was excited to read war stories about building the Linux desktop.
- TOGoS 1y ago
  import { SystemDBus } from "npm:@clebert/node-d-bus@1.0.0"; works surprisingly well, in my experience.
- dbushell 1y ago
  I hear that often, unfortunately it's just my name and I have too much equity in the domain!
magicink81 1y ago
Alternatively, this may be Deno’s “Dip”: A tough period of time before continued gains and small breakthroughs that build up over time to a new plateau. Maybe all new creative projects will have this as a part of their journey. I am confident Ryan Dahl is unlikely to give up, and is aware (and working to become more aware) of what is necessary to improve for deno to achieve the vision he has for it.
- esses 1y ago
  I read the post from a business lens and an outside observer and this was my hope too. If Deno is buckling down and cutting costs in order to survive a long winter and carry on that seems like the right move for the business and the community at the expense of latency.
- dbushell 1y ago
  Dahl doesn't strike me as a business or product person. He's a genius when left to tinker. I get the impression Deno is floundering because of business/VC pressure. I see the original promise of Deno being compromised in an effort to increase users/customers. The project is no longer focused on just making a good JS runtime.
  - GianFabien 1y ago
    Deno's original positioning was as a second version of NodeJS without the learning cruft cluttering the environment. To that extent I think Dahl and his team was successful. As is so often the case, once you introduce MBAs/VCs, the focus shifts to ROI and fast. I see Deno Deploy as being part of that attempt. People still tend to forget that software development tools are not commercially viable. For a long time we have become spoilt for choice with ever more and improving tools.
frou_dh 1y ago
From hanging around Deno's official Discord, Reddit, etc, I get the impression that there are simply not that many people using it. I doubt they are making much money from the public-facing Deno Deploy product, and are probably reducing its number of regions because those who are using it are mostly just noodling around on the free tier.
usef- 1y ago
That's sad to see. > If you sense some ire here it’s because I went all-in on Deno. I was fooled. I was rugged pulled. I don't agree with the author's use of "rug pulled" here. Deno took a shot and not all businesses succeed — they did have unusually strong competition in Bun. Them scaling down the number of regions might make them sustainable longer with their current customers who have deployments. That seems nicer than a hard shutdown.
- dbushell 1y ago
  The "rug pull" I was referring to is more about the general Deno philosophy. It's gone from being a modern forward-thinking JS runtime, to being just a Node/NPM copycat with its own half-baked packaging system. In regards to Deno Deploy I agree that scaling down is nicer, but they're extremely hush about it. Using Deploy for anything beyond a hobby project is a business risk.
deleted 1y ago
[deleted]
deleted 1y ago
[deleted]
randall 1y ago
i use deno all day every day. it’s really about taste. deno has insanely high standards, and the choices they make are great. deno deploy subhosting seems unlikely to go anywhere, even if the serverless fad is coming to its plateau of productivity. if you’re looking at node and think it’s great, you should use it. node compat makes me like deno more, not less. it’s fine to not use it, but most of the points are about deno the business, not deno the tech. postgres, rust, and a lot of other projects find a way out of the vc treadmill.
- DimmieMan 1y ago
  Personally the problem is just lack of communication. When 2 of your core products look abandoned your inviting this criticism. I love using Deno, even with the remaining node issues (usually relating to something in the Tower of Babel that is meta frameworks) it’s an exceedingly boring tool which is precisely what I’ve wanted for typescript for years. I can see they have technical potential but what I want more than anything else right now is just some confidence they’ll be around in 5 years, in this sense I can’t seperate the software and the business as there’s not one without the other. Hopefully the fresh & deploy v2 updates they’ve been silently working on deliver and this entire concern will evaporate.
Sytten 1y ago
The rust reimplementation of the node modules is interesting to read. I took some ideas for the llrt runtime modules. As a comparison Bun Zig implementation is scarily ignoring a lot of edge cases.
- bsder 1y ago
  So, basically, people don't seem to value security (Deno) very much but value speed (Bun) quite a lot. That is pretty much the standard problem across programming.
  - hu3 1y ago
    I value the path of least resistance, and Bun wins hands down because that's one of its priorities. In contrast, Deno gambled that Node compatibility wasn't critical and lost. Now they're backpedaling.
  - pjmlp 1y ago
    Mostly because liability is only a thing in some areas, when programming becomes as scrutinised as other industries, and basic stuff like returns due to failed functionality are normal instead of "try to reboot it", security and quality will have other priority.
- hardwaresofton 1y ago
  Everyone complains about Rust until they need high quality software that doesn't cut corners or isn’t impossible to write correctly. I’m biased but learning difficulty aside, Rust is very optimal as a language.
  - pjmlp 1y ago
    Except other than the affine types, we can get the same high quality in ML derived languages, nothing special about Rust there. In general the lack of quality is a side effect of the lack of liability in many software fields, not the programming language that gets used.
mmastrac 1y ago
Meh, I worked at Deno until last year and I think the signal of seeing Deploy downsize regions is not much of anything. The Deploy product itself suffered from some early missteps in terms of design. If anything, scaling down to a few core regions puts them in a better position to rebuild a stronger offering. There wasn't really a rugpull in the https:// https:// dependency space either. It just turns out that the package approach for software is better and there are major unsolved problems in web-identifier-based code distribution. I was skeptical of the value of JSR when it was first internally announced but TBH, but I think it's a strong offering in the packaging space and is in a better position than alternatives. node.js compat is hard, packaging is hard, writing performant Rust/V8 hybrid code is hard, but the team is pretty packed with smart people who really understand the space.
eranation 1y ago
Sorry for putting the security hat, but how does anyone run Deno in production without any worries when this is the state of affairs of their vulnerability notifications and scanning. No SBOM / SCA tool that I know of supports deno.lock and since it has a distributed nature, as far as I understand there is basically no way to be alerted on CVEs, unless you work hard to generate a compatible package-lock.json / yarn.lock file and stay with only npm compatible packages etc. Is it bothering only me? https://www.reddit.com/r/Deno/comments/1g5mu0l/thats_all_good_but_whats_with_audit/ https://www.reddit.com/r/Deno/comments/1g5mu0l/thats_all_goo... https://www.reddit.com/r/Deno/comments/1dpexwv/dependency_vulnerability_notifications/ https://www.reddit.com/r/Deno/comments/1dpexwv/dependency_vu...
nimchimpsky 1y ago
[dead]
mrcwinn 1y ago
Agree with the author. Deno recently has been loud about Oracle and the JavaScript trademark. Maybe they’re right, maybe they’re wrong, but it is a “last gasp” when your value proposition is something like: choose Deno, we’re righteous. Feels like a tactic to gain some attention. That’s just not how the market typically makes buying decisions, so what’s the value of the distraction when your product is in such a poor state?
justanotheratom 1y ago
Supabase's decision to take a dependency on Deno, IMO caused indirect pain to lot of devs. I have wasted quite a bit of time trying to find or load a package that I needed. And now, with Deno 2.0 apparently everything is node compatible... I don't know what was the whole point.
kamranjon 1y ago
I use Deno all the time... but it might not be exactly how it's marketed... Anytime I need to etl some data or transform a bunch of JSON or things of this nature - I use Deno. It's like a glue language for me at this point. I don't need to focus on configuration or any setup like this - I just create a new dir and I'm off. This article seems very hyperbolic to me - I still find a bunch of features within deno really helpful and there is still a ton of activity on Deno itself (Had a release yesterday) and many of the internal and community libraries in it's ecosystem like Postgres and Redis (which both had a release within the last week).
- edoceo 1y ago
  I read this same thing 25+ years ago. But we said Perl not Demo. Use the right tool. Right means reasonable and productive. Let folk who don't ship argue stack. While they're flapping, you are sailing.
  - 9d 1y ago
    I'll never understand how anyone ever liked Perl. I remember before PHP came out and Perl + CGI was what all the forums used, and that kind of made sense before Node.js + TypeScript + Nginx were a thing (maybe). But for scripts? I mean, I guess that it makes sense as a sort of bash on steroids, but at that point, why not have something more structured? Then again, that's around the time that Lua, Ruby, Python etc were all being invented, and for that exact use-case, to be a better scripting language that bash or Perl. But... why even use Perl as an intermediate step? Why not just say "hmm, bash is too simple for this... I'll write a --" oh, I think I get it now. Your only option was Perl for a while, if you didn't want to write a full fledged C or C++ script, which would be much more verbose and unforgiving.
    - xyzzy123 1y ago
      Perl's sweet spots were CGIs & sysadmin. The advantage for sysadmin was easier portability in the days when there were a ton of flavours of UNIX systems. The ergonomics & distribution of Perl in the 90s were unmatched, Ruby, Python, Lua were niche in comparison. The other killer feature was CPAN, the Perl community basically invented language package management and everyone else copied it.
zachwill 1y ago
I tried Deno for awhile — the ability to run Jupyter notebooks was a cool idea — but I’ve been Bun-only for around a year now. It’s just significantly faster and easier to use.
9d 1y ago
One major reason I still haven't switched away from Node and NPM is major stability and support, pretty much everywhere, e.g. full automatic VS Code support. Plus, even if it's ever so slowly, Node.js is legitimately keeping up to date with the latest ES features and always improving its stdlib, and V8 is still the king of performance and likely to remain so, unless, say, a court were to split up Chrome from Google funding by monopoly laws. That said, Node progress is slow. I'm not entirely sure why. I'd be glad to get paid to help make Node.js better if that were a job. And I'm still waiting on #57696 to avoid using async in a few places that I otherwise wouldn't need to.
- dbushell 1y ago
  Node’s progress to modern stuff like ES modules has been glacial. Probably the primary reason Bun/Deno have any success. It is speeding up though, seems a fire was lit by competition.
  - pjmlp 1y ago
    It hardly matters on the enterprise space where projects live from LTS to LTS, and version upgrades only happen when someone allocates enough budget for a consultancy to come in and do some upgrade project. These aren't the kind of folks rushing in to add Bun/Deno into their stacks.
throw1223323 1y ago
It's kind of funny but also depressing watching all the frontend people try to force Javascript onto the backend. They've been slowly rewriting their tooling using more suitable languages: - esbuild (Go) is 100x faster than webpack and friends - Bun (Zig) and Deno (Rust) are ~2x faster than Node - Typescript recently announced a rewrite in Go for an expected 10x performance gain Maybe one day they'll realize that those languages are good for more than developer tooling? Maybe they can even be used for serving web content?
- worik 1y ago
  > Typescript recently announced a rewrite in Go for an expected 10x performance gain Really? Why use Typescript at all, in that case? I really do not know
  - riknos314 1y ago
    The improvement is in `tsc`, the type checker. The improvement is reduced build times and thus faster developer or agent cycle times.
  - selljamhere 1y ago
    The Typescript compiler, currently JavaScript, is being rewritten in Go. The 10x performance gain is in build time, which is still a major speedup and will shrink the development loop.
- bluelightning2k 1y ago
  Couple things: First, perf you mention is from fundamentally CPU intensive workloads, not a sparse async environment like a typical server. Second (far more important) the reason we do this is type safety. We don't want types to break at the handover or to maintain them twice. We eliminate a huge category of issues and mental overhead. This maintainability and simplicity is worth more (to me at least) than perf. As a bonus there's also directly shared utils, classes etc. which again can be reused across client/server but more importantly stay in sync.
  - 1y ago
worik 1y ago
What interests me, are alternatives to Javascript type languages Deno was a step away from the shortcuts Node.js took, Typescript was a step away from the ones Javascript took. But time has moved on. Surely there is space for a *modern* garbage collected language (ie disqualifying Rust) for building servers. I spend my days programming in Typescript, and Rust. Typescript is ancient. (Vaguely Typed Script would be a more accurate name) Is that language Go? Does anybody start major projects using Node/[Type|Java]Script anymore?
exiguus 1y ago
IMO in JS/TS world its atm Bun vs. Deno in replacing node, npm, pnpm, yarn whatever other package manager. What i see is, that Deno try to go the vercel way and want to make some money to finance all this open source development. IMO totally legit. And also, normal, when you spin up a (startup) idea, 19 of 20 will fail. So i don't get the point of the article actually. The Article points to all this ideas but forgets that deno's core is the runtime. In between the lines, a node / LAMP-Stack history blinks up.
- BoorishBears 1y ago
  > Deno try to go the vercel way Future devs will look back and wonder why we randomly let Guillermo Rauch ruin the ecosystem for a few years.
  - exiguus 1y ago
    98% of the projects on vercel env are not enterprise - so i don't think so
    - BoorishBears 1y ago
      Not sure how this follows what I said. Rauch obviously doesn't care about the sustainability of his "JS library, but now it needs to become a unicorn to succeed" playbook because it's already making him money.
      - exiguus 1y ago
        I think i got it: The Next core: ISR/SSR - is practically replaced with React Server Components and Next has to move to a Platform to keep its worth.
    - pjmlp 1y ago
      In what concerns me, they certainly are, the reason I initially bothered with Next.js, are all those SaaS products that favour only React on their SDKs, with Next.js as second one, followed by everything else. Many of those SaaS vendors have partner agreements with Vercel.
d0100 1y ago
Deno is great! I am trying to use it as a FaaS to some level of success I only wish that the compiled binary retain full Deno capabilities, it would be even better if the permission model could limit file system access and limit cmd to a specific user I've also been using Deno Deploy for AI integrations, and something I miss is being able to have multy-file projects without deploying from github Just give me a online vscode environment, limited as it may be Typescript LSP should be able to run in a worker, and I wouldn't mind having to install a browser extension if necessary
porridgeraisin 1y ago
My thoughts on deno/bun: https://news.ycombinator.com/item?id=43458231 https://news.ycombinator.com/item?id=43458231 https://news.ycombinator.com/item?id=42806304 https://news.ycombinator.com/item?id=42806304
bluelightning2k 1y ago
Issue with deno deploy specifically: they have Deno subhosting but the model is you create an end user script, push it, then can run it. There's no concept of "run this once" or eval. So it's a very heavy, deploy per run, model of iteration which is not suitable for the main use case of giving end users an editor to iterate with
bluelightning2k 1y ago
I like deno's security model where you have to enable things. But I think it made a HUGE mistake to the point of being useless. Realistically, we need to grant access to env variables, network, etc. So those flags are functionally useless as always enabled. The issue we face is making sure our dependencies don't do something nefarious. Demo doesn't solve that. I would really, really like to be able to specify these flags at the package level.
- dbushell 1y ago
  I think that’s still a win for Deno. Even using all but one flag is better than carte blanche. That said I often —allow-all because Im lazy. Containerising stuff helps.
- csiegert 1y ago
  It’s definitely nice to know that nothing gets executed, read, written or sent without permission from the user when running a program/script with Deno. You complain the flags always have to be set to get anything working so they are supposedly useless. No, you don’t have to set them in a grant-all fashion. All flags allow fine-grained permissions, e.g. --allow-env=API_KEY,PORT only allows access to the env vars API_KEY and PORT instead of all env vars. The same principle applies to --allow-net, --allow-run, --allow-read, --allow-write, etc. See `deno run --help` or https://docs.deno.com/runtime/fundamentals/security/ https://docs.deno.com/runtime/fundamentals/security/ for more.
pjmlp 1y ago
Many have yet to learn the history of alternative implementations like egcs, IronPython and IronRuby, jpython and jtcl, PyPy, Rubinius,... Most of the time switching is not worth the effort for the few things they do better than the original implementation, and eventually if the features are really relevant enough, the main implementation will end up having them as well.
- sam_goody 1y ago
  ValKey and Redis, MariaDB and MySQL, Freenginx and Nginx etc. It is very hard to take the crown from a well used platform, and the originals generally manage to maintain at least parity, but the forks tend to shoulder along for a really long time, and sometimes they win.
- tbolt 1y ago
  io.js
GianFabien 1y ago
I get it, there are heaps of NodeJS systems out there. Both Deno & Bun claim to be an improvement over NodeJS and then invest masses of time to be compatible with it. I never liked NodeJS and I would much rather prefer a clean room JS environment with absolutely no explicit NodeJS compatability. 100% support for Web API specs would suffice. Why can't Deno or Bun release a slim version and then a compatability preserving version for those folks who require it?
- dbushell 1y ago
  Would such versions be much slimmer? Most of the binary is the V8 engine. The compatibility layers are largely thin wrappers around APIs. Anyway, it does strike me as an odd pursuit regardless. Obviously they're seeing compatibility as opening the door for more potential customers. But as a dev, if I wanted Node compat I'd just use Node.
cookiengineer 1y ago
I'm not sure what to make of this article. I've been involved in the JS ecosystem for a very long while and was a very early contributor of node/v8/crankshaft/uv and the other libraries that made JS on the server side possible. Back in the days when Ry pitched it in our Zynga office and everyone but our STG was skeptical about JS on the server side. Fun times. To me, peak JS era was express and koa.js. After that it felt more and more complex with feature fatigue implementations that I don't really needed to solve my tasks at hand. Webpack, when it was still pitched at the local NuernbergJS, was also super nice as an idea and as an architecture to bundle things. But after a while I got annoyed by the reinvention cycle. Everything got pretty bloated when it could also not have been, and even when they started as a fresh slim alternative to something else. Some folks being proud of maintaining 100s of micro packages (seriously?) and the whole shitshow with leftpad and the debates in TC39 after it happened kind of threw me away. A couple years ago I gave Go another try and I started gradually to reimplement all the tools and libraries I've built before in it, and I loved the simplicity of it. Coming from an embedded C++ background, Go felt like the middle ground in between C and something VM managed, with lots of opinions that I hated at first. But when you realize it's better to have an opinion on something for the sake of convention - even when you don't agree with it - than no opinion at all, leading to cluttered glue code everywhere - you start to cherish the ecosystem a lot. In my opinion, when I'm looking at my production languages that I've used vs the ones I try to avoid as much as possible right now, it always boils down to the standard library and packages it offers. Go's success is not because of its opinions and conventions alone (I hate them sometimes) but because of the standard library. In go, pretty much anything you want is either in the core or in golang.org/x. The only package we need for production software is cilium's ebpf package. And I think that's the build ecosystem effect that people experience in zig/go/bun, but not in deno. Deno at this point is as alien to the JS language ecosystem as JerryScript is, and you could've replaced the underlying language completely, and have the same production efficiency.
- hu3 1y ago
  > To me, peak JS era was express and koa.js. I cherish those times of calmer waters. At the time I had high hopes for Hapi.js (https://hapi.dev https://hapi.dev), created by Walmart folks. But I don't hear much about it these days.
kassner 1y ago
Deno 2.3 was released after this article was published. Does this invalidate it?
- dbushell 1y ago
  Yes, all of the criticism in my post is entirely invalidated. No, the Deno runtime gets regular updates. I don’t think you read the article lol.
  - deleted 1y ago
    [deleted]
nake89 1y ago
I loved David Bushell's writing. Very entertaining as always. I do agree many of Deno's products are in decline. But I think deno is by far the superior typescript/javascript runtime. And deno can be run on many reputable edge providers. So deno deploy is not necessary. It's too bad because I did like the simplicity of deno deploy, but other edge provides seem to be good too. Some of it does indeed need tweaking to get it work. But I find many amazing pieces of software written for Deno. And I find deno's tooling and security way more mature than node or bun. As long as the tooling stays good and the runtime is updated. I'm staying. I will be willing to switch to bun if the tooling/security gets good. I should revisit bun to see if it is now good. To my knowledge bun does not have granular permission levels like Deno. I don't understand why the runtime should have access to everything by default. I much prefer deno's way of doing things.
- rawkode 1y ago
  Which reputable edge providers? Besides Bunny, I don't think another exists.
- hoppp 1y ago
  Deno Deploy is a failure because it's not alluring to pay per request, especially with endpoints exposed to the open web. Deno is still better than node and its sort of a swiss army knife for developing servers in Typescript fast.
weinzierl 1y ago
With Microsoft's move to port the Typescript compiler to Go, Deno faces an interesting technical challenge. They're going to have integrate their Rust code with the Microsoft's Go. It will be interesting to see how this is going to play out.
deleted 1y ago
[deleted]
Defletter 1y ago
Really liked Deno, particularly its support of url imports. As primarily a Java developer having to deal with Maven dependencies, I cannot stress enough how refreshing it was to just say "the dependency is right there, go get it". The problem came when I noticed how Deno was being steered towards SaaS. For example, Deno KV, which uses SQLite internally, became available with v1.33 (https://deno.com/blog/v1.33#built-in-kv-database https://deno.com/blog/v1.33#built-in-kv-database). But actual SQLite support did not come until v2.2 (https://deno.com/blog/v2.2#support-for-nodesqlite https://deno.com/blog/v2.2#support-for-nodesqlite) nearly two years later... and it's a node api! The fact that Deno is lagging behind Node so it can shepherd people towards a first-party alternative that they just so happen to offer premium services for is... well, it didn't bode well. I've since abandoned Deno for Bun, which has meant giving up url imports, but Bun always feels so fresh. It gave me first-party SQLite support, not an abstraction around SQLite that they hint hint, nudge nudge me towards paying for. That said, I have felt a little uneasy about Bun since its v1.2 release (https://bun.sh/blog/bun-v1.2 https://bun.sh/blog/bun-v1.2).
- mac9 1y ago
  To clarify KV uses SQLite in development but FoundationDB when deployed to Deno Deploy.
gr4vityWall 1y ago
I like the idea behind Deno. I hope the runtime stays relevant. JSR sounded amazing on paper, but in practice, it seemed to have a lot of papercuts. You still can't make an account there without a GitHub account, I think. I wish they made a stronger push for its standard library to be used outside Deno. Such a push would clash with their original goal of not depending on npm, I guess. A well-maintained set of common functionality implemented in a cross-runtime way is still needed by the ecosystem, I think.
mac9 1y ago
For me Deno as a technology is great, the development of Fresh has been slow indeed however it is such a clean and effective way to write modern web applications. With KV built-in and deploy you don't really need to install anything other than the core fresh dependencies.
hoppp 1y ago
Not true that its not updated. They just released Deno 2.3 on the 1st of May. There was no such thing as a Deno rug pull, the author links to the use of http imports which are better used inside a map than directly in a file. Deno is fine and as a technology gets more mature it should get more boring.
animanoir 1y ago
[dead]
backspaces 1y ago
I wanted to create webdav servers hosted by glitch and cpanel. I ended up with exactly the same code on both, nice! Basically they both have node.js capabilities so I could use node.js webdav-server. But then I got the bright idea of using deno deploy which I've used in the past and loved, even using kv rather than a file system. It works (thanks chat) but it basically required creating my own version of the node.js webdav-server. Kinda annoying. The bottom line is that deno deploy is fighting a battle it can't win. Deno was the "better" node.js. And then it started integrating node capabilities, trying for a drop-in replacement of node. Nope. Sigh. I still love it for many simple projects but there's a reason node.js is, er, node.

208 points by enz 1y ago

Someone in a thread here a few months back described webdevs and their constant obsession with changing tooling, frameworks, etc. as "mayflies debating politics" or something to that effect and it has stuck with me since. Do all these new frameworks really have some sort of inherent flaws that require rebuilding everything from the ground up every 5 years or less? Or is it just something inherent in the language/web (and/or the sorts of people who become webdevs) that causes this phenomenon? Or when JS devs suddenly discover concepts like "serverside rendering" and reinvent PHP and ASP.NET.

Alupis 1y ago
I think it's mostly due to nobody solving "it" yet. If you look at the various frameworks, they approach the same problems in wildly different ways, even if the underlying ideas are similar. Take Svelte vs. Angular vs NextJS for example - they all sort of do same thing (create web apps), but take very different approaches. People choose these various frameworks for reasons, including what style makes the most sense to them, which one is easier to use, which one might be more performant for their use, etc. There's no clear "right" answer to which framework is best - in other words... the field has not yet been min-maxed. Regarding server-side rendering - I'd assert today's SSR is not really the same thing as classical SSR. Today's SSR is almost always a hybrid with some sort of client-side payload backed by server-side stuff, giving you the best of both worlds.
- ho_lee_phuk 1y ago
  People are going to downvote me for saying this, but because JavaScript's built-in batteries are so weak, everyone re-invents them all the time in slightly different ways. - How do you build a Rust project? With cargo - How about the Go project? With the Go tool - How do you build a backend JavaScript project? - node, yarn (with different incompatible yarn versions), bun, and 5 other types of tools I manage a 100+ engineer team, and any time an engineer complains about our Python stack being unwieldy, I propose they work on frontend tooling for a week. JavaScript tooling makes Python tooling fragmentation look sane.
  - steezeburger 1y ago
    How can you possibly realistically manage a 100+ engineer team? 100+ direct reports? Also, the Python landscape is just as bad as frontend! And I enjoy writing both quite a bit. Pip, pipenv, pyenv, poetry, conda, virtualenv, uv, ruff, black, pep8, etc, etc. They both need massive improvements.
    - ho_lee_phuk 1y ago
      > How can you possibly realistically manage a 100+ engineer team? 100+ direct reports? They report to engineering managers who report to me. > Also, the Python landscape is just as bad as frontend! And I enjoy writing both quite a bit. Pip, pipenv, pyenv, poetry, conda, virtualenv, uv, ruff, black, pep8, etc, etc. They both need massive improvements. Yeah, it is bad, but a notch better. Most things in Python land are 5-year-olds. 5-year-old React or Vue codebases (the two most popular frameworks) are not backward-compatible with the current release. And we cannot stay on old versions as we have a government as a customer who requires SBOM, and SBOM declaring unmaintained dependencies creates even more trouble than upgrading frontends regularly!
LikeAnElephant 1y ago
> mayflies debating politics Well said to that person. I think about this a lot, and have wondered if it's the advent of code school? Which itself was a result of the insane FAANG hiring sprees + salaries (where was a result of 0% interest rates among other things). A developer going through code school in the last ~decade was taught React, GraphQL, Redux, or whatever the cool framework was at that moment with the goal of getting hired (not learning how to build well). I'm fortunate to have entered the market in the early 2000's juuuust before that wave started. I'm only now getting a few gray hairs in my beard and am glad I was taught to understand _all_ parts of a system. I don't know if that'd be the case if I started in the mid-2010's.
leptons 1y ago
ASP.NET supports JScript, I was doing "serverside rendering" with Javascript and ASP.NET about 7 years before nodejs was a thing. ASP.NET and PHP were reinventions of previous tech. As for webdevs and tech-churn, there are a lot of people that want to make their mark on the industry in one way or another. And it's human nature to want to make a better mousetrap. Combine that with the ease of publishing to npm and you get a lot of people reinventing a lot of wheels. I wouldn't really say the previous tech is "flawed" but anyone can find a reason to dislike anything, and that's especially so for nerds. I'm not much of an early adopter. I can create solutions with existing tech just fine. I'd maybe take a look at Deno once AWS has it as runtime option in Lambda, but that seems unlikely to happen.
- joshstrange 1y ago
  > I'd maybe take a look at Deno once AWS has it as runtime option in Lambda, but that seems unlikely to happen. Are you using lambda currently for node? If so can I ask (at a high level) what your stack/deploy process is? I'm interested to know what someone who doesn't identify as an early adopter is using for lambda. I constantly waffle my decision to go with lambda (Typescript/nodeJS) for my company. In some ways it's amazing, in other it's blow-your-brains-out frustrating. I've benefited from my use of it overall I think but I often wonder if Express/NestJS/other would have been the better route (if not going all the way back to my roots with PHP). I'm using SST 2 (which uses CDK, which uses CloudFormation) to deploy my functions (1 function per endpoint). Unfortunately SST v3 decided to drop CDK and move to terraform but the upgrade path is almost non-existent. Essentially "Just spin up new infra with v3 then turn off your v2 stuff". I understand their decision and it was probably the right decision, it still burned me pretty bad. Needless to say, this has soured me (I already moved from Serverless Framework to SST a couple years ago and made it through the v1 -> v2 transition) and I'm considering alternatives. Ideally ones that don't require a complete rewrite but due to the fact that I'm not using any kind of framework (only my homegrown code/scaffolding) it might not be that hard to replace the "leaves" (endpoints) of my stack while keeping most of the other code the same.
  - leptons 1y ago
    >I'm interested to know what someone who doesn't identify as an early adopter is using for lambda. I was actually an early adopter of Lambda. At the time I didn't realize it was new, I was just looking for a way to host a new nodejs project in a scalable way. I did not want to spin up an EC2 instance for an Express based project and then have to manage load balancing and everything else that comes with it when the project needed to scale. I thought, why not make it scalable from the start? So I searched and found Lambda, which had launched only a few months earlier. It seemed great and exactly what I was looking for. I didn't realize it at the time that it was so new. I found it during Christmas vacation 2014 where I had a couple of weeks of "downtime" away from work to focus on my personal project and Lambda quickly won me over. Lambda was released in November 2014, so it was really new and I was unknowingly a very early adopter of it. There was no "Serverless" project at the time. So I created my own toolchain that I still use to this day. It's very simple. The dev program I created simply watches a folder for file changes, and then .ZIPs up the files, sends them to S3, then a companion Lambda function does "npm install" within a Lambda instance, then .ZIPs up the entire package and then updates the Lambda function I'm working on - this is done so any dependencies that require compilation will compile for the Lambda environment and not my local dev machine environment. It just works. I've added support for Layers when those became a thing, but other than that it's very simple and has withstood the test of time. I did try "Serverless" last year for another project, and it was not to my liking at all. I don't like giving "Serverless" access to my AWS account, and lots of other things made it not a good fit for me. YMMV. Yeah, there are some frustrating times with Lambda, but those are usually related to getting stuff running like a headless browser, or ffmpeg, or other heavier lifts to run inside a Lambda. But, I've got all that stuff working, and once it works, it just keeps working. I haven't touched some of the older Lambdas in years, some are still running on node v12. The only thing I kind of dislike is decommissioning of older nodejs runtimes so they aren't available at all for new Lambdas anymore. It's not that big a deal until I run into a situation where updating an older Lambda requires me to update the runtime, and there would be breaking changes due to different runtimes. But, it really is best if my code is updated to run on the latest nodejs version, although when I sometimes fall into this situation I start to question my choice of using Lambda. My regret is always short lived though, because Lambda is great in so many other ways.
ianbicking 1y ago
In one way or another they are all circling around a concept of "one runtime environment that is as close as possible to the browser JavaScript runtime" So in a sense, yes, they need to converge on the concept of a singular runtime, something which is achieved by fiat with server-side rendering.
ho_lee_phuk 1y ago
> Do all these new frameworks really have some sort of inherent flaws that require rebuilding everything from the ground up every 5 years or less? These frameworks are JavaScript frameworks in the sense that English and French are written using the Latin script. They are far apart from each other for day-to-day work.
pjmlp 1y ago
That is the only thing that makes me happy about Next.js, when I would rather be using ASP.NET or Spring/Quarkus.

andrewmcwatters 1y ago

I said it back when Deno was released, and I'll say it again: I'm not doing another JavaScript rugpull. Node.js is here to stay, it's mature, and if you want performance, leave it behind for Go. It was telling when you saw that basically all of Deno's interfaces were inspired by Go. I'm so glad that as an industry we're saying "No," to all of these JavaScript authors who try to yank entire ecosystems along with them as they go try and monetize their spin-offs. I'm too busy shipping to care.

RainyDayTmrw 1y ago
I dunno. How much do you value isomorphism and code sharing?
- behnamoh 1y ago
  I legit read your comment as "I deno" :)
- deleted 1y ago
  [deleted]
josephg 1y ago
That’s fair but - I replaced node with bun a few months ago and I haven’t looked back. All my JavaScript projects run with no changes. Performance is on par or better compared to nodejs. It can run typescript directly without needing to be compiled. It also has a built in bundler & minifier (bun build), and some other goodies. The command line is a bit different - you need to “bun run” to run scripts. But eh. Nodejs still works fine, of course. But being able to run typescript directly is killer.
- croes 1y ago
  Wasn’t the USP of deno the baked in security features? How are bun and nodejs on that side?
  - nicce 1y ago

RainyDayTmrw 1y ago

This is sad news. I always found NodeJS' APIs to be a bit deficient, and liked Deno's better - with the caveat that they openly admit to copying designs from Go[1], so it's not necessarily original. [1]: https://deno.land/std@0.164.0 https://deno.land/std@0.164.0

MortyWaves 1y ago

I'm not convinced. The author has had a pretty negative view of Deno, JSR, etc since the beginning.

knowitnone 1y ago
I don't know the history the aurthor said he went all in on Deno. That doesn't seem negative at all.
dbushell 1y ago
My original view on Deno and JSR was positive and optimistic (it's all there on my blog). I've been using it for years and I still use Deno because it has more convenient/ergonomic APIs than Node. If Deno halving the Deploy regions twice from 35 to 12, and 12 to 6 doesn't convince you then I don't know what will
- MortyWaves 1y ago
  It doesn’t convince me. You seem to be determined to conflate two very different things. If I use Deno it’s because it’s a language runtime. Deno Deploy is as the name says. The title should be, if anything, “the decline of an after thought deployment tool”.

crowcroft 1y ago

I don't intent this to be mean to Deno, but did it ever really get traction? Hard to describe something as a decline if it never really held a significant position.

theThree 1y ago
Maybe at some point. Their vsCode extension has 1M downloads, while Bun has 155k.
- lioeters 1y ago
  That might be because Bun doesn't need an editor extension. It has type definitions and works fine with the built-in TypeScript language server, formatter, etc.

joshstrange 1y ago

I really want to like Deno. I started to watch "just a few minutes" of their keynote (I assume it was the most recent one, this was a month or so ago) and was intrigued by it and ended up watching the whole thing. Then I went to go play with it add... I ran into odd compatibility issues (no, I don't remember them, I'm sorry) and tried Bun and everything "just worked". I'm sure Bun is not perfect but so far, every one-off script I've thrown at it has "just worked" which is amazing for me since I greatly prefer to work in TypeScript and (until recently with the type-stripping stuff in node) that was way harder than it needed to be. If I never see an error about how I should change my "type" to "module" only to do it have it complain about 10 other things I will die happy. I love Javascript, I love TypeScript, I feel like I'm primed to love Deno but all the parts of it felt half-baked. The comments in this article about things like Fresh and K/V store ring very true. I kept looking for things like "What backend framework should I use?" and the answers were all over the place and not very mature options. It felt like I was building on sand. I hope I'm 100% wrong, I hope deno turns it around, I want more things like deno to exist, but the closing of data centers is not encouraging.

davidkwast 1y ago
Maybe Deno is the PyPy (from Python) to the JavaScript
- pjmlp 1y ago
  To me Bun and Deno are more like egcs.
dimal 1y ago
I feel like they bit off more than they can chew. I want to like it, too. But they’re trying to create a whole new JavaScript ecosystem from the ground up, and a lot of it depends on maintaining a seamless compatibility layer that’s always a moving target. It’s not just node. They have Fresh, which depends on Preact, which is a compatibility layer over the React API. Why? To save a few K on bundle size? They have JSR. Why? The sales pitch is great: Typescript that just works. But in my experience, it didn’t “just work”. I tried building something with Fresh and ran into issues immediately. I bailed out.

evbogue 1y ago

The article mentions a decline in the number of regions Deno Deploy has in production. It isn't criticizing the runtime, but the confusion is understandable since they have similar product names. I wonder if there's a reason why there's a decline that the Deno people could weigh in on? Perhaps it's not a money issue, but some other reason why they decided to scale back the number of regions.

rglover 1y ago

I wired up some custom middleware on Bunny using Deno and it was the first time I really saw the value of it. It was really nice to just hot load dependencies via a URL, write my code, and go. Beyond that use case, though, not much has stood out.

tough 1y ago
sorry but what’s Bunny?
- simonw 1y ago
  https://bunny.net/ https://bunny.net/ - a CDN, it has nothing to do with https://bun.sh/ https://bun.sh/ as far as I can tell. They use Deno for their edge scripting feature: https://bunny.net/blog/introducing-bunny-edge-scripting-a-better-way-to-build-and-deploy-applications-at-the-edge/ https://bunny.net/blog/introducing-bunny-edge-scripting-a-be...
  - tough 1y ago
    Oh okay thanks yeah I only found that CDN thing on google too but was wondering. fun fact I was considering making a bun-first CLI framework and current working name was Bunny

techgnosis 1y ago

At first I thought this was from a site called "DBUS Hell" and I was excited to read war stories about building the Linux desktop.

TOGoS 1y ago
import { SystemDBus } from "npm:@clebert/node-d-bus@1.0.0"; works surprisingly well, in my experience.
dbushell 1y ago
I hear that often, unfortunately it's just my name and I have too much equity in the domain!

magicink81 1y ago

Alternatively, this may be Deno’s “Dip”: A tough period of time before continued gains and small breakthroughs that build up over time to a new plateau. Maybe all new creative projects will have this as a part of their journey. I am confident Ryan Dahl is unlikely to give up, and is aware (and working to become more aware) of what is necessary to improve for deno to achieve the vision he has for it.

esses 1y ago
I read the post from a business lens and an outside observer and this was my hope too. If Deno is buckling down and cutting costs in order to survive a long winter and carry on that seems like the right move for the business and the community at the expense of latency.
dbushell 1y ago
Dahl doesn't strike me as a business or product person. He's a genius when left to tinker. I get the impression Deno is floundering because of business/VC pressure. I see the original promise of Deno being compromised in an effort to increase users/customers. The project is no longer focused on just making a good JS runtime.
- GianFabien 1y ago
  Deno's original positioning was as a second version of NodeJS without the learning cruft cluttering the environment. To that extent I think Dahl and his team was successful. As is so often the case, once you introduce MBAs/VCs, the focus shifts to ROI and fast. I see Deno Deploy as being part of that attempt. People still tend to forget that software development tools are not commercially viable. For a long time we have become spoilt for choice with ever more and improving tools.

frou_dh 1y ago

From hanging around Deno's official Discord, Reddit, etc, I get the impression that there are simply not that many people using it. I doubt they are making much money from the public-facing Deno Deploy product, and are probably reducing its number of regions because those who are using it are mostly just noodling around on the free tier.

usef- 1y ago

That's sad to see. > If you sense some ire here it’s because I went all-in on Deno. I was fooled. I was rugged pulled. I don't agree with the author's use of "rug pulled" here. Deno took a shot and not all businesses succeed — they did have unusually strong competition in Bun. Them scaling down the number of regions might make them sustainable longer with their current customers who have deployments. That seems nicer than a hard shutdown.

dbushell 1y ago
The "rug pull" I was referring to is more about the general Deno philosophy. It's gone from being a modern forward-thinking JS runtime, to being just a Node/NPM copycat with its own half-baked packaging system. In regards to Deno Deploy I agree that scaling down is nicer, but they're extremely hush about it. Using Deploy for anything beyond a hobby project is a business risk.

deleted 1y ago

[deleted]

deleted 1y ago

[deleted]

randall 1y ago

i use deno all day every day. it’s really about taste. deno has insanely high standards, and the choices they make are great. deno deploy subhosting seems unlikely to go anywhere, even if the serverless fad is coming to its plateau of productivity. if you’re looking at node and think it’s great, you should use it. node compat makes me like deno more, not less. it’s fine to not use it, but most of the points are about deno the business, not deno the tech. postgres, rust, and a lot of other projects find a way out of the vc treadmill.

DimmieMan 1y ago
Personally the problem is just lack of communication. When 2 of your core products look abandoned your inviting this criticism. I love using Deno, even with the remaining node issues (usually relating to something in the Tower of Babel that is meta frameworks) it’s an exceedingly boring tool which is precisely what I’ve wanted for typescript for years. I can see they have technical potential but what I want more than anything else right now is just some confidence they’ll be around in 5 years, in this sense I can’t seperate the software and the business as there’s not one without the other. Hopefully the fresh & deploy v2 updates they’ve been silently working on deliver and this entire concern will evaporate.

Sytten 1y ago

The rust reimplementation of the node modules is interesting to read. I took some ideas for the llrt runtime modules. As a comparison Bun Zig implementation is scarily ignoring a lot of edge cases.

bsder 1y ago
So, basically, people don't seem to value security (Deno) very much but value speed (Bun) quite a lot. That is pretty much the standard problem across programming.
- hu3 1y ago
  I value the path of least resistance, and Bun wins hands down because that's one of its priorities. In contrast, Deno gambled that Node compatibility wasn't critical and lost. Now they're backpedaling.
- pjmlp 1y ago
  Mostly because liability is only a thing in some areas, when programming becomes as scrutinised as other industries, and basic stuff like returns due to failed functionality are normal instead of "try to reboot it", security and quality will have other priority.
hardwaresofton 1y ago
Everyone complains about Rust until they need high quality software that doesn't cut corners or isn’t impossible to write correctly. I’m biased but learning difficulty aside, Rust is very optimal as a language.
- pjmlp 1y ago
  Except other than the affine types, we can get the same high quality in ML derived languages, nothing special about Rust there. In general the lack of quality is a side effect of the lack of liability in many software fields, not the programming language that gets used.

mmastrac 1y ago

Meh, I worked at Deno until last year and I think the signal of seeing Deploy downsize regions is not much of anything. The Deploy product itself suffered from some early missteps in terms of design. If anything, scaling down to a few core regions puts them in a better position to rebuild a stronger offering. There wasn't really a rugpull in the https:// https:// dependency space either. It just turns out that the package approach for software is better and there are major unsolved problems in web-identifier-based code distribution. I was skeptical of the value of JSR when it was first internally announced but TBH, but I think it's a strong offering in the packaging space and is in a better position than alternatives. node.js compat is hard, packaging is hard, writing performant Rust/V8 hybrid code is hard, but the team is pretty packed with smart people who really understand the space.

eranation 1y ago

Sorry for putting the security hat, but how does anyone run Deno in production without any worries when this is the state of affairs of their vulnerability notifications and scanning. No SBOM / SCA tool that I know of supports deno.lock and since it has a distributed nature, as far as I understand there is basically no way to be alerted on CVEs, unless you work hard to generate a compatible package-lock.json / yarn.lock file and stay with only npm compatible packages etc. Is it bothering only me? https://www.reddit.com/r/Deno/comments/1g5mu0l/thats_all_good_but_whats_with_audit/ https://www.reddit.com/r/Deno/comments/1g5mu0l/thats_all_goo... https://www.reddit.com/r/Deno/comments/1dpexwv/dependency_vulnerability_notifications/ https://www.reddit.com/r/Deno/comments/1dpexwv/dependency_vu...

nimchimpsky 1y ago

[dead]

mrcwinn 1y ago

Agree with the author. Deno recently has been loud about Oracle and the JavaScript trademark. Maybe they’re right, maybe they’re wrong, but it is a “last gasp” when your value proposition is something like: choose Deno, we’re righteous. Feels like a tactic to gain some attention. That’s just not how the market typically makes buying decisions, so what’s the value of the distraction when your product is in such a poor state?

justanotheratom 1y ago

Supabase's decision to take a dependency on Deno, IMO caused indirect pain to lot of devs. I have wasted quite a bit of time trying to find or load a package that I needed. And now, with Deno 2.0 apparently everything is node compatible... I don't know what was the whole point.

kamranjon 1y ago

I use Deno all the time... but it might not be exactly how it's marketed... Anytime I need to etl some data or transform a bunch of JSON or things of this nature - I use Deno. It's like a glue language for me at this point. I don't need to focus on configuration or any setup like this - I just create a new dir and I'm off. This article seems very hyperbolic to me - I still find a bunch of features within deno really helpful and there is still a ton of activity on Deno itself (Had a release yesterday) and many of the internal and community libraries in it's ecosystem like Postgres and Redis (which both had a release within the last week).

edoceo 1y ago
I read this same thing 25+ years ago. But we said Perl not Demo. Use the right tool. Right means reasonable and productive. Let folk who don't ship argue stack. While they're flapping, you are sailing.
- 9d 1y ago
  I'll never understand how anyone ever liked Perl. I remember before PHP came out and Perl + CGI was what all the forums used, and that kind of made sense before Node.js + TypeScript + Nginx were a thing (maybe). But for scripts? I mean, I guess that it makes sense as a sort of bash on steroids, but at that point, why not have something more structured? Then again, that's around the time that Lua, Ruby, Python etc were all being invented, and for that exact use-case, to be a better scripting language that bash or Perl. But... why even use Perl as an intermediate step? Why not just say "hmm, bash is too simple for this... I'll write a --" oh, I think I get it now. Your only option was Perl for a while, if you didn't want to write a full fledged C or C++ script, which would be much more verbose and unforgiving.
  - xyzzy123 1y ago
    Perl's sweet spots were CGIs & sysadmin. The advantage for sysadmin was easier portability in the days when there were a ton of flavours of UNIX systems. The ergonomics & distribution of Perl in the 90s were unmatched, Ruby, Python, Lua were niche in comparison. The other killer feature was CPAN, the Perl community basically invented language package management and everyone else copied it.

zachwill 1y ago

I tried Deno for awhile — the ability to run Jupyter notebooks was a cool idea — but I’ve been Bun-only for around a year now. It’s just significantly faster and easier to use.

9d 1y ago

One major reason I still haven't switched away from Node and NPM is major stability and support, pretty much everywhere, e.g. full automatic VS Code support. Plus, even if it's ever so slowly, Node.js is legitimately keeping up to date with the latest ES features and always improving its stdlib, and V8 is still the king of performance and likely to remain so, unless, say, a court were to split up Chrome from Google funding by monopoly laws. That said, Node progress is slow. I'm not entirely sure why. I'd be glad to get paid to help make Node.js better if that were a job. And I'm still waiting on #57696 to avoid using async in a few places that I otherwise wouldn't need to.

dbushell 1y ago
Node’s progress to modern stuff like ES modules has been glacial. Probably the primary reason Bun/Deno have any success. It is speeding up though, seems a fire was lit by competition.
- pjmlp 1y ago
  It hardly matters on the enterprise space where projects live from LTS to LTS, and version upgrades only happen when someone allocates enough budget for a consultancy to come in and do some upgrade project. These aren't the kind of folks rushing in to add Bun/Deno into their stacks.

throw1223323 1y ago

It's kind of funny but also depressing watching all the frontend people try to force Javascript onto the backend. They've been slowly rewriting their tooling using more suitable languages: - esbuild (Go) is 100x faster than webpack and friends - Bun (Zig) and Deno (Rust) are ~2x faster than Node - Typescript recently announced a rewrite in Go for an expected 10x performance gain Maybe one day they'll realize that those languages are good for more than developer tooling? Maybe they can even be used for serving web content?

worik 1y ago
> Typescript recently announced a rewrite in Go for an expected 10x performance gain Really? Why use Typescript at all, in that case? I really do not know
- riknos314 1y ago
  The improvement is in `tsc`, the type checker. The improvement is reduced build times and thus faster developer or agent cycle times.
- selljamhere 1y ago
  The Typescript compiler, currently JavaScript, is being rewritten in Go. The 10x performance gain is in build time, which is still a major speedup and will shrink the development loop.
bluelightning2k 1y ago
Couple things: First, perf you mention is from fundamentally CPU intensive workloads, not a sparse async environment like a typical server. Second (far more important) the reason we do this is type safety. We don't want types to break at the handover or to maintain them twice. We eliminate a huge category of issues and mental overhead. This maintainability and simplicity is worth more (to me at least) than perf. As a bonus there's also directly shared utils, classes etc. which again can be reused across client/server but more importantly stay in sync.
- 1y ago

worik 1y ago

What interests me, are alternatives to Javascript type languages Deno was a step away from the shortcuts Node.js took, Typescript was a step away from the ones Javascript took. But time has moved on. Surely there is space for a *modern* garbage collected language (ie disqualifying Rust) for building servers. I spend my days programming in Typescript, and Rust. Typescript is ancient. (Vaguely Typed Script would be a more accurate name) Is that language Go? Does anybody start major projects using Node/[Type|Java]Script anymore?

exiguus 1y ago

IMO in JS/TS world its atm Bun vs. Deno in replacing node, npm, pnpm, yarn whatever other package manager. What i see is, that Deno try to go the vercel way and want to make some money to finance all this open source development. IMO totally legit. And also, normal, when you spin up a (startup) idea, 19 of 20 will fail. So i don't get the point of the article actually. The Article points to all this ideas but forgets that deno's core is the runtime. In between the lines, a node / LAMP-Stack history blinks up.

BoorishBears 1y ago
> Deno try to go the vercel way Future devs will look back and wonder why we randomly let Guillermo Rauch ruin the ecosystem for a few years.
- exiguus 1y ago
  98% of the projects on vercel env are not enterprise - so i don't think so
  - BoorishBears 1y ago
    Not sure how this follows what I said. Rauch obviously doesn't care about the sustainability of his "JS library, but now it needs to become a unicorn to succeed" playbook because it's already making him money.
    - exiguus 1y ago
      I think i got it: The Next core: ISR/SSR - is practically replaced with React Server Components and Next has to move to a Platform to keep its worth.
  - pjmlp 1y ago
    In what concerns me, they certainly are, the reason I initially bothered with Next.js, are all those SaaS products that favour only React on their SDKs, with Next.js as second one, followed by everything else. Many of those SaaS vendors have partner agreements with Vercel.

d0100 1y ago

Deno is great! I am trying to use it as a FaaS to some level of success I only wish that the compiled binary retain full Deno capabilities, it would be even better if the permission model could limit file system access and limit cmd to a specific user I've also been using Deno Deploy for AI integrations, and something I miss is being able to have multy-file projects without deploying from github Just give me a online vscode environment, limited as it may be Typescript LSP should be able to run in a worker, and I wouldn't mind having to install a browser extension if necessary

porridgeraisin 1y ago

My thoughts on deno/bun: https://news.ycombinator.com/item?id=43458231 https://news.ycombinator.com/item?id=43458231 https://news.ycombinator.com/item?id=42806304 https://news.ycombinator.com/item?id=42806304

bluelightning2k 1y ago

Issue with deno deploy specifically: they have Deno subhosting but the model is you create an end user script, push it, then can run it. There's no concept of "run this once" or eval. So it's a very heavy, deploy per run, model of iteration which is not suitable for the main use case of giving end users an editor to iterate with

bluelightning2k 1y ago

I like deno's security model where you have to enable things. But I think it made a HUGE mistake to the point of being useless. Realistically, we need to grant access to env variables, network, etc. So those flags are functionally useless as always enabled. The issue we face is making sure our dependencies don't do something nefarious. Demo doesn't solve that. I would really, really like to be able to specify these flags at the package level.

dbushell 1y ago
I think that’s still a win for Deno. Even using all but one flag is better than carte blanche. That said I often —allow-all because Im lazy. Containerising stuff helps.
csiegert 1y ago
It’s definitely nice to know that nothing gets executed, read, written or sent without permission from the user when running a program/script with Deno. You complain the flags always have to be set to get anything working so they are supposedly useless. No, you don’t have to set them in a grant-all fashion. All flags allow fine-grained permissions, e.g. --allow-env=API_KEY,PORT only allows access to the env vars API_KEY and PORT instead of all env vars. The same principle applies to --allow-net, --allow-run, --allow-read, --allow-write, etc. See `deno run --help` or https://docs.deno.com/runtime/fundamentals/security/ https://docs.deno.com/runtime/fundamentals/security/ for more.

pjmlp 1y ago

Many have yet to learn the history of alternative implementations like egcs, IronPython and IronRuby, jpython and jtcl, PyPy, Rubinius,... Most of the time switching is not worth the effort for the few things they do better than the original implementation, and eventually if the features are really relevant enough, the main implementation will end up having them as well.

sam_goody 1y ago
ValKey and Redis, MariaDB and MySQL, Freenginx and Nginx etc. It is very hard to take the crown from a well used platform, and the originals generally manage to maintain at least parity, but the forks tend to shoulder along for a really long time, and sometimes they win.
tbolt 1y ago
io.js

GianFabien 1y ago

I get it, there are heaps of NodeJS systems out there. Both Deno & Bun claim to be an improvement over NodeJS and then invest masses of time to be compatible with it. I never liked NodeJS and I would much rather prefer a clean room JS environment with absolutely no explicit NodeJS compatability. 100% support for Web API specs would suffice. Why can't Deno or Bun release a slim version and then a compatability preserving version for those folks who require it?

dbushell 1y ago
Would such versions be much slimmer? Most of the binary is the V8 engine. The compatibility layers are largely thin wrappers around APIs. Anyway, it does strike me as an odd pursuit regardless. Obviously they're seeing compatibility as opening the door for more potential customers. But as a dev, if I wanted Node compat I'd just use Node.

cookiengineer 1y ago

I'm not sure what to make of this article. I've been involved in the JS ecosystem for a very long while and was a very early contributor of node/v8/crankshaft/uv and the other libraries that made JS on the server side possible. Back in the days when Ry pitched it in our Zynga office and everyone but our STG was skeptical about JS on the server side. Fun times. To me, peak JS era was express and koa.js. After that it felt more and more complex with feature fatigue implementations that I don't really needed to solve my tasks at hand. Webpack, when it was still pitched at the local NuernbergJS, was also super nice as an idea and as an architecture to bundle things. But after a while I got annoyed by the reinvention cycle. Everything got pretty bloated when it could also not have been, and even when they started as a fresh slim alternative to something else. Some folks being proud of maintaining 100s of micro packages (seriously?) and the whole shitshow with leftpad and the debates in TC39 after it happened kind of threw me away. A couple years ago I gave Go another try and I started gradually to reimplement all the tools and libraries I've built before in it, and I loved the simplicity of it. Coming from an embedded C++ background, Go felt like the middle ground in between C and something VM managed, with lots of opinions that I hated at first. But when you realize it's better to have an opinion on something for the sake of convention - even when you don't agree with it - than no opinion at all, leading to cluttered glue code everywhere - you start to cherish the ecosystem a lot. In my opinion, when I'm looking at my production languages that I've used vs the ones I try to avoid as much as possible right now, it always boils down to the standard library and packages it offers. Go's success is not because of its opinions and conventions alone (I hate them sometimes) but because of the standard library. In go, pretty much anything you want is either in the core or in golang.org/x. The only package we need for production software is cilium's ebpf package. And I think that's the build ecosystem effect that people experience in zig/go/bun, but not in deno. Deno at this point is as alien to the JS language ecosystem as JerryScript is, and you could've replaced the underlying language completely, and have the same production efficiency.

hu3 1y ago
> To me, peak JS era was express and koa.js. I cherish those times of calmer waters. At the time I had high hopes for Hapi.js (https://hapi.dev https://hapi.dev), created by Walmart folks. But I don't hear much about it these days.

kassner 1y ago

Deno 2.3 was released after this article was published. Does this invalidate it?

dbushell 1y ago
Yes, all of the criticism in my post is entirely invalidated. No, the Deno runtime gets regular updates. I don’t think you read the article lol.
- deleted 1y ago
  [deleted]

nake89 1y ago

I loved David Bushell's writing. Very entertaining as always. I do agree many of Deno's products are in decline. But I think deno is by far the superior typescript/javascript runtime. And deno can be run on many reputable edge providers. So deno deploy is not necessary. It's too bad because I did like the simplicity of deno deploy, but other edge provides seem to be good too. Some of it does indeed need tweaking to get it work. But I find many amazing pieces of software written for Deno. And I find deno's tooling and security way more mature than node or bun. As long as the tooling stays good and the runtime is updated. I'm staying. I will be willing to switch to bun if the tooling/security gets good. I should revisit bun to see if it is now good. To my knowledge bun does not have granular permission levels like Deno. I don't understand why the runtime should have access to everything by default. I much prefer deno's way of doing things.

rawkode 1y ago
Which reputable edge providers? Besides Bunny, I don't think another exists.
hoppp 1y ago
Deno Deploy is a failure because it's not alluring to pay per request, especially with endpoints exposed to the open web. Deno is still better than node and its sort of a swiss army knife for developing servers in Typescript fast.

weinzierl 1y ago

With Microsoft's move to port the Typescript compiler to Go, Deno faces an interesting technical challenge. They're going to have integrate their Rust code with the Microsoft's Go. It will be interesting to see how this is going to play out.

deleted 1y ago

[deleted]

Defletter 1y ago

Really liked Deno, particularly its support of url imports. As primarily a Java developer having to deal with Maven dependencies, I cannot stress enough how refreshing it was to just say "the dependency is right there, go get it". The problem came when I noticed how Deno was being steered towards SaaS. For example, Deno KV, which uses SQLite internally, became available with v1.33 (https://deno.com/blog/v1.33#built-in-kv-database https://deno.com/blog/v1.33#built-in-kv-database). But actual SQLite support did not come until v2.2 (https://deno.com/blog/v2.2#support-for-nodesqlite https://deno.com/blog/v2.2#support-for-nodesqlite) nearly two years later... and it's a node api! The fact that Deno is lagging behind Node so it can shepherd people towards a first-party alternative that they just so happen to offer premium services for is... well, it didn't bode well. I've since abandoned Deno for Bun, which has meant giving up url imports, but Bun always feels so fresh. It gave me first-party SQLite support, not an abstraction around SQLite that they hint hint, nudge nudge me towards paying for. That said, I have felt a little uneasy about Bun since its v1.2 release (https://bun.sh/blog/bun-v1.2 https://bun.sh/blog/bun-v1.2).

mac9 1y ago
To clarify KV uses SQLite in development but FoundationDB when deployed to Deno Deploy.

gr4vityWall 1y ago

I like the idea behind Deno. I hope the runtime stays relevant. JSR sounded amazing on paper, but in practice, it seemed to have a lot of papercuts. You still can't make an account there without a GitHub account, I think. I wish they made a stronger push for its standard library to be used outside Deno. Such a push would clash with their original goal of not depending on npm, I guess. A well-maintained set of common functionality implemented in a cross-runtime way is still needed by the ecosystem, I think.

mac9 1y ago

For me Deno as a technology is great, the development of Fresh has been slow indeed however it is such a clean and effective way to write modern web applications. With KV built-in and deploy you don't really need to install anything other than the core fresh dependencies.

hoppp 1y ago

Not true that its not updated. They just released Deno 2.3 on the 1st of May. There was no such thing as a Deno rug pull, the author links to the use of http imports which are better used inside a map than directly in a file. Deno is fine and as a technology gets more mature it should get more boring.

animanoir 1y ago

[dead]

backspaces 1y ago

I wanted to create webdav servers hosted by glitch and cpanel. I ended up with exactly the same code on both, nice! Basically they both have node.js capabilities so I could use node.js webdav-server. But then I got the bright idea of using deno deploy which I've used in the past and loved, even using kv rather than a file system. It works (thanks chat) but it basically required creating my own version of the node.js webdav-server. Kinda annoying. The bottom line is that deno deploy is fighting a battle it can't win. Deno was the "better" node.js. And then it started integrating node capabilities, trying for a drop-in replacement of node. Nope. Sigh. I still love it for many simple projects but there's a reason node.js is, er, node.