You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
New to deno and trying to wrap my head around the state of the ecosystem before committing a large system. Hoping for some helpful insight.
I'm a strong believer in [mostly] static typing - more so after trying to rescue a large legacy javascript project recently that had absolutely no discipline or consistency at all in its use of objects. Structural discipline can definitely be a pain, and it doesn't have to be perfect, but its about the only thing holding back the ravages of time and evolution in a large code base. My feeling these days is that we either need to stop pretending that Javascript is engineerable and move to something else entirely, or we need to accept that good projects have long lifecycles and we need some help - which at the moment would be Typescript.
Having just confirmed that node v24 provides crash-only support for ESM modules, and that the fight with package typing hasn't substantially improved since I last looked five or six years ago, I've given up on node. If I understand the options today, it's either adopt deno or bail on the whole idea of a common client/server programming language and move to go on the server.1 Deno seems to support ESM and typescript well. I've been bitten by the async/await model in several real-world use cases, and I'm encouraged by the thought that the deno team has given to concurrency for such cases. Finally, I think that the ability to write the rare native code (Rust) plugin for performance critical services is likely to be a huge win if used judiciously.
Writing as a PL person, I'm confident that typescript will never be the preferred language of the web. It inherits all of the operational weaknesses of Javascript, it requires a bit more thought to write programs well, interop with JS code is never going to be totally seamless, and the "marketing" story for typescript is that you get to keep your javascript code. On the other hand, the people writing code in typescript are often writing better and more reliable code. That's a mixed bag, but for people trying to write robust systems it seems more of a win than a loss. I think it's possible that deno2's [very understandable] decision to embrace npm packages will come at the cost of a significant reduction in robustness.
So what's the sense of things these days? Is deno here to stay, or is it time to bite the bullet and abandon server-side javascript/typescript in favor of Go or something entirely different? I'm a big fan of typescript, but at the end of the day I need to build systems that last a while and survive evolution. I don't see a lot of people talking about that perspective in the node world (there are definitely some who do!). So I thought I'd ask what people think.
Footnotes
There's an argument that a single programming language simplifies dev hiring and reduces dev costs, but there aren't that many people who actually understand the full stack, and the ones who do are generally familiar with a range of programming languages. ↩
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
New to deno and trying to wrap my head around the state of the ecosystem before committing a large system. Hoping for some helpful insight.
I'm a strong believer in [mostly] static typing - more so after trying to rescue a large legacy javascript project recently that had absolutely no discipline or consistency at all in its use of objects. Structural discipline can definitely be a pain, and it doesn't have to be perfect, but its about the only thing holding back the ravages of time and evolution in a large code base. My feeling these days is that we either need to stop pretending that Javascript is engineerable and move to something else entirely, or we need to accept that good projects have long lifecycles and we need some help - which at the moment would be Typescript.
Having just confirmed that node v24 provides crash-only support for ESM modules, and that the fight with package typing hasn't substantially improved since I last looked five or six years ago, I've given up on node. If I understand the options today, it's either adopt deno or bail on the whole idea of a common client/server programming language and move to go on the server.1 Deno seems to support ESM and typescript well. I've been bitten by the async/await model in several real-world use cases, and I'm encouraged by the thought that the deno team has given to concurrency for such cases. Finally, I think that the ability to write the rare native code (Rust) plugin for performance critical services is likely to be a huge win if used judiciously.
Writing as a PL person, I'm confident that typescript will never be the preferred language of the web. It inherits all of the operational weaknesses of Javascript, it requires a bit more thought to write programs well, interop with JS code is never going to be totally seamless, and the "marketing" story for typescript is that you get to keep your javascript code. On the other hand, the people writing code in typescript are often writing better and more reliable code. That's a mixed bag, but for people trying to write robust systems it seems more of a win than a loss. I think it's possible that deno2's [very understandable] decision to embrace npm packages will come at the cost of a significant reduction in robustness.
So what's the sense of things these days? Is deno here to stay, or is it time to bite the bullet and abandon server-side javascript/typescript in favor of Go or something entirely different? I'm a big fan of typescript, but at the end of the day I need to build systems that last a while and survive evolution. I don't see a lot of people talking about that perspective in the node world (there are definitely some who do!). So I thought I'd ask what people think.
Footnotes
There's an argument that a single programming language simplifies dev hiring and reduces dev costs, but there aren't that many people who actually understand the full stack, and the ones who do are generally familiar with a range of programming languages. ↩
Beta Was this translation helpful? Give feedback.
All reactions