Hacker News Reader

Comment by JodieBenitez | Hacker News Reader

One of the frontend problems is that too much frontend engineers think a web app should be a single page app. A lot of apps don't need to be that. Server-side endpoints and templating + lightweight vanilla JS and framework-agnostic web components works and is now even easier than ever.

View on HN

It‘s a kind of collective hallucination. It‘s affected me too.

I just recently decided to go back in time and wrote a web app using Flask, all rendered server side, with a minimum of JS and JSON endpoints for a bit of client-side interactivity (e.g. autocompleting an input field). Very fast, iterative work. No duplication of data classes, no weird caching issues…

Felt like a breath of fresh air, sadly. Have we witnessed a full turn of the wheel?

That's a good old case of "the right tool for the job".

But let's be honest: the frontend dev rat race had the effect to make the base web technologies better. Better CSS (variables, nesting, effects, media support, etc), better JS (webcomponents), useful libs available as wasm and so on... all good things that can be used natively and allow us to make better MPAs.

I've seen so many marketing websites written in React. It's so confusing.

I think most people choose SPAs because they also maintain the frontend state of a an application. If you're just serving templated html from a backend, you're probably also doing vanilla javascript which is it's own kind of hell. How do you manage the transition between one view and another on the same page? How do you pass state between two pages? I think webcomponents solve some of this but there's a lot of react developers out there who don't have the requisite software engineering skills to handle this

> How do you manage the transition between one view and another on the same page?

HTMX solves this, and it's mostly automatic. You get some nice transitions.

> How do you pass state between two pages?

You don't. You submit some data to the server, it generates HTML dynamically, you replace HTML on the frontend or redirect all together, you're done. The state is on the server.

So then you need some kind of state management on the server?

> So then you need some kind of state management on the server

Yes. You might call this an application, lol. You will require this no matter what, unless you have a fully client-side application. Like photoshop or something.

> If you're just serving templated html from a backend, you're probably also doing vanilla javascript which is it's own kind of hell.

How so ? Vanilla JS has never been easier and more powerful.

> How do you pass state between two pages?

Why is it even considered to be a problem ? This is basic stuff. All web frameworks since the 90s have had this concept of sessions where you can store data that will be available across pages.

Vanilla js is unstructured. It's very easy to write spaghetti code with vanilla js.

Sessions are a kind of global state. I mean temporary state, like when filling out a form and moving from one page to the other, but without submitting the results until the end.

> Vanilla js is unstructured.

Functions, classes, modules... everything is available to organize code. The mess some programmers make can be unstructured, but that's the case with any paradigm and yes, we've seen that with "modern" JS frameworks too. Spaghetti mess, lasagna mess, components mess or whatever pasta mess.

> I mean temporary state

What is the problem here ? It's as temporary as you need it to be.

Temporary state does not need need to be sent to the server, it can be managed in localstorage

clear boundary is good, I don't understand why people like to trash their back-end with templates, MVC and all the "view" nonsense. They are just shifting complexity from a place they feel uncomfortable, to where they do, but at the cost of destroying their own nirvana. Certainly one way, but hardly the only one.

> I don't understand why people like to trash their back-end with templates, MVC and all the "view" nonsense.

Because the tooling has been here for decades and it works damn fine. No need to trash the frontend with ever changing piles of dependency and build nonsense.

> works damn fine

when? View code in the back-end always looks like crap and never able to achieve the interactivity the front-end can. People wrestling with it was the reason SPA was born. There was no dictator forcing people to move on from such "awesome" working "damn fine" pipelines to modern front-end for no reason.

> View code in the back-end always looks like crap

That's probably the fault of the people writing it. People can also write crap looking code using frameworks too.

> and never able to achieve the interactivity the front-end can.

That's what small sprinkles of javascript is for. You don't need incredibly beautiful interactivity in every pixel.

Commercial-grade applications need some grade of offline operativity that classic HATEOAS can't provide, often target users who won't learn or can't really use a web browser (tabs, back button, extensions, bookmarks besides whatever they can fit in the bar, etc), often want to give a UX which abuses and deforms a web browser by design. Yeah, FE engineers may all look like dumbasses with macbooks (i don't think this of them!), but they have real problems to solve.

Not denying that, but just because I browse the web I'm pretty sure not all websites with "modern" frontend stacks have modern frontend problems.

That's for sure, for example any blog software (a few SSGs included) is a failure for WWW and for itself (most of the interaction between author and reader must be mediated with third-party or big cloud to avoid spam and scam).

Reply on news.ycombinator.com