SPAs Were a Mistake • Hacker News Board

Re: SPAs Were a Mistake

#551

Post by code_runner » Thu, Mar 03, 2022, 12:06 PM UTC

For me, things like react and vue are DEDICATED to the front end. They are great for building UIs and have great ergonomics.

Backend frameworks that I LOVE (asp.net, laravel) have templating languages that feel like an afterthought, and passing data to them sucks (I usually have to redeclare what data they receive somewhere, or it’s entirely a dynamic paradigm) editor support is ok AT BEST… all of the sudden part of my app is dynamic c#, which c# isn’t good at.

My choice of backend should be absolutely divorced from my choice of front end. I can write an api in node, c#, go, etc and I don’t have to totally change how my front end works.

And splitting state between front end and backend (as mentioned throughout the comments here) is awful and error prone. There is a reason large scale apps aren’t using vanilla js or jquery and hand rolling state management etc.

It’s all about the size of the app, complexity, division of labor (I can hire a front end specialist who spends 70-80% of their time on front end)… the only goal isn’t JUST performance but if you do it right you get that too.

Re: SPAs Were a Mistake

#552

Post by marcos100 » Thu, Mar 03, 2022, 12:56 PM UTC

mattmanser wrote: post #201

hughrr wrote: post #178

Earlier quoted context omitted.

The correct answer for this stuff, and it absolutely kills me saying this, is probably something like asp.net web forms.

Asp.net web forms absolutely sucked. They fundamentally misunderstood HTML and how the internet even worked. Modern Razor's pretty good (not Razor Pages, they also suck) which is probably what you mean. But it's not that much different from Rails, Laravel, Django, etc.

By Modern Razor you mean Blazor components?

Re: SPAs Were a Mistake

#553

Post by manishsharan » Thu, Mar 03, 2022, 12:58 PM UTC

lmm wrote: post #419

s17n wrote: post #370

Earlier quoted context omitted.

This is missing the real reason that people write SPAs, which is that React solved web components, which are hugely beneficial for almost 100% of web sites, and thus became the standard for building web sites, and with React it's easier to make an "SPA" than to make a "traditional" site and users don't know or care either way.

Wicket has offered a beautiful component approach for over a decade now. Having seen it I can't stand page-oriented MVC frameworks (indeed it's good enough that it convinced me that OO actually has some merit in some cases).

I used Wicket quite extensively about 10 years ago so my comments may not be true anymore. I began using Wicket as it was so much better than Struts and JSF. However, the development of new custom widgets in Wicket was so much more convoluted than implementing the same widget in Backbone.js. And it was hard to inject new functionality into and existing page. I eventually refactored all my UI code into jquery+ backbone.js ( this was before React ) and that code is in production and still working. And the new developers maintaining it don't see any reason to refactor that into React or Vue.

Re: SPAs Were a Mistake

#554

Post by dlisboa » Thu, Mar 03, 2022, 1:19 PM UTC

recursivedoubts wrote: post #413

dlisboa wrote: post #315

Earlier quoted context omitted.

HTMX goes about it in the wrong way, in my opinion. HTML code should not carry state and logic. The moment you need something a bit more complicated than the common examples you’re in HTML-attribute soup trying to use a real programming language. It’s better to just write that as a component in React or Svelte or whatever. It’s more testable, easier to understand, can carry state and logic just fine. It does mean you…

the original network model of the web was REST[1] a core aspect of REST was HATEOAS, which stands for Hypermedia As The Engine of Application State[2] htmx goes about it in the same way as the original web perhaps that is wrong, but the web was pretty successful overall [1] - https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arc... [2] - https://htmx.org/essays/hateoas/

HATEOAS is great, but that's not my issue with HTMX. It's coding interactivity via HTML attributes that I have an issue with. It just never works. It overcomplicates things and there's an actual programming language right there in JavaScript to solve this.

When it goes past the simplest examples it gets ugly real quick. Here's an example of client-side validation via HTMX: https://htmx.org/docs/#validation. That can't be the future.

Re: SPAs Were a Mistake

#555

Post by the_gipsy » Thu, Mar 03, 2022, 2:02 PM UTC

ozim wrote: post #357

the_gipsy wrote: post #346

Earlier quoted context omitted.

> The majority of routers for React, and other SPA frameworks, do this out of the box. This has been a solved problem for half a decade at least. A website has to go out of its way to mess this up. 99% of SPAs break history related features in some way.

99% of people don't FRICKING care. Most of the users I have to deal with still have problems with double clicking. They don't understand basic browser features. They don't understand that they can set preferred language in their browser. History related features are not an argument in any way.

They do care if the experience doesn't work right, even if they don't understand why.

Re: SPAs Were a Mistake

#556

Post by b0ner_t0ner » Thu, Mar 03, 2022, 2:08 PM UTC

> SPAs were a mistake. Tomorrow, I’ll show you how we can build MPAs that are just as performant as SPAs, with less complexity and fragility.

You could just show people Unpoly: https://demo.unpoly.com/

Re: SPAs Were a Mistake

#557

Post by softwarebeware » Thu, Mar 03, 2022, 2:08 PM UTC

gls2ro wrote: post #197

softwarebeware wrote: post #29

I'm not clear why the author thinks that "media sites, really" are the only SPA use case. Have they never used webmail (like GMail), map apps (like Google Maps), or social networks (like Twitter)?

I give you Google Maps is a perfect example maybe for SPA. But Gmail? Why do we need SPA for that? Receiving emails notifications could be websockets and clicking on email should go to a new page displaying the email. I dont know if the initial gmail was SPA or not, but the current version is very very slow and consumes a lot of memory to display some emails that worked even in terminal clients, remember Pine? The sa…

Do you want a full page reload just because you deleted an email? Or flagged it? Or marked it as spam? Or even do you want your webmail in frames just to have a reader pane? Webmail is a great SPA candidate.

Re: SPAs Were a Mistake

#558

Post by darepublic » Thu, Mar 03, 2022, 2:20 PM UTC

Nextjs is a great way to make multipage web apps in modern day. Imo it should simply be the default for most use cases

Re: SPAs Were a Mistake

#559

Post by lolinder » Thu, Mar 03, 2022, 2:25 PM UTC

rtpg wrote: post #464

lolinder wrote: post #376

Earlier quoted context omitted.

Your arguments seem to be assuming a particularly bad implementation of a traditional backend. 1. A good server-generated-HTML backend will have no more state than a good server-generated-JSON backend. The client state is all stored in the client either way, whether in JS variables, HTML tags, or the URL. 2. A good server-generated-HTML backend doesn't do significantly more work just because its output is in HTML ins…

Multi-page forms without some front end stuff ends up with the very clunky either "rerender previous form pages over and over again, except hidden", or "have some token to track partial form data", or "build up a DB to store a partially complete form". With some frontend work you can have a multi-page form just work, with the data stored in the client up until final submission, and only sending in partial checks ahea…

I've built a multi-page form in an SSR app with a tiny dash of JavaScript. The form's children are divs. The Next button hides the current div and shows the next one. The final Submit button is just a regular submit.

If you get into more than 3 pages, this isn't a great approach for various reasons, but you don't need to reach for a framework the instant you have a multi-page form.

Re: SPAs Were a Mistake

#560

Post by chrismorgan » Thu, Mar 03, 2022, 2:48 PM UTC

com2kid wrote: post #329

simonw wrote: post #286

It's been so frustrating watch this play out over the past decade. I keep seeing projects that could have been written as a traditional multi-page application pick an SPA architecture instead, with the result that they take 2-5 times longer to build and produce an end-result that's far slower to load and much more prone to bugs. Inevitably none of these projects end up taking advantage of the supposed benefits of SPA…

> And most of them don't spend the time to implement HTML5 history properly, so they break the URLs - which means you can't bookmark or deep link into them and they break the back/forward buttons. The majority of routers for React, and other SPA frameworks, do this out of the box. This has been a solved problem for half a decade at least. A website has to go out of its way to mess this up. That aside, SPAs are great…

Client-side routing for page-oriented stuff is certainly not a solved problem: the basics, sure, but not actually doing it properly. There are some parts of the experience that it’s not possible to do perfectly because the web doesn’t expose the necessary primitives, and exceptionally few things go beyond the basics of just clobbering and resetting scroll position on back/forward. To do it properly, you need to restore all transient UI state (form field contents/state, scroll positions, focus, selection, media playback position; zoom level, probably not implementable; and there may be more, though I don’t include things like as transient state since that’s put into the DOM) on back/forwards, and I don’t know if I’ve seen anything actually do that. Then there’s the matter of helping accessibility tech to realise a page change has occurred, and I’m not sure of the state of the art on that, but last time I looked (some years ago) I think it was bogged down in unreliable heuristic land rather than actually being solved.