4 ms·

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 cha

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.
- bufferoverflow 2y ago
  > given jQuery and React aren't even remotely aimed at solving the same problem? Both are used for rich UI experiences.
  - troad 2y ago
    > Both are used for rich UI experiences. So is Microsoft Frontpage, or Figma, or wgpu over wasm, or my friend John, the UI designer. Are these all directly comparable tools? Does John lose marks for not being downloadable over npm? (I can get him to compile TypeScript, but I can't seem to get him to compile into TypeScript)
- curtisblaine 2y ago
  It's not unnecessary if you don't want to write and maintain a backend. Single page apps are easily statically hosted on a CDN. They don't run, they can't go down. They can use a server less platform API like Firebase and Supabase. They can be hosted for free at low traffic. Compare with rolling, monitoring and maintaining your own server, ssh-ing if it goes down, dealing with auth, containers, VMs etc.

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.
bufferoverflow 2y ago
> given jQuery and React aren't even remotely aimed at solving the same problem? Both are used for rich UI experiences.
- troad 2y ago
  > Both are used for rich UI experiences. So is Microsoft Frontpage, or Figma, or wgpu over wasm, or my friend John, the UI designer. Are these all directly comparable tools? Does John lose marks for not being downloadable over npm? (I can get him to compile TypeScript, but I can't seem to get him to compile into TypeScript)
curtisblaine 2y ago
It's not unnecessary if you don't want to write and maintain a backend. Single page apps are easily statically hosted on a CDN. They don't run, they can't go down. They can use a server less platform API like Firebase and Supabase. They can be hosted for free at low traffic. Compare with rolling, monitoring and maintaining your own server, ssh-ing if it goes down, dealing with auth, containers, VMs etc.