7 ms·

I was super-excited about Deno right up until they threw away their earlier commitments and added backwards compatibility for node and all the shite that comes

I was super-excited about Deno right up until they threw away their earlier commitments and added backwards compatibility for node and all the shite that comes with it. The whole selling point for me was that deno was node without the bullshit and baggage, but they dropped that and basically just turned it into node with built in typescript support and a few other minor things like the permissions. Similar story with bun.sh - node backwards compatibility (although not using V8). Does anyone know of a server-side typescript scripting engine that is not trying to be backwards compatible with node?

diggan 1y ago
> Does anyone know of a server-side typescript scripting engine that is not trying to be backwards compatible with node? What's the point? If you're in love with static types, but have to do JavaScript because you're targeting the browser, I kind of understand why'd you go for TypeScript. But if you're on the backend, and don't need anything JS, why limit yourself to TypeScript which is a "Compile-to-JS" language? You control the stack, make another choice.
- Octoth0rpe 1y ago
  > why limit yourself to TypeScript which is a "Compile-to-JS" language? You control the stack, make another choice. Because some of us _like_ typescript, or at a minimum, have invested a significant portion of our careers learning ts/js. We want an ROI, we just don't want node/npm.
  - diggan 1y ago
    > Because some of us _like_ typescript, or at a minimum, have invested a significant portion of our careers learning ts/js. Right, makes sense. It also makes sense that most of those learnings are transferable, it's not like TypeScript is the only language with types. So your design/architecture skills can be used elsewhere too. Locking yourself into the ecosystem of one language, then asking other runtimes to adhere to your preference sounds like a sure way of getting disappointed, instead of being pragmatic and flexible to chose the right tool for the problem.
    - LoganDark 1y ago
      I haven't seen any true competition with TypeScript, at least for me. Go is unsound (Go slices...), Python is too high-level (even with mypyc), Rust is too low-level (in comparison to TS), and so on. It's not just "a language with types". Also, when I was writing a frontend and backend both in TS, I could literally share the exact same type definitions between them. Then I could use a compiler plugin (`typescript-is`) to validate on the server that payloads match the appropriate type. It was amazing and worked quite well, and I can't really see that being nearly as easy and seamless with anything else.
      - skydhash 1y ago
        I don’t understand the need to share types between frontend and backend. It’s like a strong incentive to take the wrong decisions down the lines instead of using the right data model for the domain.
        LoganDark 1y ago
        I mean JSON payload types.
      - diggan 1y ago
        > I could literally share the exact same type definitions between them. Then I could use a compiler plugin (`typescript-is`) to validate on the server that payloads match the appropriate type. It was amazing and worked quite well, and I can't really see that being nearly as easy and seamless with anything else. But isn't that benefit just because TypeScript does compile to JavaScript and is compatible with JavaScript? Remove that compatibility, and you wouldn't get that benefit anymore, right? And if you still can get that benefit, why wouldn't you be able to get that benefit with other languages too? It's not like TypeScript gives you some inherit benefit that makes it easier to convert to JavaScript, besides the fact that it's literally a "Compile-to-JS" language.
        LoganDark 1y ago
        > But isn't that benefit just because TypeScript does compile to JavaScript and is compatible with JavaScript? Remove that compatibility, and you wouldn't get that benefit anymore, right? JavaScript does make it easier to target both the web browser and Node.js, sure. But TypeScript also has a fairly mature type system and ecosystem (flaws in `tsc` itself notwithstanding). Not to say that no novel approaches are worth exploring, though; I just haven't seen one that rivals my TS experience yet. > And if you still can get that benefit, why wouldn't you be able to get that benefit with other languages too? That depends. In many other programming languages (such as ones that compile to WASM) it's also possible to have common code shared between server and client, but it's usually pretty inconvenient to actually get the code running in both environments. It's also possible to have a common interface definition and generate types for server and client from that definition, but that's still more complicated. Anyway I don't fault anyone for being disappointed that Deno fell into the Node.js compatibility trap. Pure TypeScript without that particular cruft is also something I was excited about. I also was excited to see what looked like some fair innovation (like their import mechanism and their sandboxing) but I don't know how that'll continue if Node.js compatibility ends up being too much of a time sink. I don't have very strong opinions because I've never really used Deno and I probably won't even bother at this point, but I definitely would not agree that this is just a problem of needing to use another programming language instead.
- jgalt212 1y ago
  maybe because async Python is painful, an async TypeScript / JS is the default.
  - diggan 1y ago
    Use another language where async isn't painful then? Since it's the backend, you have 100% control over what stack to chose, unless some other requirement gets in the way. And no, async isn't "the default" in at least JavaScript, not sure where you'd get that from.
    - jgalt212 1y ago
      > And no, async isn't "the default" in at least JavaScript, not sure where you'd get that from. My bad. I was conflating common idioms and actuality.
    - int_19h 1y ago
      It is the default in a sense that most libraries and increasingly many stdlib functions and even core language features require it. E.g. dynamic import() is async-only.
- koakuma-chan 1y ago
  Why would you use something other than a JS framework to build a web app back-end? You don't have to deal with OpenAPI or GraphQL, you can just use server actions.
  - diggan 1y ago
    Because there are other options available that might be better? Personally I'd chose Clojure for anything I have a choice with. Cargo culting a language like that does no one any favors.
    - koakuma-chan 1y ago
      > Personally I'd chose Clojure for anything I have a choice with. And then you would have to solve the problem of how to communicate with the client.
      - diggan 1y ago
        I dunno, HTTP works pretty well for me as a transport layer to communicate with clients. Otherwise Websockets. Not sure why you'd think that be a difficult thing?
        koakuma-chan 1y ago
        > Not sure why you'd think that be a difficult thing? You aren't suggesting to handwrite an HTTP API client, right? You would have to set up either OpenAPI which is a mess, or GraphQL which is also a mess. LMK if you have a better solution.
        diggan 1y ago
        What exactly is the problem you're encountering when trying to interact with HTTP APIs? If you really want to use OpenAPI for whatever reason, there are plenty of ways of doing that even in Clojure/Java, so I'm sure it's possible in other languages as well. But it's not like using OpenAPI or GraphQL are the only two options, if you're of that opinion I'm afraid you've drank way too much of the koolaid.
- ChocolateGod 1y ago
  > But if you're on the backend, and don't need anything JS, why limit yourself to TypeScript Why not use it? What high level programming language would you suggest instead with the same level of performance and ecosystem support.
  - liveoneggs 1y ago
    Java has (much) better performance and a bigger ecosystem. It has types and multiple alternative languages which target it (kotlin, scala, clojure, etc)
    - alabastervlog 1y ago
      Hell, last I checked PHP is still king of the server-side Web scripting languages, as far as real-world speed. Like, fast enough that you've gotta be pretty careful in Java or Go or whatever, or you'll end up slower than PHP. The way you make a scripting language fast is by getting the hell out of it and into C or C++ as fast as possible, and PHP's library ecosystem embraces that harder than just about any other scripting language, is the reason (I think). [EDIT] My point is mainly that Node's performance isn't really that impressive, in the field of "languages one might use to write server-side Web code". It beats absolute slugs like Python and Ruby handily, but past that... eh. And really, in its speed category you'd probably do just as well using either of those and paying a little more attention to things like network calls and database access patterns.
      - ChocolateGod 1y ago
        Google has poured millions of $ and 100s of developers into the development of V8 to get every last inch of speed and optimisation. As far as comparing it to AOT/non-GC languages of course it will always be slower, but I would struggle to believe it's slower than PHP other than in specific situations. Just one benchmark I could find https://benchmarksgame-team.pages.debian.net/benchmarksgame/index.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
  - coffeebeqn 1y ago
- lolinder 1y ago
  Because out of all the languages that stand a chance of being adopted at most workplaces, TypeScript is in my opinion the single most enjoyable to code in. It has an extremely expressive type system that gets out of your way and allows you to model almost anything you can come up with, it has great IDE integrations on both VS Code and JetBrains, it has strong first-class support for functional programming patterns. On top of all the things the language itself has going fit it, it allows me to write the same language on frontend and backend, which in my experience actually does make a huge difference in avoiding context switching and which also helps with avoiding code duplication. People like to sneer at TypeScript, but let's be honest: people like to sneer at anything that's popular enough. The fact is that no language that I enjoy better than TypeScript (which is already not a very long list) stands any chance of adoption in an average workplace.
  - coolcase 1y ago
    I'm torn between Go (nicer runtime) and Node (get to use TS for nicer types!)
    - lolinder 1y ago
      For me Go doesn't even come close. It's way too restrictive in what I can and can't do with it. I might feel differently if I worked with a large number of people who I didn't trust, but on small to medium teams composed of very senior people using Go feels like coding with one hand tied behind my back.
      - coolcase 1y ago
        I'm talking about the runtime though e.g. concurrency story being the main thing. Speed too. Easier multiform use. Memory footprint.
  - xnorswap 1y ago
    Well there's C# / .NET, which ticks off all of those boxes, even the functional syntax is well supported since it added pattern matching and people write a lot of fluent functional style anyway with LINQ. It also interops nicely with F#, so you can write a pure functional library in F# and call it from a C# program in the "functional core, imperative shell" style. It has an incredibly solid runtime, and a good type system that balances letting you do what you want without being overly fussy.
- mattlondon 1y ago
  Yep I control the stack, and I want it to be typescript. At this stage, I don't think anyone needs to try and persuade anyone why JavaScript and typescript are the Lingua Franca of software engineering. Performant, expressive, amazing tooling (not including node/npm), natively cross-platform. An absolute joy to code with. Why would anyone want to use anything else for general purpose coding? In my mind there are two alternative approaches in the current ecosystem: C++ where absolute 100% maximal performance is the overriding primary objective and be damned with the consequences, then for everything else just use Typescript
  - diggan 1y ago
    > anyone why JavaScript and typescript are the Lingua Franca of software engineering. I mean, it obviously isn't, although for web development, I'd probably agree with you. But regardless, zealots who hold opinions like this, where there is "one language to rule them all" is why discussing with TS peeps is so annoying. In your world, there is either C or TypeScript, but for the rest of us, we tend to use different languages depending on what problem we're solving, as they all have different strengths and drawbacks. If you cannot see any drawbacks with TypeScript, it's probably not because there aren't any, but you're currently blind to them. > Why would anyone want to use anything else for general purpose coding? Because you've tasted the world of having a REPL connected to your editor where you can edit running code live and execute forms. Just one example. There are so many languages available out there when you control your stack. I understand using JavaScript for frontend web stuff, because you have no other options, and I personally have nothing against JavaScript itself. But for the love of god, realize there is a world out there outside of your bubble, and some of those languages have benefits too.
    - hungryhobbit 1y ago
      Do you know what lingua franca means? https://survey.stackoverflow.co/2024/technology#most-popular-technologies-language-prof https://survey.stackoverflow.co/2024/technology#most-popular... ... JS is the most popular language in the world, per Stack Overflow.
user3939382 1y ago
I like JSDoc. Doesn’t have anything to do with Node and you get many of the same benefits without all the compilation toolchain complexity.
hyperpape 1y ago
> Does anyone know of a server-side typescript scripting engine that is not trying to be backwards compatible with node? I'm sure you can find other projects that are going to fail, but why do you want to? Node has lots of problems (I am basing this statement on the fact that it's a major tech project). None of them are sufficient to prevent it from being extremely widely used. To fix those problems in a product that will be used, it is not sufficient to provide something sort of like Node but without those problems. You either have to: 1. Provide a tool that requires a major migration, but has some incredible upside. This can attract greenfield projects, and sometimes edge out the existing tool. 2. Provide a tool with minimal migration cost, and without the same problems. Maybe this tool can replace the existing one. Ideally there will be other carrots (performance, reliability, ease of use). Such a tool can get people to migrate if there are enough carrots, and the migration cost is low enough. Deno was a classic example of messing this up. It's not #1 or #2, it has the worst of both worlds. The upside was that it did things "the right way", and the downside was that you couldn't run most code that worked on Node. This is the kind of approach that only attracts zealots and hobbyists.
skybrian 1y ago
Why do you treat adding a feature (npm compatibility) like you’re losing something? You don’t have to use any Node API’s in your app - Deno’s API’s are pretty comprehensive. You can also stick with the libraries available on jsr.io if you’re satisfied with what you can find there. If you want the developer experience of using something that’s not Node, you can still get it from Deno. But it turns out that few people care that much about purity, so it’s fortunate that they’re not relying on that.
- nicce 1y ago
  It is less about purity and more about why continue improving Deno APIs since now we can handle the stuff with Node or Node-powered library? Especially, if you are driven by profits. That means that all possible hours will be removed from the future Deno API development. Also, it does not force older libraries to adapt and make versions that use Deno API.
  - skybrian 1y ago
    What Deno API’s do you miss, compared to Node? It seems like they’re pretty built out? I’m looking forward to whatever they’re going to do instead of KV, which I tried and is too limited, even for a KV store. (64k values are too small.) Something like Cloudflare’s Durable Objects might be nice. You can’t “force” maintainers of old libraries to do anything. Deno never had that power. For people who are interested in supporting multiple alternate platforms, jsr.io seems pretty nice?
    - nicce 1y ago
      You should think Deno as standard library for JavaScript/TypeScript. Node was that. How well Node compares to Go/Python for example? We would like to see most used small Node libraries to merged at some level into Deno's standard library so that the amount of dependencies and deprecations would go downwards. > You can’t “force” maintainers of old libraries to do anything. Deno never had that power. For people who are interested in supporting multiple alternate platforms, jsr.io seems pretty nice? If enough people find Deno useful enough to skip some old libraries, maintainers are "forced", even thought Deno is not forcing anyone. If they do not adapt, then someone will just create a new library with better practices. In both cases there is pressure for better JS/TS evolution.
pier25 1y ago
> Does anyone know of a server-side typescript scripting engine that is not trying to be backwards compatible with node? Cloudflare Workers workerd comes to mind but it's fundamentally a different thing. https://github.com/cloudflare/workerd https://github.com/cloudflare/workerd It's not meant to be a generalist backend runtime and it provides almost zero batteries.
deleted 1y ago
[deleted]

diggan 1y ago

> Does anyone know of a server-side typescript scripting engine that is not trying to be backwards compatible with node? What's the point? If you're in love with static types, but have to do JavaScript because you're targeting the browser, I kind of understand why'd you go for TypeScript. But if you're on the backend, and don't need anything JS, why limit yourself to TypeScript which is a "Compile-to-JS" language? You control the stack, make another choice.

Octoth0rpe 1y ago
> why limit yourself to TypeScript which is a "Compile-to-JS" language? You control the stack, make another choice. Because some of us _like_ typescript, or at a minimum, have invested a significant portion of our careers learning ts/js. We want an ROI, we just don't want node/npm.
- diggan 1y ago
  > Because some of us _like_ typescript, or at a minimum, have invested a significant portion of our careers learning ts/js. Right, makes sense. It also makes sense that most of those learnings are transferable, it's not like TypeScript is the only language with types. So your design/architecture skills can be used elsewhere too. Locking yourself into the ecosystem of one language, then asking other runtimes to adhere to your preference sounds like a sure way of getting disappointed, instead of being pragmatic and flexible to chose the right tool for the problem.
  - LoganDark 1y ago
    I haven't seen any true competition with TypeScript, at least for me. Go is unsound (Go slices...), Python is too high-level (even with mypyc), Rust is too low-level (in comparison to TS), and so on. It's not just "a language with types". Also, when I was writing a frontend and backend both in TS, I could literally share the exact same type definitions between them. Then I could use a compiler plugin (`typescript-is`) to validate on the server that payloads match the appropriate type. It was amazing and worked quite well, and I can't really see that being nearly as easy and seamless with anything else.
    - skydhash 1y ago
      I don’t understand the need to share types between frontend and backend. It’s like a strong incentive to take the wrong decisions down the lines instead of using the right data model for the domain.
      - LoganDark 1y ago
        I mean JSON payload types.
    - diggan 1y ago
      > I could literally share the exact same type definitions between them. Then I could use a compiler plugin (`typescript-is`) to validate on the server that payloads match the appropriate type. It was amazing and worked quite well, and I can't really see that being nearly as easy and seamless with anything else. But isn't that benefit just because TypeScript does compile to JavaScript and is compatible with JavaScript? Remove that compatibility, and you wouldn't get that benefit anymore, right? And if you still can get that benefit, why wouldn't you be able to get that benefit with other languages too? It's not like TypeScript gives you some inherit benefit that makes it easier to convert to JavaScript, besides the fact that it's literally a "Compile-to-JS" language.
      - LoganDark 1y ago
        > But isn't that benefit just because TypeScript does compile to JavaScript and is compatible with JavaScript? Remove that compatibility, and you wouldn't get that benefit anymore, right? JavaScript does make it easier to target both the web browser and Node.js, sure. But TypeScript also has a fairly mature type system and ecosystem (flaws in `tsc` itself notwithstanding). Not to say that no novel approaches are worth exploring, though; I just haven't seen one that rivals my TS experience yet. > And if you still can get that benefit, why wouldn't you be able to get that benefit with other languages too? That depends. In many other programming languages (such as ones that compile to WASM) it's also possible to have common code shared between server and client, but it's usually pretty inconvenient to actually get the code running in both environments. It's also possible to have a common interface definition and generate types for server and client from that definition, but that's still more complicated. Anyway I don't fault anyone for being disappointed that Deno fell into the Node.js compatibility trap. Pure TypeScript without that particular cruft is also something I was excited about. I also was excited to see what looked like some fair innovation (like their import mechanism and their sandboxing) but I don't know how that'll continue if Node.js compatibility ends up being too much of a time sink. I don't have very strong opinions because I've never really used Deno and I probably won't even bother at this point, but I definitely would not agree that this is just a problem of needing to use another programming language instead.
jgalt212 1y ago
maybe because async Python is painful, an async TypeScript / JS is the default.
- diggan 1y ago
  Use another language where async isn't painful then? Since it's the backend, you have 100% control over what stack to chose, unless some other requirement gets in the way. And no, async isn't "the default" in at least JavaScript, not sure where you'd get that from.
  - jgalt212 1y ago
    > And no, async isn't "the default" in at least JavaScript, not sure where you'd get that from. My bad. I was conflating common idioms and actuality.
  - int_19h 1y ago
    It is the default in a sense that most libraries and increasingly many stdlib functions and even core language features require it. E.g. dynamic import() is async-only.
koakuma-chan 1y ago
Why would you use something other than a JS framework to build a web app back-end? You don't have to deal with OpenAPI or GraphQL, you can just use server actions.
- diggan 1y ago
  Because there are other options available that might be better? Personally I'd chose Clojure for anything I have a choice with. Cargo culting a language like that does no one any favors.
  - koakuma-chan 1y ago
    > Personally I'd chose Clojure for anything I have a choice with. And then you would have to solve the problem of how to communicate with the client.
    - diggan 1y ago
      I dunno, HTTP works pretty well for me as a transport layer to communicate with clients. Otherwise Websockets. Not sure why you'd think that be a difficult thing?
      - koakuma-chan 1y ago
        > Not sure why you'd think that be a difficult thing? You aren't suggesting to handwrite an HTTP API client, right? You would have to set up either OpenAPI which is a mess, or GraphQL which is also a mess. LMK if you have a better solution.
        diggan 1y ago
        What exactly is the problem you're encountering when trying to interact with HTTP APIs? If you really want to use OpenAPI for whatever reason, there are plenty of ways of doing that even in Clojure/Java, so I'm sure it's possible in other languages as well. But it's not like using OpenAPI or GraphQL are the only two options, if you're of that opinion I'm afraid you've drank way too much of the koolaid.
ChocolateGod 1y ago
> But if you're on the backend, and don't need anything JS, why limit yourself to TypeScript Why not use it? What high level programming language would you suggest instead with the same level of performance and ecosystem support.
- liveoneggs 1y ago
  Java has (much) better performance and a bigger ecosystem. It has types and multiple alternative languages which target it (kotlin, scala, clojure, etc)
  - alabastervlog 1y ago
    Hell, last I checked PHP is still king of the server-side Web scripting languages, as far as real-world speed. Like, fast enough that you've gotta be pretty careful in Java or Go or whatever, or you'll end up slower than PHP. The way you make a scripting language fast is by getting the hell out of it and into C or C++ as fast as possible, and PHP's library ecosystem embraces that harder than just about any other scripting language, is the reason (I think). [EDIT] My point is mainly that Node's performance isn't really that impressive, in the field of "languages one might use to write server-side Web code". It beats absolute slugs like Python and Ruby handily, but past that... eh. And really, in its speed category you'd probably do just as well using either of those and paying a little more attention to things like network calls and database access patterns.
    - ChocolateGod 1y ago
      Google has poured millions of $ and 100s of developers into the development of V8 to get every last inch of speed and optimisation. As far as comparing it to AOT/non-GC languages of course it will always be slower, but I would struggle to believe it's slower than PHP other than in specific situations. Just one benchmark I could find https://benchmarksgame-team.pages.debian.net/benchmarksgame/index.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
- coffeebeqn 1y ago
lolinder 1y ago
Because out of all the languages that stand a chance of being adopted at most workplaces, TypeScript is in my opinion the single most enjoyable to code in. It has an extremely expressive type system that gets out of your way and allows you to model almost anything you can come up with, it has great IDE integrations on both VS Code and JetBrains, it has strong first-class support for functional programming patterns. On top of all the things the language itself has going fit it, it allows me to write the same language on frontend and backend, which in my experience actually does make a huge difference in avoiding context switching and which also helps with avoiding code duplication. People like to sneer at TypeScript, but let's be honest: people like to sneer at anything that's popular enough. The fact is that no language that I enjoy better than TypeScript (which is already not a very long list) stands any chance of adoption in an average workplace.
- coolcase 1y ago
  I'm torn between Go (nicer runtime) and Node (get to use TS for nicer types!)
  - lolinder 1y ago
    For me Go doesn't even come close. It's way too restrictive in what I can and can't do with it. I might feel differently if I worked with a large number of people who I didn't trust, but on small to medium teams composed of very senior people using Go feels like coding with one hand tied behind my back.
    - coolcase 1y ago
      I'm talking about the runtime though e.g. concurrency story being the main thing. Speed too. Easier multiform use. Memory footprint.
- xnorswap 1y ago
  Well there's C# / .NET, which ticks off all of those boxes, even the functional syntax is well supported since it added pattern matching and people write a lot of fluent functional style anyway with LINQ. It also interops nicely with F#, so you can write a pure functional library in F# and call it from a C# program in the "functional core, imperative shell" style. It has an incredibly solid runtime, and a good type system that balances letting you do what you want without being overly fussy.
mattlondon 1y ago
Yep I control the stack, and I want it to be typescript. At this stage, I don't think anyone needs to try and persuade anyone why JavaScript and typescript are the Lingua Franca of software engineering. Performant, expressive, amazing tooling (not including node/npm), natively cross-platform. An absolute joy to code with. Why would anyone want to use anything else for general purpose coding? In my mind there are two alternative approaches in the current ecosystem: C++ where absolute 100% maximal performance is the overriding primary objective and be damned with the consequences, then for everything else just use Typescript
- diggan 1y ago
  > anyone why JavaScript and typescript are the Lingua Franca of software engineering. I mean, it obviously isn't, although for web development, I'd probably agree with you. But regardless, zealots who hold opinions like this, where there is "one language to rule them all" is why discussing with TS peeps is so annoying. In your world, there is either C or TypeScript, but for the rest of us, we tend to use different languages depending on what problem we're solving, as they all have different strengths and drawbacks. If you cannot see any drawbacks with TypeScript, it's probably not because there aren't any, but you're currently blind to them. > Why would anyone want to use anything else for general purpose coding? Because you've tasted the world of having a REPL connected to your editor where you can edit running code live and execute forms. Just one example. There are so many languages available out there when you control your stack. I understand using JavaScript for frontend web stuff, because you have no other options, and I personally have nothing against JavaScript itself. But for the love of god, realize there is a world out there outside of your bubble, and some of those languages have benefits too.
  - hungryhobbit 1y ago
    Do you know what lingua franca means? https://survey.stackoverflow.co/2024/technology#most-popular-technologies-language-prof https://survey.stackoverflow.co/2024/technology#most-popular... ... JS is the most popular language in the world, per Stack Overflow.

user3939382 1y ago

I like JSDoc. Doesn’t have anything to do with Node and you get many of the same benefits without all the compilation toolchain complexity.

hyperpape 1y ago

> Does anyone know of a server-side typescript scripting engine that is not trying to be backwards compatible with node? I'm sure you can find other projects that are going to fail, but why do you want to? Node has lots of problems (I am basing this statement on the fact that it's a major tech project). None of them are sufficient to prevent it from being extremely widely used. To fix those problems in a product that will be used, it is not sufficient to provide something sort of like Node but without those problems. You either have to: 1. Provide a tool that requires a major migration, but has some incredible upside. This can attract greenfield projects, and sometimes edge out the existing tool. 2. Provide a tool with minimal migration cost, and without the same problems. Maybe this tool can replace the existing one. Ideally there will be other carrots (performance, reliability, ease of use). Such a tool can get people to migrate if there are enough carrots, and the migration cost is low enough. Deno was a classic example of messing this up. It's not #1 or #2, it has the worst of both worlds. The upside was that it did things "the right way", and the downside was that you couldn't run most code that worked on Node. This is the kind of approach that only attracts zealots and hobbyists.

skybrian 1y ago

Why do you treat adding a feature (npm compatibility) like you’re losing something? You don’t have to use any Node API’s in your app - Deno’s API’s are pretty comprehensive. You can also stick with the libraries available on jsr.io if you’re satisfied with what you can find there. If you want the developer experience of using something that’s not Node, you can still get it from Deno. But it turns out that few people care that much about purity, so it’s fortunate that they’re not relying on that.

nicce 1y ago
It is less about purity and more about why continue improving Deno APIs since now we can handle the stuff with Node or Node-powered library? Especially, if you are driven by profits. That means that all possible hours will be removed from the future Deno API development. Also, it does not force older libraries to adapt and make versions that use Deno API.
- skybrian 1y ago
  What Deno API’s do you miss, compared to Node? It seems like they’re pretty built out? I’m looking forward to whatever they’re going to do instead of KV, which I tried and is too limited, even for a KV store. (64k values are too small.) Something like Cloudflare’s Durable Objects might be nice. You can’t “force” maintainers of old libraries to do anything. Deno never had that power. For people who are interested in supporting multiple alternate platforms, jsr.io seems pretty nice?
  - nicce 1y ago
    You should think Deno as standard library for JavaScript/TypeScript. Node was that. How well Node compares to Go/Python for example? We would like to see most used small Node libraries to merged at some level into Deno's standard library so that the amount of dependencies and deprecations would go downwards. > You can’t “force” maintainers of old libraries to do anything. Deno never had that power. For people who are interested in supporting multiple alternate platforms, jsr.io seems pretty nice? If enough people find Deno useful enough to skip some old libraries, maintainers are "forced", even thought Deno is not forcing anyone. If they do not adapt, then someone will just create a new library with better practices. In both cases there is pressure for better JS/TS evolution.

pier25 1y ago

> Does anyone know of a server-side typescript scripting engine that is not trying to be backwards compatible with node? Cloudflare Workers workerd comes to mind but it's fundamentally a different thing. https://github.com/cloudflare/workerd https://github.com/cloudflare/workerd It's not meant to be a generalist backend runtime and it provides almost zero batteries.

deleted 1y ago

[deleted]