3 ms·

Yes! You 100% dont need a front end framework like React to achieve dynamic UI effects. I’d argue they’ve degraded the user experience over time, complicated de

Yes! You 100% dont need a front end framework like React to achieve dynamic UI effects. I’d argue they’ve degraded the user experience over time, complicated development process, and slowed down the web experience for most people. The fact remains client side JS frameworks did not grow organically from the open source community. They had to be pushed into the dev mindspace by the mega-caps tech cos to offload processing power to the client. For the vast majority of companies (all but a handful), front end frameworks hold an org back. I’ve had this unpopular opinion for several years, and have yet to meet/work with a startup who didn’t regret choosing Angular/React/etc.

slifin 6y ago
SPAs designed to mirror state on the server have a distributed data problem, there are lots of problems there in terms of fetching, updating, ensuring the users are traversing from action, loading, success/failure etc Then there's the problem that the page could have changed since the user started filling out that form, what happens when those form values now conflict etc etc The difference between serving a dead fish of a HTML page, and a SPA application is vast because you're essentially creating 2 independent systems, server and client instead of just server and then adding one of the hardest thing in computing which is consensus between disparate systems I'm quite excited about React Server Components because it means for the majority of your web app you can return to the simplicity of shipping HTML it doesn't solve everything but at the moment client side applications have a lot of boilerplate to do with just keeping the server in sync that would have been historically "for free" in a server context
- chrischattin 6y ago
  Yes. This exactly. You're basically writing the business logic in the app twice. It's an anti-pattern in my opinion that adds all kinds of tech debt. I'm loving it that the trend is starting to go back to rendering HTML from the server, then sprinkling on dynamic elements when desired. It's so much more efficient whether you're talking compute, developer time, or the ability to stay agile and change/add features as you learn about the market.
franklampard 6y ago
Curious why they regretted and how else would they have built the web app
hombre_fatal 6y ago
That clients exist to do work so that a company's hardware doesn't have to is cynical, a "client bad [if it's built with JS]" cargo cult, and it suggests that you can't think of any upside to doing things on the user's powerful device instead of a phone-home network request to a server.
lucasmullens 6y ago
You've never met anyone who didn't regret React? According to the Stack Overflow Developer Survey, 68.9% love React. I feel like you haven't talked to enough people. The idea that client side JS was pushed to offload processing power is a bit ridiculous. Do you have any evidence for that claim? Many React sites these days do SSR anyway (running the client-side code on the server) so it doesn't seem like they would save money doing that.

slifin 6y ago

SPAs designed to mirror state on the server have a distributed data problem, there are lots of problems there in terms of fetching, updating, ensuring the users are traversing from action, loading, success/failure etc Then there's the problem that the page could have changed since the user started filling out that form, what happens when those form values now conflict etc etc The difference between serving a dead fish of a HTML page, and a SPA application is vast because you're essentially creating 2 independent systems, server and client instead of just server and then adding one of the hardest thing in computing which is consensus between disparate systems I'm quite excited about React Server Components because it means for the majority of your web app you can return to the simplicity of shipping HTML it doesn't solve everything but at the moment client side applications have a lot of boilerplate to do with just keeping the server in sync that would have been historically "for free" in a server context

chrischattin 6y ago
Yes. This exactly. You're basically writing the business logic in the app twice. It's an anti-pattern in my opinion that adds all kinds of tech debt. I'm loving it that the trend is starting to go back to rendering HTML from the server, then sprinkling on dynamic elements when desired. It's so much more efficient whether you're talking compute, developer time, or the ability to stay agile and change/add features as you learn about the market.

franklampard 6y ago

Curious why they regretted and how else would they have built the web app

hombre_fatal 6y ago

That clients exist to do work so that a company's hardware doesn't have to is cynical, a "client bad [if it's built with JS]" cargo cult, and it suggests that you can't think of any upside to doing things on the user's powerful device instead of a phone-home network request to a server.

lucasmullens 6y ago

You've never met anyone who didn't regret React? According to the Stack Overflow Developer Survey, 68.9% love React. I feel like you haven't talked to enough people. The idea that client side JS was pushed to offload processing power is a bit ridiculous. Do you have any evidence for that claim? Many React sites these days do SSR anyway (running the client-side code on the server) so it doesn't seem like they would save money doing that.