6 ms·

> 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 wi

by 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.
  - rtpg 1y ago
    Typescript's type system is uniquely good for preventing types in "bog standard enterprise code". No other language comes close to it. Two words: untagged unions. And of course all the other utilities it provides. It's extremely good! Shame about it being coupled to Javascript.
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.

by diggan 1y ago

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.
- rtpg 1y ago
  Typescript's type system is uniquely good for preventing types in "bog standard enterprise code". No other language comes close to it. Two words: untagged unions. And of course all the other utilities it provides. It's extremely good! Shame about it being coupled to Javascript.

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.