Hacker News new | ask | show | jobs
by Merad 1115 days ago
I tend to agree with the article. I've felt pretty frustrated with the direction of react in the last few years. Most of the companies I've worked for that used react did so because they wanted a SPA, in most cases making a conscious decision to move away from older SSR technologies towards the SPA.

It's doubly frustrating because we primarily use C# and Asp.Net Core for back end work. A react SPA is trivial to use with any back end of your choosing... this SSR push they're making isn't much fun unless you use a JS back end (no thanks).

3 comments

Many have switched to a backend for frontend design (BFF). So you have another backend that proxies and/or uses the real backend and makes SSR and other frontend things.

A better explanation: https://blog.bitsrc.io/bff-pattern-backend-for-frontend-an-i...

I totally get that it's possible, but it's completely unnecessary complexity for both deployed apps and local dev. If the react team tells us that we have to jump through these extra hoops to use react*, my response will probably be to move to a different front end framework. And I say this as someone who honestly really likes react and who never really cared for front end work prior to learning react.

* I'm aware that server components aren't required, and probably won't be in the near future. But the way they're being pushed ATM they're likely to become the de facto standard, similar to how functional components and hooks have completely displaced class components even though the latter is still officially supported.

Horrid dev experience.
What's wrong with a JS back end? Node/Express is awesome.
Node is fine (and improving), but Express, or any of the many other libraries with similar APIs, is full of footguns:

- The base request-response cycle is ridiculously dynamic: the void-returning-callback API + stateful response object makes debugging a nightmare.

- Then there’s middlewares: they can come from anywhere, do anything anywhere in the call stack. They create complex webs of implicit coupling you can’t see, can’t find with static analysis, and can’t know if they’re changed or removed.

- You can add static types to address some of the above, but you cannot have any real confidence that the types reflect the actual presence or behavior of anything. It’s all just type assertions out of thin air.

- It’s routers all the way down; if you so much as nest one on a subpath, you have footguns squared.

- Maybe more specific to Express than the overall design, an absurd set of the request/response property names are very wrong, and get wronger in common setups.

It’s possible to address all of these without leaving Node (and I have!), but you’ll end up with a radically different API. It’ll be a better API, but it’ll also create friction for the unfamiliar, at least up front.

Any experiences with Hapi or Deno re: footguns above?
No direct experience, but the fact that route handlers return responses is a good sign. Both look like they have some of the request-mutation type of footguns.
For example, it's wrong if my back end is Java. Or Python. Or .Net. Or an exotic high performance database that serves JSON. Or anything that already works and I have no reason to replace or hobble with a new JS middleman at great cost.
Express was awesome. Now it's fastify or GTFO.

Seriously, express in 2023 smh.

It's too fragmented.

Express is actually pretty cool for basic microservices.

For anything complex, hell no.

nodejs and bilions of js libraries that you will install and never check.
This move seems like something that pleases nobody. There's a crowd that hates SPAs and a crowd that hates heavy react frameworks, and there's very little else. It seems like the number one critique of React is how bloated it has gotten and how much it reinvents the wheel.

Personally, I've always like React as a library for small interactive parts of your website. It's fairly trivial to make your site mostly static and use something like Asp.Net to handle how its rendered.