4 ms·

It is rather simple why: Frontend is not linear programming, most backend actions are single-flow (on A do B), in frontend at any point the user can interrupt t

It is rather simple why: Frontend is not linear programming, most backend actions are single-flow (on A do B), in frontend at any point the user can interrupt things, which calls for state management. Most backend applications are stateless and state management is outsourced to a database which does the heavy lifting. So the complexities are in scaling. Maintaining a complex frontend application is akin to maintaining a complex caching layer in front of your database. The tooling hell doesn't help of course, but I wouldn't say it is the main reason.

gemstones 3y ago
Yeah - it’s a wildly different paradigm. It’s not quite the same as Erlang/OTP, but it requires a mindset shift much like learning OTP and thinking of callbacks on an event loop working together. Users can interrupt code when they want, and aren’t obligated to take a blessed path of actions. I will say that some of the complications he mentions are from web apps needing to compile down to a single executable, on a platform that only really supports one interpreted language. Perhaps WASM will help here, over time.
gemstones 3y ago
Another wrinkle - lots of web apps have a need to say, I’m going to give you one bundle of JS for this whole hostname, regardless of URL, but then have to handle getting loaded from arbitrary URLs (that may have semantic meaning for your server) anyways. Everyone gets the complexity of a URL document hierarchy, even if your web app isn’t document-based.
- DanielHB 3y ago
  true, it is called routing. But to be fair most mobile apps also have routing, usually with semantics similar, but still different, from web-based routing. The reason mobiles apps have it is for deeplinking. Old school desktop applications didn't really have deep linking, even today it is quite uncommon (with the exception to trigger some action in the app like opening a file as opposed to navigation)
addicted 3y ago
There is nothing you can do in the front end that a .NET Forms application from a few years ago could not also easily handle. And the .Net forms application would be immeasurably simpler in terms of complexity and as a bonus, would have the backend thrown in almost for free as well. I deliberately picked .Net forms because despite being much simpler than today’s front end stacks, it was still, much like any MS product, an overengineered corporate driven MS tech. Something like Ruby on Rails, Laravel etc shows that front end is not inherently complex.
- gemstones 3y ago
  So why did the frontend engineers move on from Ruby on Rails? When I was an ROR developer, RailsCasts would tell you to do basically the same thing as HTMX, return partial HTML and use a tiny bit of JS to update the appropriate part of the DOM. It’s a good fit for simple experiences, but breaks down when you need the result to update more than one place (say, a counter by the cart icon, or a set of options in a select in the sidebar.) Then, you hypermedia approach has forced you to try and explore your HTML snippet to pull relevant information, rather than get it in a nice structured format.
- graftak 3y ago
  Rendering 3d VR environments with interactive points of interest, live video players with real time highlight markings and sport standings with graphs comparing parallel games in the same league, having online conferences with 20K visitors that can interact with each other through (video) (group) chat. Sweet.
  - majewsky 3y ago
    Ok, agreed that 1% of all apps need a complicated tech stack. Meanwhile the bulk of all web development is simple CRUD forms and reports.
    - 6510 3y ago
      You mean need to be desktop clients.
DrScientist 3y ago
Yep. Modern clients are complicated because state management is complex. Ironically, that's what the early web largely got rid of - for example this web page I'm using now has very little state to manage.
- DanielHB 3y ago
  yeah, because keeping state in a backend-cookie-based-session was a huge pain in the ass
joecot 3y ago
Making websites into single page applications / dynamically javascript powered separated the frontend and the backend, and made the backend significantly easier. But it made the backend easier by pushing a ton of those previously backend concerns to the frontend. And then we wonder why the frontend is so complicated.

gemstones 3y ago

Yeah - it’s a wildly different paradigm. It’s not quite the same as Erlang/OTP, but it requires a mindset shift much like learning OTP and thinking of callbacks on an event loop working together. Users can interrupt code when they want, and aren’t obligated to take a blessed path of actions. I will say that some of the complications he mentions are from web apps needing to compile down to a single executable, on a platform that only really supports one interpreted language. Perhaps WASM will help here, over time.

gemstones 3y ago

Another wrinkle - lots of web apps have a need to say, I’m going to give you one bundle of JS for this whole hostname, regardless of URL, but then have to handle getting loaded from arbitrary URLs (that may have semantic meaning for your server) anyways. Everyone gets the complexity of a URL document hierarchy, even if your web app isn’t document-based.

DanielHB 3y ago
true, it is called routing. But to be fair most mobile apps also have routing, usually with semantics similar, but still different, from web-based routing. The reason mobiles apps have it is for deeplinking. Old school desktop applications didn't really have deep linking, even today it is quite uncommon (with the exception to trigger some action in the app like opening a file as opposed to navigation)

addicted 3y ago

There is nothing you can do in the front end that a .NET Forms application from a few years ago could not also easily handle. And the .Net forms application would be immeasurably simpler in terms of complexity and as a bonus, would have the backend thrown in almost for free as well. I deliberately picked .Net forms because despite being much simpler than today’s front end stacks, it was still, much like any MS product, an overengineered corporate driven MS tech. Something like Ruby on Rails, Laravel etc shows that front end is not inherently complex.

gemstones 3y ago
So why did the frontend engineers move on from Ruby on Rails? When I was an ROR developer, RailsCasts would tell you to do basically the same thing as HTMX, return partial HTML and use a tiny bit of JS to update the appropriate part of the DOM. It’s a good fit for simple experiences, but breaks down when you need the result to update more than one place (say, a counter by the cart icon, or a set of options in a select in the sidebar.) Then, you hypermedia approach has forced you to try and explore your HTML snippet to pull relevant information, rather than get it in a nice structured format.
graftak 3y ago
Rendering 3d VR environments with interactive points of interest, live video players with real time highlight markings and sport standings with graphs comparing parallel games in the same league, having online conferences with 20K visitors that can interact with each other through (video) (group) chat. Sweet.
- majewsky 3y ago
  Ok, agreed that 1% of all apps need a complicated tech stack. Meanwhile the bulk of all web development is simple CRUD forms and reports.
  - 6510 3y ago
    You mean need to be desktop clients.

DrScientist 3y ago

Yep. Modern clients are complicated because state management is complex. Ironically, that's what the early web largely got rid of - for example this web page I'm using now has very little state to manage.

DanielHB 3y ago
yeah, because keeping state in a backend-cookie-based-session was a huge pain in the ass

joecot 3y ago

Making websites into single page applications / dynamically javascript powered separated the frontend and the backend, and made the backend significantly easier. But it made the backend easier by pushing a ton of those previously backend concerns to the frontend. And then we wonder why the frontend is so complicated.