5 ms·

The vast majority of websites don't need to be 'apps' at all. A few do, but these generally need to be tailor-made anyway. The trend to shove web frameworks in

by troad 2y ago

The vast majority of websites don't need to be 'apps' at all. A few do, but these generally need to be tailor-made anyway. The trend to shove web frameworks into everything has ushered in a nightmarish decade of slow, dysfunctional websites, that - despite being over-engineered to high heaven - hardly deliver an improved user experience compared to what we had in 2008. There's a class of frontend dev for whom - no matter the question - the answer is always some unholy combination of React / Node / Vite / Angular / Vue / Nuxt / Next / Bun / Deno / Svelte / SvelteKit / etc - preferably running across two dozen Docker swarms, ruled by the Red Queen (kubernetes). "Oh, you want to put your CV online? Sure, let's spend the next three weeks plotting out the state flow diagram for your 'app'... " The reason React is particularly disparaged, imho, is because the framework fashionistas have moved on to chase the new shiny thing, and everyone else has always hated all these frameworks to begin with, so there's no one left to defend this particular hot mess. The same fate awaits the rest of the frameworks, in time.

absqueued 2y ago
I was talking to my classmate from x10, and he said to have shipped one page app with WP backend, React frontend in Azure VM :| Incurred a bill of $800, and reached out to me. Gobsmacked!!
notapenny 2y ago
> The reason React is particularly disparaged, imho, is because the framework fashionistas have moved on to chase the new shiny thing, and everyone else has always hated all these frameworks to begin with, so there's no one left to defend this particular hot mess. I think you're projecting here. Its fine not to like trends in tech, but tech will change whether you like it or not. The people who jump on every new thing and stress about having to learn it all will keep doing it. That doesn't mean that anyone else hated it all to begin with. That's a pretty weird assumption to make. Even this thread is full of people who enjoy using React. Meanwhile, React is pretty stable and boring if you ask me. Your nightmarish decade will be extended. I'll light a candle for you.
nsonha 2y ago
the vast majority static "sites" don't need to exist at all, how about that? It's the apps with unique requirements that need to be coded, not some pages that present some info in some way that's slightly different, stylistically, and not standard at all.
xcrunner529 2y ago
Yep. A simple shopping site or tweet site doesn’t need to be an “app”. These devs are up their own asses thinking they need an app for their stupid (and simple) idea because it’s easy for them and they are “engineers” and we’re all stuck with delayed reactions, missed/double clicks, and broken middle clicks (X, Target) on every click now. Some app.
- bardak 2y ago
  I think I despise throbers and spinners more than slow page loads at this point.
  - troad 2y ago
    At least the throbbers and spinners are real. The true evil is "optimistic rendering". "Our framework is so slow that we can't possibly manipulate data in a reasonable time frame, so we'll just lie to the user and say we did! What could possibly go wrong?" Also in the running: giving absolutely no indication whatsoever to the user that anything succeeded or failed or is in progress at all (aka the Apple approach).
- gejose 2y ago
  This reads like the perspective of someone who really doesn't understand nor appreciate the real world complexity and technical trade offs involved in building something like twitter or a shopping site
  - troad 2y ago
    > This reads like the perspective of someone who really doesn't understand nor appreciate the real world complexity and technical trade offs involved in building something like twitter or a shopping site You're describing websites simple enough that they're often used in beginner tutorials for web development. Online shopping and text-based social networking absolutely and emphatically do not require a spaghetti soup of JavaScript frameworks. These were relatively simple websites to build for decades before web frameworks ever came along.
bufferoverflow 2y ago
React (and similar frameworks) make the code much more maintainable. You basically define your state and how that state should look like. You don't manually change your UI, it just re-renders when your state changes. Compare it with the nightmare of JQuery, where any line of code can affect any UI for whatever reason.
- troad 2y ago
  I understand what React does. My point is that what it does is unnecessary for the vast majority of websites, and I stand by this. > Compare it with the nightmare of JQuery, where any line of code can affect any UI for whatever reason. False dichotomy, and a somewhat strange one, given jQuery and React aren't even remotely aimed at solving the same problem? You're free to stick to a functional paradigm in JS without requiring the overhead of React (and all the cruft that tends to pile up around React - build systems, compile times, masses of dependencies, the inevitable CVEs for those dependencies, etc.) But more importantly, I'd respectfully note that you're pre-supposing that UI state rightly lives in JavaScript, which is a point of view already limited by framework-centric assumptions.
  - hombre_fatal 2y ago
    I think it's time to question what "necessary" means for a product/service delivered online. If it's unnecessary to use React et al, why is it necessary to complicate your application server with UI concerns so that it can build a big html UI string that is sent over the wire? And this only works for web browsers and no other clients? Instead, it could be a simple API server that doesn't need to know about the UI at all. There are obviously trade-offs in either direction, but to talk about necessary vs unnecessary doesn't seem to reflect that. There is nothing more necessary about one set of them over the other.
    - troad 2y ago
      Simple problems call for simple solutions. The vast, overwhelming majority of webpages are simple problems, solved by a server serving HTML. A 'simple API server' sounds lovely, but it's not getting your website to anybody without a frontend - and the complexity of the frontend offsets any savings made by simplifying the backend. I'd also very respectfully push back on this 'simple API server' business - serving /fie/fo/fum.json really isn't very much simpler than serving /fie/fo/fum.html; you have identical business logic, plus you've now got messy bi-directional JSON objects and hundreds of Ajax calls over unreliable end-user connections to contend with. It's the voluntary introduction of hundreds of unnecessary failure points. For most 'simple API servers' there's an alternative, and much simpler, much safer, much saner HTML server. For that tiny number of websites that do require accompanying apps (mobile, etc), 97% of these could be solved with a thinly wrapped web-view. Those that cannot generally have special needs, and therefore cannot be solved by simply serving the same API endpoints across web and app anyway. If you're already separating your web and app APIs, plus now you've got a tangled web frontend to contend with, I'm really not seeing the benefits of reorienting your backend around APIs to begin with. A backend serving HTML to web, and a custom API to mobile is much more elegant and flexible (and doesn't actually require a soup of Javascript anywhere). But we're already in the 3% of the 3% here - truly unusual applications. The vast, vast, vast majority of use cases were already solved by a server serving HTML.

by troad 2y ago

absqueued 2y ago

I was talking to my classmate from x10, and he said to have shipped one page app with WP backend, React frontend in Azure VM :| Incurred a bill of $800, and reached out to me. Gobsmacked!!

notapenny 2y ago

> The reason React is particularly disparaged, imho, is because the framework fashionistas have moved on to chase the new shiny thing, and everyone else has always hated all these frameworks to begin with, so there's no one left to defend this particular hot mess. I think you're projecting here. Its fine not to like trends in tech, but tech will change whether you like it or not. The people who jump on every new thing and stress about having to learn it all will keep doing it. That doesn't mean that anyone else hated it all to begin with. That's a pretty weird assumption to make. Even this thread is full of people who enjoy using React. Meanwhile, React is pretty stable and boring if you ask me. Your nightmarish decade will be extended. I'll light a candle for you.

nsonha 2y ago

the vast majority static "sites" don't need to exist at all, how about that? It's the apps with unique requirements that need to be coded, not some pages that present some info in some way that's slightly different, stylistically, and not standard at all.

xcrunner529 2y ago

Yep. A simple shopping site or tweet site doesn’t need to be an “app”. These devs are up their own asses thinking they need an app for their stupid (and simple) idea because it’s easy for them and they are “engineers” and we’re all stuck with delayed reactions, missed/double clicks, and broken middle clicks (X, Target) on every click now. Some app.

bardak 2y ago
I think I despise throbers and spinners more than slow page loads at this point.
- troad 2y ago
  At least the throbbers and spinners are real. The true evil is "optimistic rendering". "Our framework is so slow that we can't possibly manipulate data in a reasonable time frame, so we'll just lie to the user and say we did! What could possibly go wrong?" Also in the running: giving absolutely no indication whatsoever to the user that anything succeeded or failed or is in progress at all (aka the Apple approach).
gejose 2y ago
This reads like the perspective of someone who really doesn't understand nor appreciate the real world complexity and technical trade offs involved in building something like twitter or a shopping site
- troad 2y ago
  > This reads like the perspective of someone who really doesn't understand nor appreciate the real world complexity and technical trade offs involved in building something like twitter or a shopping site You're describing websites simple enough that they're often used in beginner tutorials for web development. Online shopping and text-based social networking absolutely and emphatically do not require a spaghetti soup of JavaScript frameworks. These were relatively simple websites to build for decades before web frameworks ever came along.

bufferoverflow 2y ago

React (and similar frameworks) make the code much more maintainable. You basically define your state and how that state should look like. You don't manually change your UI, it just re-renders when your state changes. Compare it with the nightmare of JQuery, where any line of code can affect any UI for whatever reason.

troad 2y ago
I understand what React does. My point is that what it does is unnecessary for the vast majority of websites, and I stand by this. > Compare it with the nightmare of JQuery, where any line of code can affect any UI for whatever reason. False dichotomy, and a somewhat strange one, given jQuery and React aren't even remotely aimed at solving the same problem? You're free to stick to a functional paradigm in JS without requiring the overhead of React (and all the cruft that tends to pile up around React - build systems, compile times, masses of dependencies, the inevitable CVEs for those dependencies, etc.) But more importantly, I'd respectfully note that you're pre-supposing that UI state rightly lives in JavaScript, which is a point of view already limited by framework-centric assumptions.
- hombre_fatal 2y ago
  I think it's time to question what "necessary" means for a product/service delivered online. If it's unnecessary to use React et al, why is it necessary to complicate your application server with UI concerns so that it can build a big html UI string that is sent over the wire? And this only works for web browsers and no other clients? Instead, it could be a simple API server that doesn't need to know about the UI at all. There are obviously trade-offs in either direction, but to talk about necessary vs unnecessary doesn't seem to reflect that. There is nothing more necessary about one set of them over the other.
  - troad 2y ago
    Simple problems call for simple solutions. The vast, overwhelming majority of webpages are simple problems, solved by a server serving HTML. A 'simple API server' sounds lovely, but it's not getting your website to anybody without a frontend - and the complexity of the frontend offsets any savings made by simplifying the backend. I'd also very respectfully push back on this 'simple API server' business - serving /fie/fo/fum.json really isn't very much simpler than serving /fie/fo/fum.html; you have identical business logic, plus you've now got messy bi-directional JSON objects and hundreds of Ajax calls over unreliable end-user connections to contend with. It's the voluntary introduction of hundreds of unnecessary failure points. For most 'simple API servers' there's an alternative, and much simpler, much safer, much saner HTML server. For that tiny number of websites that do require accompanying apps (mobile, etc), 97% of these could be solved with a thinly wrapped web-view. Those that cannot generally have special needs, and therefore cannot be solved by simply serving the same API endpoints across web and app anyway. If you're already separating your web and app APIs, plus now you've got a tangled web frontend to contend with, I'm really not seeing the benefits of reorienting your backend around APIs to begin with. A backend serving HTML to web, and a custom API to mobile is much more elegant and flexible (and doesn't actually require a soup of Javascript anywhere). But we're already in the 3% of the 3% here - truly unusual applications. The vast, vast, vast majority of use cases were already solved by a server serving HTML.