Hacker News Reader

Comment by ozten | Hacker News Reader

NodeJS kind of muddies the waters. It ate a lot of use cases that would have previously been done in Java. That created conflict between backend teams that wanted statically typed code and a "boring" tech choice against "full stack" developers creating a backend service.

I think Rust will see a lot of adoption in web services that are glorified CRUD APIs. It would have been a poor choice to do many of these workloads in this in C or C++ (despite the data point of Amazon 1.0 LOLz).

View on HN

I've really tried to give js/ts in backend a go. Both by nodejs and deno. And by kickstarting my own projects as well as diving into experienced nodejs developers' code.

I really don't see how anyone choses nodejs/deno to anything.

Java imo gives you much less trouble, is more stable, has a working (!!!) Unit testing setup and exceptional runtime.

Next on my list is to give rust a go, since I'm intrigued by its features, but if I was to go fast I'd go with java any day.

"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.

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.

To clarify my point, I think nodejs is great for the backend part of the view layer and to proxy requests to another backend service.

But for business logic, database interactions, calculations, etc, I really think the language construct is to clumsy and does not scale nicely.

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

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

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

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/

This page[0] seems to have some good information(on stdlib support at least).

As far as file sizes go, you're right. It might be possible to get better results deploying a brotli'd or gzipped file instead[1].

[0]:https://tinygo.org/docs/reference/lang-support/stdlib/ [1]:https://github.com/golang/go/wiki/WebAssembly#reducing-the-s...

>>increasingly, wasm

If you are referring to something similar to Blazor (client side), yeah no imo it's pretty awful for anything other than internal enterprise apps. I couldn't imagine running a public facing product on that.

By using Typescript you can share types on the backend and frontend. Java stacks tend to do the same thing but for backend and database by defining data at the ORM level. You can connect to your database in any language, but most people using Spring don't write plain SQL.

> The usual "isomorphic" case for backend.js is no less 'presumptuous' or 'dismissive' than the comment you're pointing to and criticizing here

> You can even compile backend-friendly code to run in JS on the frontend, via emscripten (and increasingly, Wasm)

Lol, you can't be serious

I could understand this reasoning but it is not the typical node backend I am seeing in the wild.

Your comments tells me you are in the group who doesn't know better. Data is passed in json which is a format other languages can read and send back. If that's your reason for using it you do have other choices.

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.

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.

> But unfortunately it has been slowly declining for a long time…

That could be a sign of “stability”.

I’m personally using Django since two years ago and have the same feeling as yours, there are nothing exciting happening in this area, but after two years of use I came to the conclusion that it’s features are too stable, so nothing new need to happen in the first place.

It’s a common myth that software should be always updating and introducing new features. No, it’s not, if it can solve the problem great it doesn’t need to change at all.

JS/TS/Rust are still in their exploration phase, new ideas, new exprimentations, new frameworks come and go everyday, and that’ the reason they look vibrant.

Before settle down with Django, for years I’ve used bleeding edge tech like Meteorjs/React/Nextjs/Vue/Nuxtjs/Svelte/SvelteKit/… in real world, or try to rewrite real world app with them, and the biggest problem of all of them is that they all have their quirks and things in JavaScript area are changing too often and too much, I’m so tired to chase all these fancy new ideas.

For 90% web apps Django+Htmx+AlpineJS can serve me good and do all the things that new tech can do easily, at the same time keep incredible stability.

I believe Rails or Laraval are same here, you don’t need to switch in 90% cases, just relex and appreciate the stability they bring.

Thank you for your feedbacks on Django. I agree Django is maybe a boring but solid framework. I never used it so I can’t speak about it’s dev experience but it looks great. I see Python kind of like Java but for dynamic languages. It’s not shiny it’s not the hype. But what can’t you do with it? Usually when a new tool comes out you have Java and Python as clients. Before you used to have Ruby too. Now not so much.

For Rails the thing is that it’s not just one lib among a huge ecosystem like Python but more or less Ruby = Ruby on Rails. Sure you have Sinatra which is the Flask of Ruby but that’s it. While in Python you can do so many other things from devops to ML to eBPF…

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

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.

I agree like I said the last version of Rails is great. I have been doing Rails for almost a decade now so I’m quite familiar with all its new things. But there are also a lot of issues right now if you are planning to start a company.

The total number of job offers in Rails have been going down for quite a long time now.

If you look at the Stackoverflow surveys and compare the professional respondents for Ruby and RoR between 2021 and then 2022. It’s a 20% decrease. It’s a lot.

Critical contributors of Rails and its ecosystem left for Rust, Elixir, etc. For instance the guy that was behind Active Record went to Rust. Or the creator of Elixir itself and many other followed. On the other hand I don’t see prohiminent open source contributors coming to Ruby to at least replace them… I have been doing Rails myself for almost a decade now and I can tell you that many Rails devs want or already switched to Phoenix or other languages. It’s not going up.

Many gems are mature for sure and don’t really need anymore commits. But also many are abandoned with PRs and issues stacking up. The ecosystem is not really increasing anymore even more vibrant.

Now with all that said: is it impossible to find a job in Rails today? No. Is it impossible to find some devs? No. Is it going to disappear in 4 years? No. Are you going to make a big mistake using it today? No. But there are now so many other options out there without any of these cons and some other pros that it starts to be more and more difficult to chose Rails as a solution today to start a company. Unless you want to use Rails for a side project you can’t ignore these issues and all the other options we now have out there.

About rewrites. It’s not just about the technical part. It’s also the human part. Let’s say I hire you and we grow and there is also 3-10 more Rail devs. But a rewrite has to happen. Are you going to be so exited to jeopardize all your experience in Rails to switch to something new? Even if you are the other 2-9 devs may not. And let’s say more or less everybody agrees that a rewrite has to happen, now you still have to agree on which language and which framework you are going to use! Some may really want to do Go, some Elxir, some other TS…

Whatever the solution that will be chosen there will be a lot of frustrations. Plus there will be frustrations on the tech part of the rewrite and they have to start to be slowly getting more and more productive to the new tech where something that could have taken 1 day can take 5 now. All this, particularly the frustrations from switching to a tech where some won’t really like, will slow down a lot the company. When you check postmortems of startups that failed, so many times in the reasons why they failed there will be this “and we decided to do a rewrite…”. But I never saw a company failed and they will still say that the rewrite was a great idea.

With all that said: better pick the right solution today and look at all the options. Not the Google one, not the one that decrease but one that is at least solid to vibrant, not the last hyped one either, but the best one.

I truly love Rails. But I can’t just chose it because I love it. There are now better options out there for the long term future.

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.

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.

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

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.

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.

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

crates.io for Rust has 213 crates tagged "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/

And the IDEs which practically write your code for you. I mean yeah Java is so verbose but most of that word vomit is me just tabbing through autocomplete

I went back and prototyped a slightly similar app in Python w/ a gui toolkit and I felt like I was driving through exception city. I have made my career writing in dynamic languages so I forgot just how pleasant it was to write in a static one!

> Python w/ a gui toolkit

Sorry, this is always the wrong choice, which is why it felt so bad.

Writing a UI in TypeScript with any of the major frontend frameworks will not require you to wade through run-time exceptions

Java native GUI toolkits are also far more mature

Python and TKinter and similar stuff is always just awful, I've never seen someone put together anything half decent with that stack

Calibre, the ebook client, is a python GUI app. wxWidgets I think?

Theres another app that I use for renaming downloaded video files that uses a GUI toolkit.

I've written GUIs in pyGTK for industrial apps and it was a wonderful experience. The only reason I couldn't get it to work now because I can't get pygobject to compile on Windows (the offered solution of MSYS2... wasnt)

Unfortunately this project was working with Stable Diffusion, so I had to use something in Python

In any case I don't like this idea of a right or wrong answer here. LIke way too many people think Electron is a right answer and I think that's just dumb

I find typescript makes the most common things I do in business app software as straightforward as possible. That is, making copies of objects with slightly different structure to pass them to some other system. Typescript is just fantastic for plumbing.

To do the same in java means making a billion model files with a billion transformation functions on them

Yup. I view TypeScript as the best "get things done quickly without too much code and minimal bugs" language.

You should try NestJS with Prisma or Typeorm and Postgres. Plus all the classic other stuff. It's a great stack.

Your post is a great example why I wish Go lang was named something different. Because you use the lower cased versions java, rust, js, ts, nodejs, deno, etc. But all your 'go' refer to the verb, not the Go language.

Wouldn't you just use go/python/node for a simple crud API? fastapi for python is pretty performative if you use gunicorn as your runtime and time to iterate is must faster than it is in rust.

It depends exactly how simple that CRUD API is. If there's any business logic, I'd rather get all the cheap correctness guarantees that Rust provides. I don't find myself making many truly dumb CRUD APIs.

Time to iterate is also only much faster in certain situations, e.g. local development; if you have to e.g. build a container image, push to a registry, and redeploy to a k8s cluster somewhere, those savings become somewhere between less significant and nonexistent.

> Time to iterate is also only much faster in certain situations, e.g. local development; if you have to e.g. build a container image, push to a registry, and redeploy to a k8s cluster somewhere, those savings become somewhere between less significant and nonexistent.

Can you expand on what you mean here? I know you're not implying Rust is faster to move thru a CICD pipeline, so can you tell me what you do mean? I seem to be unable to make a different reading

I think the point being made here is that all CI/CD/SDLC stuff is effectively slowing down development, so the difference in iteration speed between Python and Rust is less explicit. But I dare to disagree, I just can't connect the dots here, moving code further down the CICD pipeline doesn't mean we can't work on the code itself or think about project improvement ideas.

“Time to iterate” is measuring how quickly you can get an idea, build it in code, deploy it to your customer, and get feedback.

If Rust is helping you make prototypes and iterate quickly, I’d love to hear how you’re using the language.

Not your parent, but I have some ideas on this. I'm not sure how true they are. Maybe I'll write a longer version some day and see what people think. But the summary is this:

I suspect it has to do with how familiar you are with type systems, and the way that you use them. I find that Rust's constraints help guide me towards a solution more quickly, and I spend less time chasing down strange edge cases. Not eliminate! But reduce.

The latter use case is terrible for Rust.

Reply on news.ycombinator.com