Hacker News Reader

Comment by DanielHB | Hacker News Reader

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.

View on HN

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.

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.

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.

You mean need to be desktop clients.

Nobody will download a desktop app to visit a marketing campaign about the future of IOT, watch a sports event, or to visit an online conference.

And if they would it would all be electron wrapping a website anyway.

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.

this is a common sentiment in these anti-modern-FE threads. it's a problem of imagination; i build internal tools for a large company you've definitely heard of. my org is several thousand people. we absolutely need to use react for the complex internal 2d/3d combo applications we build for debugging our next-gen products. given all the different platforms we need to support and the realtime nature of these incredibly complex tools, we _must_ build them for the web; we tried native applications and it does not scale.

many applications are much more complex than some simple forms.

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.

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.

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.

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

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.

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)

Reply on news.ycombinator.com