Hacker News Reader

Comment by guideamigo_com | Hacker News Reader

Why would someone use this over much more maintainable and performant backends in Go or Rust?

Define performant and define maintainable.

If you have a lot of duplicated functionality in a web frontend and backend, it may be a lot more maintainable to do the development once and not have to keep two implementations in sync.

As far as performance, if you’re using one of the JS application frameworks with server-side pre-rendering time to interactivity may very well be faster than anything you can build in Go or Rust.

There is no way that a js ssr framework is faster than a go ssr template renderer.

If you're building in plain Go with pure SSR, sure, but OP is talking about building a React frontend that is pre-rendered server-side. TTI very well could be faster with that than with a React front end that talks to a Go backend.

I'm kind of lost here. It's been ages since I wrote anything frontend related so here the question: how does it matter?

I mean unless you have pure front end app - you are still going to talk to some backend. Regardless of how you got your frontend part - generated by the server or a static file served by nginx.

Modern JS frameworks pre-render the components on the server then they attach to them to "rehydrate" and add JS handlers on the client. They also allow mixing of purely-server-side components (essentially templates, no JS or hydration) and mostly-client-side components (that still pre-render on the server)

For Rust, Leptos (https://leptos.dev/) would be one choice that can do SSR+hydration (but not intermixed with server-side components, at least AFAIK not yet)

There very well could be, the same way that java can be faster than c.

Why? Because js and java are JIT compiled for the very specific cpu they run on, and HotSpot is basically PGO but running all the time.

Granted, this is if and only if the js or java is carefully and properly written, which never happens...

The performance of Go and the maintainability of Rust ..., did you forget a /s there?

While many people have the impression the Rust type system slows them down while prototyping, I think it is a huge time saver when working on existing code, so I'm not sure why you think Rust isn't as maintainable.

Because there's a large productivity gain from being able to use one language for both the frontend and the backend, and server-side JS tooling is far more mature and usable than client-side Go or Rust.

Hiring real backend devs will give you a much better productivity gain then letting front-end JS devs larp at it.

Because they simply can't convert all of their js code into either go or rust for a forseeable future? Even providing they actually find those languages desirable, comparing to typescript.

> Why would someone use this over much more maintainable and performant backends in Go or Rust?

They were already using NodeJs or would have. And that's a large part of the current ecosystem.

Yeah it’s a silly question. It’s like going into a python thread and being like “why didn’t you implement all of this in Go or Rust?” Well, there’s a thousand reasons, and it’s really not even worth the time to unwrap this very reductive question that is really only going to turn into a language flame war for no reason.

because I can hire more JS/TS developers than I can go or rust (especially rust) developers AND I can pay them less... No $400k for a crud app here.

Indeed.

That's why outsourcing firms (both inside and outside the US) love JS backend.

The fragility of JS codebase shows much later.

Go is not a low level language FFS. It is just absolutely nowhere close enough to anywhere Rust/C/C++/Zig’s niche. Just stop it.

I never claimed Go is low level. However, it is very performant for building web backends.

Reply on news.ycombinator.com