9 ms·

"I really don't see how anyone choses nodejs/deno to anything." This is going to sound mean but I don't really know how to phrase it more nicely. People buildi

"I really don't see how anyone choses nodejs/deno to anything." This is going to sound mean but I don't really know how to phrase it more nicely. People building backends in js/ts are doing so because either they, or a critical mass of the people they expect to code in it, don't know any better backend languages. I don't mean for this to be judge-y. People have different skillsets. A nodejs backend can be the right choice if you're a full-stack dev or a solo dev and you mainly know js and you get a lot of agility and correctness by using what you know instead of trying to use a "better" choice but one that you yourself are less likely to use correctly or quickly in your own use case. It can also be the right choice if you're a big backend java/etc guru but you know you want to set this thing up but then just monitor/oversee frontend/fullstack devs being the ones who do incremental modifications to it. But yeah - without additional outside constraints and everything else being equal, it doesn't make a lot of sense to use nodejs as opposed to basically anything more boring - be it java, rails, etc. The thing that surprises me the most about node based backends is that they forego both the platform maturity and static-safety of java AND the ridiculous amount of batteries included into django and rails, just to be able to use javascript, of all things. What you could rails-g in a minute you could instead spend a day looking for an npm package that won't be abandoned in a month or spend eternity rolling your own everything and then maintaining it.

legerdemain 4y ago
This comment is presumptuous, dismissive, and also wrong. People who write application-like front ends in React (etc.) want back ends that can interoperate with those front ends. They accomplish things like built-time code generation, static server-side rendering, and other kinds of code transformation that are difficult and flaky without a back end that can understand JS. I have looked for non-tinkertoy solutions in Java and Go. There aren't any, and senior people in those communities are hostile to the very idea. (Maybe remembering Java Nashorn?) Maybe the only people friendly to the idea of interoperable back ends are Rust people (where you have libraries like Yew/Sycamore/Dioxus/Leptos that actively imitate JS frameworks). But yes, your claim is that the only reason to write JS back ends is ignorance and enfeeblement is ignorant and repugnant.
- zozbot234 4y ago
  > want back ends that can interoperate with those front ends. You can ingest and emit JSON in any language. You can even compile backend-friendly code to run in JS on the frontend, via emscripten (and increasingly, Wasm), which will output very lean and JIT-friendly code. The usual "isomorphic" case for backend.js is no less 'presumptuous' or 'dismissive' than the comment you're pointing to and criticizing here.
  - legerdemain 4y ago
    > You can ingest and emit JSON in any language. How is this relevant? Serving a JS application to a client is not like serving a JSON API. > You can even compile backend-friendly code to run in JS on the frontend, via emscripten (and increasingly, Wasm), which will output very lean and JIT-friendly code. Not in my experience. Compared to front-to-back JS, shipping your applications as WASM ends up with downloads and memory footprints that are several times larger than the same application in ordinary JS, and this matters a lot for slower networks and mobile clients. Edit: not to mention that Go has a very limited WASM story, so your "realistic" choices for shipping back end code to the front end are C++ and Rust.
    - d-z-m 4y ago
      > How is this relevant? Serving a JS application to a client is not like serving a JSON API. In some JS applications, the way the frontend code communicates with the backend is via JSON API endpoints. I believe GP was just pointing out that you can write that JSON API in any language you want. > not to mention that Go has a very limited WASM story, so your "realistic" choices for shipping back end code to the front end are C++ and Rust. Can you elaborate on this? How is it limited in comparison to say, Rust.
      - legerdemain 4y ago
        My understanding is that to get reasonable WASM file sizes, one must use tinygo (a C reimplementation). tinygo is a WIP, although I wish I could find a better updated description of what's missing than this page on their site: https://tinygo.org/docs/reference/lang-support/ https://tinygo.org/docs/reference/lang-support/
CuriouslyC 4y ago
While it doesn't have the batteries, typescript's gradual typing is much nicer than python's, so for some use cases it's a better language. All languages come with tradeoffs in terms of performance, development/maintenance cost and ease of hiring. Most businesses only care superficially about performance, which leaves developer productivity and ease of hiring. Node/typescript isn't terrible in terms of developer productivity, and it's got the best hiring story of any language. Python is good in both those ways too, but since you already need a javascript hiring pipeline for the client it's easier just to use node and hire full stack devs.
- worik 4y ago
  > typescript's gradual typing is much nicer than python's, It is not Node V. Python, but Node V Java Python is a terrible choice as a backend, too. It has a place as a scripting language, but so often it is used to build complete systems. They suck.
  - xyzzy4747 4y ago
    Python is suitable if you don't care about performance, type safety, or async programming. That is to say, it's usually not a good choice.
strokirk 4y ago
Is there any statically typed HTML templating language, for non-node languages? Genuine question.
- steveklabnik 4y ago
  crates.io for Rust has 213 crates tagged "template-engine" https://crates.io/categories/template-engine https://crates.io/categories/template-engine handlebars, terra, askama, and maud are examples I recognize from high up on that list. Maud example: (chosen because it's the most "native Rust" in a sense and is designed for HTML specifically so I believe it's the closest to what you're asking for) html! { h1 { "Hello, world!" } p.intro { "This is an example of the " a href="https://github.com/lambda-fairy/maud" { "Maud" } " template language." } } https://maud.lambda.xyz/ https://maud.lambda.xyz/
helsontaveras18 4y ago
That’s an interesting comment. I chose Node not because I love it, but it’s the easiest to hire for as a startup. I hate configuring typescript and having to deal with bundlers, package.json, esbuild, etc. But Deno and Bun are just around the corner. What we need is to get rid of this a la carte mentality around tooling and just give everyone Typescript, batteries included, and make it fast. Then Node really isn’t that bad anymore.
tekkk 4y ago
Heh heh, well maybe in some cases but since TS/JS is kinda the lowest common denominator in web development, it's just the most convenient choice. We humans are limited in our capacity to learn and take time to get good at things. So it makes a lot of sense to pick a tool that can be used to build the whole app with. And for all of its faults, NodeJS can be fun compared to something like Java which feels more like doing taxes. Maybe it's the danger. Maybe it's the fact there are so many packages and libraries out there - everyone can contribute! Who knows, but I won't waste my time learning say Rails just to use a "better" backend framework. It's good enough even though I know better. There are way more important things.
nazka 4y ago
I love Rails and if it was continuing to grow even so slightly it will be my go to for sure. But unfortunately it has been slowly declining for a long time… Many moving to Go, Elixir, Rust, and elsewhere. It was by far the best dev experience with a framework I ever had. The last version still looks great. But realistically unless if you plan to do a rewrite, which is never a good idea, it may not be the best option out there. Even more with having to get people onboard for the next years ahead and the ecosystem too. I am looking for a framework to use and see grow a lot for at least the next 4 years with having hiring in mind. Spring boot is great but it does have its quirks. Config and plumbing for instance compare to Nest or Rails doesn’t makes it the best and fastest dev experience. And all the Java extra stuff and it’s ecosystem makes it solid but also old compare to what you can see happening in other languages. I have Quarkus in my mind though. It looks amazing in dev experience with lib like panache, resteasy etc… and performance are amazing too which comes as a bonus. But there is no dev out there. And I feel that in Java people want to work on Spring Boot because spending X years working on Spring Boot are more valuable in their career than X years on something else that is not really the de facto standard of the industry. So ya not great for hiring talented people… But NestJS with the JS/TS ecosystem start to be very close to what Rails was in the past. Stuff like Prisma for instance makes everything a breeze. There is almost always a package for the thing you want. Great at websocket too. Can do GraphQL if it’s your thing. Same language as the front end, Nextjs, etc. One of the most performant dynamic languages. And interesting things happening like Deno or using Rust with it. So there are quite some perks to it. Can’t speak about Django though. But I am wondering how is the dev experience like when we use it for real projects. I am starting a new project/startup and wondering which one to start it with between all these technologies. And after looking for a long time I can see that they really all comes with their pros and cons.
- gls2ro 4y ago
  Ruby is growing (you can say "growing back") starting at least from 2020/2021 with a lot of things happening in 2022 and looking at a very exciting 2023. Hotwire is an exciting technology coming out of Ruby/Rails ecosystem. Rails 7 was an important release bringing a lot of great features and Rails 7.1 looks even better. Ruby has a lot of nice advances as language starting with 2.7 and continuing to the recent release of 3.2. Check the recent changes at https://rubyreferences.github.io https://rubyreferences.github.io IMHO Ruby and its eco-system is the perfect mix of tech that works while trying to get right some of the most important modern approaches. Specifically regarding the > But realistically unless if you plan to do a rewrite, which is never a good idea, it may not be the best option out there This is not directed to you but more a general rant :) I hate with passion (and yes I am biased) this line of thinking because it is not true in maybe 90% of the cases. And it is not true when one says that about almost any established language that should be used where it fits (or where it is used the most). What I write below applies to an average company mostly doing Saas/CRUD/web apps. If you are working at FAANG or FAANG-like companies maybe this does not apply to you. Be sincere: - Say that you want to pick something that will increase your hiring skills if you are a developer, or that you want to brag to your friends that you are using what Amazon/Google is using or that you want to speak to conferences about the latest big tech - Or say that you don't like Ruby and just want to choose something else. That is fine. - Or if you are a director of engineering/leader/manager say that you can hire JS developers cheaper or that offering a cool/hype technology is the only way to attract new people or that you want to feel safe in front of board members/GM/CEO by saying we failed to solve this even if we use everything that FAANG uses. But please don't say that you don't choose Rails because you might grow so much that you will need to rewrite. I don't know one single example where a company died because they choose Rails. Just the decision to rewrite a product on its own is a high risk of failing. It does not matter the from:, to: parameters. And again I need to say to anyone thinking to start a project in Ruby/Rails but thinking they need to choose otherwise: You are not Google, nor Netflix, Amazon, .... You (probably) don't need anything from their tools or architecture that makes them offer concurrent services to hundred of millions of users. Try to have 10k users first and then I think you will probably have the mindset + management experience to hire Ruby devs or to help a new hire to learn Ruby.
Zababa 4y ago
Node runs circles around Django/Rails, and batteries included in Javascript tend to be pushed to either the frontend or the database. Node backend tends to be thinner, compared to Java/Django/Rails. Some people don't know any better, some have good reasons of doing this.

legerdemain 4y ago

This comment is presumptuous, dismissive, and also wrong. People who write application-like front ends in React (etc.) want back ends that can interoperate with those front ends. They accomplish things like built-time code generation, static server-side rendering, and other kinds of code transformation that are difficult and flaky without a back end that can understand JS. I have looked for non-tinkertoy solutions in Java and Go. There aren't any, and senior people in those communities are hostile to the very idea. (Maybe remembering Java Nashorn?) Maybe the only people friendly to the idea of interoperable back ends are Rust people (where you have libraries like Yew/Sycamore/Dioxus/Leptos that actively imitate JS frameworks). But yes, your claim is that the only reason to write JS back ends is ignorance and enfeeblement is ignorant and repugnant.

zozbot234 4y ago
> want back ends that can interoperate with those front ends. You can ingest and emit JSON in any language. You can even compile backend-friendly code to run in JS on the frontend, via emscripten (and increasingly, Wasm), which will output very lean and JIT-friendly code. The usual "isomorphic" case for backend.js is no less 'presumptuous' or 'dismissive' than the comment you're pointing to and criticizing here.
- legerdemain 4y ago
  > You can ingest and emit JSON in any language. How is this relevant? Serving a JS application to a client is not like serving a JSON API. > You can even compile backend-friendly code to run in JS on the frontend, via emscripten (and increasingly, Wasm), which will output very lean and JIT-friendly code. Not in my experience. Compared to front-to-back JS, shipping your applications as WASM ends up with downloads and memory footprints that are several times larger than the same application in ordinary JS, and this matters a lot for slower networks and mobile clients. Edit: not to mention that Go has a very limited WASM story, so your "realistic" choices for shipping back end code to the front end are C++ and Rust.
  - d-z-m 4y ago
    > How is this relevant? Serving a JS application to a client is not like serving a JSON API. In some JS applications, the way the frontend code communicates with the backend is via JSON API endpoints. I believe GP was just pointing out that you can write that JSON API in any language you want. > not to mention that Go has a very limited WASM story, so your "realistic" choices for shipping back end code to the front end are C++ and Rust. Can you elaborate on this? How is it limited in comparison to say, Rust.
    - legerdemain 4y ago
      My understanding is that to get reasonable WASM file sizes, one must use tinygo (a C reimplementation). tinygo is a WIP, although I wish I could find a better updated description of what's missing than this page on their site: https://tinygo.org/docs/reference/lang-support/ https://tinygo.org/docs/reference/lang-support/

CuriouslyC 4y ago

While it doesn't have the batteries, typescript's gradual typing is much nicer than python's, so for some use cases it's a better language. All languages come with tradeoffs in terms of performance, development/maintenance cost and ease of hiring. Most businesses only care superficially about performance, which leaves developer productivity and ease of hiring. Node/typescript isn't terrible in terms of developer productivity, and it's got the best hiring story of any language. Python is good in both those ways too, but since you already need a javascript hiring pipeline for the client it's easier just to use node and hire full stack devs.

worik 4y ago
> typescript's gradual typing is much nicer than python's, It is not Node V. Python, but Node V Java Python is a terrible choice as a backend, too. It has a place as a scripting language, but so often it is used to build complete systems. They suck.
- xyzzy4747 4y ago
  Python is suitable if you don't care about performance, type safety, or async programming. That is to say, it's usually not a good choice.

strokirk 4y ago

Is there any statically typed HTML templating language, for non-node languages? Genuine question.

steveklabnik 4y ago
crates.io for Rust has 213 crates tagged "template-engine" https://crates.io/categories/template-engine https://crates.io/categories/template-engine handlebars, terra, askama, and maud are examples I recognize from high up on that list. Maud example: (chosen because it's the most "native Rust" in a sense and is designed for HTML specifically so I believe it's the closest to what you're asking for) html! { h1 { "Hello, world!" } p.intro { "This is an example of the " a href="https://github.com/lambda-fairy/maud" { "Maud" } " template language." } } https://maud.lambda.xyz/ https://maud.lambda.xyz/

helsontaveras18 4y ago

That’s an interesting comment. I chose Node not because I love it, but it’s the easiest to hire for as a startup. I hate configuring typescript and having to deal with bundlers, package.json, esbuild, etc. But Deno and Bun are just around the corner. What we need is to get rid of this a la carte mentality around tooling and just give everyone Typescript, batteries included, and make it fast. Then Node really isn’t that bad anymore.

tekkk 4y ago

Heh heh, well maybe in some cases but since TS/JS is kinda the lowest common denominator in web development, it's just the most convenient choice. We humans are limited in our capacity to learn and take time to get good at things. So it makes a lot of sense to pick a tool that can be used to build the whole app with. And for all of its faults, NodeJS can be fun compared to something like Java which feels more like doing taxes. Maybe it's the danger. Maybe it's the fact there are so many packages and libraries out there - everyone can contribute! Who knows, but I won't waste my time learning say Rails just to use a "better" backend framework. It's good enough even though I know better. There are way more important things.

nazka 4y ago

I love Rails and if it was continuing to grow even so slightly it will be my go to for sure. But unfortunately it has been slowly declining for a long time… Many moving to Go, Elixir, Rust, and elsewhere. It was by far the best dev experience with a framework I ever had. The last version still looks great. But realistically unless if you plan to do a rewrite, which is never a good idea, it may not be the best option out there. Even more with having to get people onboard for the next years ahead and the ecosystem too. I am looking for a framework to use and see grow a lot for at least the next 4 years with having hiring in mind. Spring boot is great but it does have its quirks. Config and plumbing for instance compare to Nest or Rails doesn’t makes it the best and fastest dev experience. And all the Java extra stuff and it’s ecosystem makes it solid but also old compare to what you can see happening in other languages. I have Quarkus in my mind though. It looks amazing in dev experience with lib like panache, resteasy etc… and performance are amazing too which comes as a bonus. But there is no dev out there. And I feel that in Java people want to work on Spring Boot because spending X years working on Spring Boot are more valuable in their career than X years on something else that is not really the de facto standard of the industry. So ya not great for hiring talented people… But NestJS with the JS/TS ecosystem start to be very close to what Rails was in the past. Stuff like Prisma for instance makes everything a breeze. There is almost always a package for the thing you want. Great at websocket too. Can do GraphQL if it’s your thing. Same language as the front end, Nextjs, etc. One of the most performant dynamic languages. And interesting things happening like Deno or using Rust with it. So there are quite some perks to it. Can’t speak about Django though. But I am wondering how is the dev experience like when we use it for real projects. I am starting a new project/startup and wondering which one to start it with between all these technologies. And after looking for a long time I can see that they really all comes with their pros and cons.

gls2ro 4y ago
Ruby is growing (you can say "growing back") starting at least from 2020/2021 with a lot of things happening in 2022 and looking at a very exciting 2023. Hotwire is an exciting technology coming out of Ruby/Rails ecosystem. Rails 7 was an important release bringing a lot of great features and Rails 7.1 looks even better. Ruby has a lot of nice advances as language starting with 2.7 and continuing to the recent release of 3.2. Check the recent changes at https://rubyreferences.github.io https://rubyreferences.github.io IMHO Ruby and its eco-system is the perfect mix of tech that works while trying to get right some of the most important modern approaches. Specifically regarding the > But realistically unless if you plan to do a rewrite, which is never a good idea, it may not be the best option out there This is not directed to you but more a general rant :) I hate with passion (and yes I am biased) this line of thinking because it is not true in maybe 90% of the cases. And it is not true when one says that about almost any established language that should be used where it fits (or where it is used the most). What I write below applies to an average company mostly doing Saas/CRUD/web apps. If you are working at FAANG or FAANG-like companies maybe this does not apply to you. Be sincere: - Say that you want to pick something that will increase your hiring skills if you are a developer, or that you want to brag to your friends that you are using what Amazon/Google is using or that you want to speak to conferences about the latest big tech - Or say that you don't like Ruby and just want to choose something else. That is fine. - Or if you are a director of engineering/leader/manager say that you can hire JS developers cheaper or that offering a cool/hype technology is the only way to attract new people or that you want to feel safe in front of board members/GM/CEO by saying we failed to solve this even if we use everything that FAANG uses. But please don't say that you don't choose Rails because you might grow so much that you will need to rewrite. I don't know one single example where a company died because they choose Rails. Just the decision to rewrite a product on its own is a high risk of failing. It does not matter the from:, to: parameters. And again I need to say to anyone thinking to start a project in Ruby/Rails but thinking they need to choose otherwise: You are not Google, nor Netflix, Amazon, .... You (probably) don't need anything from their tools or architecture that makes them offer concurrent services to hundred of millions of users. Try to have 10k users first and then I think you will probably have the mindset + management experience to hire Ruby devs or to help a new hire to learn Ruby.

Zababa 4y ago

Node runs circles around Django/Rails, and batteries included in Javascript tend to be pushed to either the frontend or the database. Node backend tends to be thinner, compared to Java/Django/Rails. Some people don't know any better, some have good reasons of doing this.