Hacker News Reader

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.

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

> 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

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

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.

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.

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

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/