Deno's Decline
dbushell.com
dbushell.com
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.
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.
Respect. Everyone gets to love something. I’ve been through enough iterations of technology that I don’t attach like that anymore. But I find it interesting when people express these opinions. Can you share a little context? What background you’re from, industry your working in, what motivates your love?
Personally, I loathe javascript but love typescript.
On my hobby projects I tend to use script tags directly and don't bother with any of the build headaches I have at work, hobby projects are supposed to be fun.
Now that TS exists I never write plain JS except a few old legacy pages here and there.
Btw, looks like they did respond, so your effort wasn't in vain.
I currently work in the POS industry (day job) and Food Festival Payments (my business).
For me, when it's working, the Typescript development experience is bar-none for me. Typescript (Javascript) can run almost anywhere, or at least all the types of devices I would care about targeting. I enjoy using 1 language for backend and frontend development. I'm fully aware of the issues in the TS/JS ecosystem but I still really enjoy writing TS despite that. I feel like I get "tastes" of a perfect future where the issues I have are fixed and I hope the current state of affairs is just growing pains we look back on as we do the IE6 days (which I developed for, some people forgot how bad it used to be).
Being able to write backend, frontend (web, iOS, Android), all in the same language feels like a super power, especially when you can share code between them. Without Typescript (and Vue/Quasar) there is no way I'd be able to run by own company and support web/iOS/Android without cross-platform frameworks utilizing Typescript. I've written Java, I've written Swift, it's not that I can't write them it's just that I'm not good at either and I don't have the time to get better at either.
I haven't played much with other languages (aside from PHP, which I use for my day job) other than a todo/hello-world here and there because at the end of the day TS fills my needs and has something going for it that no other language does, it runs on the web natively. With WASM that might change (has changed?) but for now TS give me the best DX.
I'm not sure if that answers your question and I'm happy to expand further.
We ported our webapps from JS to Typescript a while back, and I hate having to read untyped code, even (maybe especially) the stuff written by our best coders, even my own code. You have to run the code in your head just to understand the shape of "order".
I would never go back, I cannot fathom the resistance in the JS community.
Big mistake. my project really required me to have so many custom deno commands like deno run -A --sloppyimports and so much more and that it was really causing me to be unable to find previous history of commands (something which I have in zshrc because of it for some reason)
I really regret not using bun for it. Bun is faster & to me it doesn't matter that much because deno is boasting that it can run nextjs, well quite frankly, I don't use nextjs, I use sveltekit which works on literally every single platform.
And also instead of deno cloud, I personally prefer cloudflare workers with sveltekit. It has been a breeze of mind to be honest, but I am not sure if cloudflare workers is 100% compatible with nodejs/bun but my deployments have always worked for some reason.
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).
Use the right tool. Right means reasonable and productive. Let folk who don't ship argue stack. While they're flapping, you are sailing.
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.
Eventually Python became a better alternative, however for me it was mostly because I had enough of sigils, the way reference works and the hacky way of doing objects with blessed references.
And as the sibling comment points out CPAN.
The previous generation of Nokia NetAct infrastructure software as originally written for HP-UX, was a mix of CORBA C++ and Perl, and by 2007, it was still the main implementation. Nowadays it has been rewriten into Java.
I hope it doesn't die, but I always thought the business model was going to be tough. Bun seems to be eclipsing Deno for sure, mainly due to its embrace of any and every syntax/feature/ecosystem, which makes me sad because Deno's opinionated stance was what had me so excited to begin with
We shall see
Theoretically a better approach could be (if we are talking about serverless providers supporting bun) is that we can compile it into bytecode and then just run a command with bun to run that bytecode and it would be faster. And to be honest, this feature is also available in deno and maybe its even coming to node IIRC, but bun supports bytecode in the executable whereas deno doesn't. I am never trying deno again, I liked their security model but it has really messed up with my ~/history and I had to type so much context to get suggestions and simple minute changes (lets say I don't want --A and I want in one command --net-only and in the second command some different flag
and now I can't really see my suggestions, I don't know maybe a skill issue but when I wrote a deno code which required me to write code and I had atleast ran it 50 times while developing it. Yeah it was a nightmare, never trying that again
Which- this is one of my favorite things about this ecosystem, and especially these projects! It's Just Code, with a single system dependency, and you can run it in one place just as easily as any other
But that means you can't corral devs into your own hosting service, which makes it a tough business to make money in
IMO these kinds of projects just can't work as a startup. They need to be either community-led, or incubated within a larger business that uses them instead of trying to sell them
Hopefully one or both can make a transition if/when their business model fails to take off
> 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.
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.
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.
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.
Deno is still better than node and its sort of a swiss army knife for developing servers in Typescript fast.
That is pretty much the standard problem across programming.
In contrast, Deno gambled that Node compatibility wasn't critical and lost. Now they're backpedaling.
I’m biased but learning difficulty aside, Rust is very optimal as a language.
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.
Haskell is still struggling with what exactly to do about Linear types (and get the whole ecosystem on board), and strictness. While lazy-by-default is really amazing for certain things, Rust's approach just wins out for production code, I think.
> 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.
This is true, until you have languages with truly novel features, like an implementation of affine types, and strong compilers.
Even just the difference between errors-as-values versus exceptions is a huge difference in my book -- Rust code gives you a clear chance/requirement to handle every possible error.
F# is even simpler but you have the entire C# and CLR complexity that you need to grok to read it.
Same with Scala, Kotlin and others... I find for people coming from not CLR or JVM or etc Rust has less to worry about.
I do agree all this also means a high intial learning curve but I just find myself liking the language more than others.
Honestly OCaml's ppx and multicore churn scared me away. And for performance focused stuff Rust is the best ML-curious language around, atleast for me and a lot of other people.
I personally like F# a lot too it might be the better language if only Microsoft invested in it more.
Kotlin and Scala on the other than are just imho too tightly coupled with JVM. I have seen AoT attempts for both but man are they not good enough.
Personally I just like the ethos of Rust more for some reason. The idea of safety through type system while ensuring we don't have any significant loss of performance is just awesome to me.
And I like to think a lot of people share that opinion.
I might be wrong, and so can a lot of other people but I just want to see the idea of Rust succeed.
To be clear I write a lot of Go and like Zig and Haskell as well but Rust just feels more practical. I am not sure what it is...
And I have checked I am not any less productive in Rust than in Go. Or anything else including C#
GraalVM exists, no need for the snowflake projects from Scala and Kotlin native.
The JVM and CLR completely, is exactly what makes them having great IDE tooling and libraries.
These aren't the kind of folks rushing in to add Bun/Deno into their stacks.
import { SystemDBus } from "npm:@clebert/node-d-bus@1.0.0";
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.
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.
They use Deno for their edge scripting feature: https://bunny.net/blog/introducing-bunny-edge-scripting-a-be...
fun fact I was considering making a bun-first CLI framework and current working name was Bunny
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
There wasn't really a rugpull in the 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.
Future devs will look back and wonder why we randomly let Guillermo Rauch ruin the ecosystem for a few years.
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.
Many of those SaaS vendors have partner agreements with Vercel.
Talking about Next: Before there was only Angular with universal rendering that could do SSR / ISR. Second one was Next and den Nuxt. SSR or ISR is often a must have in enterprise projects. If it is not a internal app, you have todo SSR. And with a modern architecture, you decouple the frontend. So, no other options. Recently we have also Remix, Astro and Svelte Kit for that. And the market get much more diverse, what i like.
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.
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/ for more.
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
The title should be, if anything, “the decline of an after thought deployment tool”.
https://www.reddit.com/r/Deno/comments/1g5mu0l/thats_all_goo...
https://www.reddit.com/r/Deno/comments/1dpexwv/dependency_vu...
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.
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). But actual SQLite support did not come until v2.2 (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).
- 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?
Really?
Why use Typescript at all, in that case?
I really do not know
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.
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?
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.
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.
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?
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.
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?
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.
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.
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
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.
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.
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.
I cherish those times of calmer waters.
At the time I had high hopes for Hapi.js (https://hapi.dev), created by Walmart folks.
But I don't hear much about it these days.
No, the Deno runtime gets regular updates. I don’t think you read the article lol.
Or when JS devs suddenly discover concepts like "serverside rendering" and reinvent PHP and ASP.NET.
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.
- 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
JavaScript tooling makes Python tooling fragmentation look sane.
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.
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!
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.
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.
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.
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.
> Express based project
Ahh, so you use a monolith in a lambda. I should have gone this route. I was concerned about package size (due to lambda limits) and so went the "one function per endpoint" route instead. That seemed to be what AWS was saying you should do but it really screws you in a number of ways, size is the only place where it really helps. Provisioned lambdas, for example, are so much better for a monolith.
Did you not have size issues putting all the code in 1 package? That was a real limit I hit when I was (naively) packaging all my code for every endpoint instead of just the handler and the code it needed. I'd be nervous of pushing up against the limit. I guess the escape hatch is moving to a docker container on lambda since that gives you 10GB.
> The only thing I kind of dislike is decommissioning of older nodejs runtimes so they aren't available at all for new Lambdas anymore.
Yep, I've been burned by this and forced to update.
One more question, how do you handle local development? Do you just run Express directly? That's one reason I've leaned into the serverless frameworks out there. My function-per-endpoint setup doesn't have any default scaffolding, running via lambda is the only way to run the code (or one of the project that tries to replicate lambda locally). SST has been the best on this front since you deploy your dev environment like normal (spin up real queues, etc) but the lambdas are just proxying the request to the code running locally on your computer. This has resulted in the least "gotchas" when it comes time to deploy (though arch differences are always a blast).
The only time I have problems with Lambdas growing too large is when I try to include a really big payload that includes something like Chrome for headless screenshots, or FFMPEG, or other large binary programs. But for normal Lambda functions I don't have any size issues. Recently when trying to get headless Chrome working in Lambda, I had to boot up EC2 running AWS Linux, and create a .zip file there with library files that were missing in Lambda, then .zip up everything and upload to S3 and then import the .zip into Lambda. After this, I can modify my .js files locally and have my toolchain upload the changes to Lambda to update the Lambda. But this time the payload was too large for importing into a Lambda, and too big for a Lambda layer. The solution was saving the .zip file with Chrome in it to an S3 bucket, and when the Lambda machine starts up, it first downloads the .zip file to /tmp, unzips it, and now the Lambda has the Chrome binaries in the /tmp folder. This bypasses the size limits associated with Lambda. It's rare that I need to do this, and it's not fun, but there are always going to be some edge cases like this with Lambda and getting large architecture specific binaries running in Lambda.
I actually put many different functions into a single Lambda, and I call the Lambda with a specific action parameter to perform a specific function.
Local development... when I create a Lambda function I may add some functionality so I can also run it on the command line if I'm still early in developing a complex function. But most of the time I just use my self-built toolchain which watches my local code for changes, then creates/updates the Lambda in AWS, which takes about 2 to 5 seconds typically. Then I test the code as it runs inside AWS. If I didn't have internet access, then it's impossible to develop in this way, but that's almost never the case.
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.
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.
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.
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.
How are bun and nodejs on that side?
It's just straight up not a problem other authors are thinking about regularly in other programming languages, because we don't have left-pad crises in other programming language ecosystems.
It is hard to deny that Go isn't much more performant on the development end. Someone who is inexperienced might be slowed down due to that inexperience negating the performance boost, sure, but when one is concerned about developer performance they will be happy to incur the small upfront cost to become experienced for the bigger payoff later.
(It is debatable if Go is really the king of developer performance, you might do even better with another language, but what is certain is that it is not Javascript/Typescript)
The recent tsc port from TS to Go is a good example of that. The TypeScript code in the compiler relied a lot on polymorphism, which made it really hard for the JIT to do a good job.
The Go port enabled them to 'rewrite' it keeping the logic more-or-less 1:1 and land a good performance increase. IMO it was a good decision, specially the language choice, and much saner than what a JIT-friendly TS compiler would be.
I'm a bit of an outsider here, I've only run a little Node in production in the past, and used it on and off for ~13 years. My take is that these projects all get some hype specifically because Node.js is not mature.
I've got a hobby project that has a bit of Node in it, and it very plainly difficult (Which imports am I using? Not the good one. Which language am I writing? Not the typed one. Which package manager do I use? etc). Getting a new project set up well takes time and effort, it is not the default that Node gives you (at least in ~early 2024 maybe?).
I can really get behind the "not another JS rugpull" idea, but I also see why everyone is constantly wanting to get off Node itself onto something Node-like that solves their problems.
Just ignore it all and you're fine. And definitely ignore the people who keep changing things on you.
If it doesn't help me ship more product, I do not care.