4 ms·

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

aranchelk 3y ago
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.
- LorenzoGood 3y ago
  There is no way that a js ssr framework is faster than a go ssr template renderer.
  - lolinder 3y ago
    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.
    - konart 3y ago
      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.
      - spion 3y ago
        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/ https://leptos.dev/) would be one choice that can do SSR+hydration (but not intermixed with server-side components, at least AFAIK not yet)
  - tuetuopay 3y ago
    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...
lolinder 3y ago
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.
- cornercasechase 3y ago
  Hiring real backend devs will give you a much better productivity gain then letting front-end JS devs larp at it.
re-thc 3y ago
> 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.
- SOLAR_FIELDS 3y ago
  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.
gabereiser 3y ago
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.
- guideamigo_com 3y ago
  Indeed. That's why outsourcing firms (both inside and outside the US) love JS backend. The fragility of JS codebase shows much later.
nsonha 3y ago
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.
flohofwoe 3y ago
The performance of Go and the maintainability of Rust ..., did you forget a /s there?
- alpaca128 3y ago
  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.
kaba0 3y ago
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.
- guideamigo_com 3y ago
  I never claimed Go is low level. However, it is very performant for building web backends.

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.

LorenzoGood 3y ago
There is no way that a js ssr framework is faster than a go ssr template renderer.
- lolinder 3y ago
  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.
  - konart 3y ago
    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.
    - spion 3y ago
      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/ https://leptos.dev/) would be one choice that can do SSR+hydration (but not intermixed with server-side components, at least AFAIK not yet)
- tuetuopay 3y ago
  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...

lolinder 3y ago

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.

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

re-thc 3y ago

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

SOLAR_FIELDS 3y ago
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.

gabereiser 3y ago

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.

guideamigo_com 3y ago
Indeed. That's why outsourcing firms (both inside and outside the US) love JS backend. The fragility of JS codebase shows much later.

nsonha 3y ago

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.

flohofwoe 3y ago

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

alpaca128 3y ago
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.

kaba0 3y ago

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.

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