SPAs Were a Mistake • Hacker News Board

Re: SPAs Were a Mistake

#411

Post by mwcampbell » Thu, Mar 03, 2022, 1:19 AM UTC

craigkerstiens wrote: post #343

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…

Hi Simon, why'd you pull me in ;) We recently went a rewrite of our frontend for https://www.crunchybridge.com from SPA to more "basic" request response app and couldn't be happier. Previously was SPA with React and we rebuilt from scratch with request/response using Node. In places we still leverage react components for re-usable frontend bits, but no more SPA and state management. As you've mentioned in some of you…

What server-side framework did you use for the request/response rewrite?

Re: SPAs Were a Mistake

#412

Post by unclebucknasty » Thu, Mar 03, 2022, 1:25 AM UTC

dlisboa wrote: post #155

Zanfa wrote: post #7

I think one of the unsolved problems of client-side interactivity on websites is how difficult it is to add it just a little bit of extra client-side functionality to a traditional server rendered website. For example, recently I had to deal with photo uploads on a Rails app, which works fine out of the box at first, until you want to show progress bars and uploaded previews etc. Then you add a couple of client-side…

The problem is the mixing and matching of state management. In a traditional web app all of the state is in the back end, in a SPA all of the state is in the front end. When we share state in between the two it's often messy. To me the answer feels like it should be "traditional web app for most things, components-as-first-intended for some things". The simplest React example is just one component that abstracts pres…

>The problem is the mixing and matching of state management

Routing (history management) is also a big problem (I'm assuming you weren't including that in your definition of "state" here).

Some would say, "but React, etc. have solved the routing issues", and that's perhaps the case. But what's difficult is wiring these routers up outside of a full React app. That is, if you truly want routing "solved", you generally have to go all React (or whatever) or just let the browser handle it in the traditional request/response sense. Sprinkling in just a bit of dynamic interaction wherein you want the history managed is purgatory.

And, on mobile, things get even more interesting. Consider the simple case of popping a modal (especially a slide-out). Many users will hit "back" on a mobile device, which they would reasonably expect to simply close the modal. But, if your app/page doesn't intercede to manage the history, the previous page is loaded instead.

Re: SPAs Were a Mistake

#413

Post by recursivedoubts » Thu, Mar 03, 2022, 1:26 AM UTC

dlisboa wrote: post #315

khimaros wrote: post #279

Earlier quoted context omitted.

this seems to be approximately what https://htmx.org/ is trying to accomplish.

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/

Re: SPAs Were a Mistake

#414

Post by fendy3002 » Thu, Mar 03, 2022, 1:27 AM UTC

craigkerstiens wrote: post #343

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…

Hi Simon, why'd you pull me in ;) We recently went a rewrite of our frontend for https://www.crunchybridge.com from SPA to more "basic" request response app and couldn't be happier. Previously was SPA with React and we rebuilt from scratch with request/response using Node. In places we still leverage react components for re-usable frontend bits, but no more SPA and state management. As you've mentioned in some of you…

My knowledge is limited on the front end. May I know which Node framework do you use? Is it NextJS? If not, what do you think about using NextJS because I really consider it a better approach and want to use it at new projects.

Re: SPAs Were a Mistake

#415

Post by unclebucknasty » Thu, Mar 03, 2022, 1:28 AM UTC

Pensacola wrote: post #368

dlisboa wrote: post #155

Earlier quoted context omitted.

The problem is the mixing and matching of state management. In a traditional web app all of the state is in the back end, in a SPA all of the state is in the front end. When we share state in between the two it's often messy. To me the answer feels like it should be "traditional web app for most things, components-as-first-intended for some things". The simplest React example is just one component that abstracts pres…

> The problem is the mixing and matching of state management. This. But IMHO the right solution is to make the back-end stateless and manage all client state on the client. Each request authenticates itself, and (if you're ReSTful about it) the back-end is simply a database connector/augmenter. In this paradigm, the SPA is basically a desktop app that retrieves data from a server, built to run within a framework, whi…

How well does React Router solve these problems if you're not using React fully?

Re: SPAs Were a Mistake

#416

Post by mwcampbell » Thu, Mar 03, 2022, 1:30 AM UTC

krisrm wrote: post #308

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…

I always thought of the benefits of SPAs more as a separation-of-concerns thing. You can pretty effectively build a functional front-end web application and mock a set of back-end REST apis, while another team builds out a the back-end. There are absolutely tradeoffs, and being a good software engineer is about understanding where and when those tradeoffs apply.

Why not eliminate that organizational bottleneck by using a full-stack framework that lets one person do it all? DHH recently described Rails as a one-person framework [1]. I think Phoenix fits that category as well.

[1]: https://world.hey.com/dhh/the-one-person-framework-711e6318

Re: SPAs Were a Mistake

#417

Post by naasking » Thu, Mar 03, 2022, 1:33 AM UTC

hughrr wrote: post #212

mattmanser wrote: post #201

Earlier quoted context omitted.

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.

Yes I mean the original version of it. I'd love to watch people attempt to implement some of the stuff I pulled off with that back in the day now. Occasionally, very complex data driven page flows are required and you could nail that entire problem domain trivially with them. There is a very large and well known company with a front-facing product used by millions of people which took 5 years pissing around with thre…

Speaking as someone who is still maintaining a web forms app, that sounds like a people problem, not a tech problem. You can implement literally any workflow if you understand continuations, and it will be simpler and more lightweight than web forms.

If you don't understand continuations, then you'll struggle and invent all sorts of poor state management patterns. Web forms simplifies some of this because the continuation is captured in viewstate, but it captures too much state (there are other warts too of course).

Re: SPAs Were a Mistake

#418

Post by chrisweekly » Thu, Mar 03, 2022, 1:33 AM UTC

pphysch wrote: post #294

chrisweekly wrote: post #263

Earlier quoted context omitted.

Please, go learn about Remix ( https://remix.run ), it is the actual correct answer for this stuff.

I don't understand why they choose an example -- a simple user dashboard -- that could be easily implemented as a traditional MPA. It seems like Remix is mainly for the "I learned to program with SPAs" audience.

Remix's _messaging_ may be aimed at the "SPA generation", but its capabilities are light years beyond a Rails w/ Turbolinks or whatever your concept of a traditional MPA might use. I'd encourage you to look a little closer.

My kneejerk rxn was "clearly you don't get it" -- but your critique and (mis)perception speak to their marketing / messaging, which, well, yeah, this is the world we live in. SPA has become the default, and Remix is pushing back on that, hard, and I'm stoked.

I've been doing webdev for a living since 1998, and Remix (like https://every-layout.dev 's "axiomatic css" - but I digress) is doing something profoundly powerful by leveraging the amazing power of the web platform on its terms, using the native APIs, and doing much, much more by being simpler and doing less. It's so refreshing.

Re: SPAs Were a Mistake

#419

Post by lmm » Thu, Mar 03, 2022, 1:33 AM UTC

s17n wrote: post #370

com2kid wrote: post #329

Earlier quoted context omitted.

> 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…

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).

Re: SPAs Were a Mistake

#420

Post by fendy3002 » Thu, Mar 03, 2022, 1:34 AM UTC

unclebucknasty wrote: post #412

dlisboa wrote: post #155

Earlier quoted context omitted.

The problem is the mixing and matching of state management. In a traditional web app all of the state is in the back end, in a SPA all of the state is in the front end. When we share state in between the two it's often messy. To me the answer feels like it should be "traditional web app for most things, components-as-first-intended for some things". The simplest React example is just one component that abstracts pres…

> The problem is the mixing and matching of state management Routing (history management) is also a big problem (I'm assuming you weren't including that in your definition of "state" here). Some would say, "but React, etc. have solved the routing issues", and that's perhaps the case. But what's difficult is wiring these routers up outside of a full React app. That is, if you truly want routing "solved", you generally…

Routing (along with hash path and query string) IMO is definitely a part of state. Different route lead to different content, thus different state.

The problem is which source of truth we want to use. I find that I'll need to refer to routes as the source of truth to process information, meaning "almost" every react action become route-manipulation action and it's state is just derived from the route, which is very similar with what MPA already do.