SPAs Were a Mistake • Hacker News Board

Re: SPAs Were a Mistake

#481

Post by porker » Thu, Mar 03, 2022, 6:25 AM UTC

coruja wrote: post #438

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 try to tell myself "don't get caught up in using a fancy frontend framework on this one," as I'm starting a new project, but I keep running into situations where my functionality would just work so much better. As an example, I was writing a tool the other day to automate some things that have to do with quotes for my 9-to-5. Being able to add inline functionality in Django to select a customer within the quote pag…

> Being able to add inline functionality in Django to select a customer within the quote page, or add / edit a new customer without having to leave that quote felt very 'hackish,' using the same jquery callback method used in Django Admin.

Agreed. For form based apps I don't like to fall back to SPAs (bloat, the desire of every dev to reinvent forms in their framework, client and server side validation duplication), and yet working with relational data they are easier.

It's one of those places where a half-way step would be so useful.

Re: SPAs Were a Mistake

#482

Post by threeys » Thu, Mar 03, 2022, 6:26 AM UTC

nfw2 wrote: post #471

I have worked as an engineer on products in a lot of different domains in my career including: - edtech - real estate - HR/payroll software and every single project I've worked on had enough complex state to benefit from using a SPA. I've also worked on one complex web project run by someone dogmatically against client-logic, and it was absolute hell. The codebase was full of janky hacks to approximate the same compl…

No post body was provided.

Re: SPAs Were a Mistake

#483

Post by canyonero » Thu, Mar 03, 2022, 6:27 AM UTC

It's seeming pretty fashionable these days to bash SPAs. I disagree that SPAs were mistake (or that it's often a mistake to reach for a SPA, even today) SPAs are now and have been a great tool to leverage when you want to build an application without needing to think about servers. Yes, there are tradeoffs. Yes, you should think about the thing you're building for. Yes, you should think about the skills of the developers working on it. That doesn't change the fact that SPAs can be great choice and not something to be perceived as a mistake.

Re: SPAs Were a Mistake

#484

Post by ehnto » Thu, Mar 03, 2022, 6:32 AM UTC

I think SPA tooling solves a composability issue that people didn't realize they had, and so SPAs are used in a lot of instances where MPAs make way more sense and would be more performant, because the developers want to utilize the composability of components. The fact that SSR is a feature for React and Vue makes me think a lot of projects were really just aching for composability, not interactivity and dynamic data features of SPAs.

A think a lot of backend frameworks offer some attempts at frontend composability on the serverside but it's usually not the same approach that SPA tooling uses. I would love to get people's thoughts on backend tooling that is attempting to solve composability in a serious way, not just tacked onto an existing MVC framework.

Re: SPAs Were a Mistake

#485

Post by szastamasta » Thu, Mar 03, 2022, 6:33 AM UTC

What a total nonsense. I’m quite old in our industry standards and remember all this ”great and easy” way of working with backend templates and struggle to find it much easier than working with SPAs.

I also thank computer gods for SPAs each time I click in Github and wait for it junky slow interface to reload whole page.

Please save us from likes of ROR etc. that is slow and has awful user experience. Just try to use Basecamp. It’s so ugly, slow and free of any features at all that your eyes will bleed.

I personally am totally for ditching html and css from the browsers and just leave JS with some nice APIs (without DOM nonsense) and let us work with web apps like we would with desktop apps.

Web is not for documents any more. Just get over it.

Re: SPAs Were a Mistake

#486

Post by int_19h » Thu, Mar 03, 2022, 6:33 AM UTC

nrb wrote: post #454

tored wrote: post #442

Earlier quoted context omitted.

2. Hard to believe that is true in the general case. Typical scenario for SPA is to use some sort of REST API, these API:s are usually designed for general usage, not specific usage, i.e. designed to be reused between components and views thus they basically return everything of a specific model regardless if data is needed or not. Therefore the controller queries the database with the equivalent of SELECT * on a tab…

GraphQL is such a quality of life upgrade coming from this environment, especially at the scale where your frontend teams are potentially larger and shipping more than the teams closer to the SQL can provide.

What I really don't get is why we don't just expose SQL directly at this point. Is it just security? Database servers have fairly extensive authentication and authorization models.

Re: SPAs Were a Mistake

#487

Post by porker » Thu, Mar 03, 2022, 6:35 AM UTC

nfw2 wrote: post #471

I have worked as an engineer on products in a lot of different domains in my career including: - edtech - real estate - HR/payroll software and every single project I've worked on had enough complex state to benefit from using a SPA. I've also worked on one complex web project run by someone dogmatically against client-logic, and it was absolute hell. The codebase was full of janky hacks to approximate the same compl…

In your experience how often did the complex state have to be modelled on the backend as well as the frontend, to provide validation of submitted data?

And for personal interest, how did you handle streaming in updates and edits from multiple people, and stopping people from editing eg the same real estate listing at the same time? I know it can be done but I find it easier with server round trips for every request.

Re: SPAs Were a Mistake

#488

Post by thomas-guettler » Thu, Mar 03, 2022, 6:37 AM UTC

htmx.org the one and only frontend revolution

Re: SPAs Were a Mistake

#489

Post by int_19h » Thu, Mar 03, 2022, 6:37 AM UTC

ehnto wrote: post #484

I think SPA tooling solves a composability issue that people didn't realize they had, and so SPAs are used in a lot of instances where MPAs make way more sense and would be more performant, because the developers want to utilize the composability of components. The fact that SSR is a feature for React and Vue makes me think a lot of projects were really just aching for composability, not interactivity and dynamic dat…

But components in web apps aren't really new. That's what ASP.NET and JSF was all about, waaaay back when.

Re: SPAs Were a Mistake

#490

Post by shkkmo » Thu, Mar 03, 2022, 6:38 AM UTC

westoncb wrote: post #375

scarmig wrote: post #358

Earlier quoted context omitted.

> You aren't mixing state across server and client. Single Source of Truth is a thing for a good reason. If you have a stateful backend, and your front end naturally has the state of whatever the user has input, you now have to work to keep those two in sync. This is a bit weird to me, in that I'd say that cuts in the opposite direction. State can exist in at least three locations for most applications: db, app serve…

> but for all but the most cosmetic of purposes you're going to have to replicate that state on the backend anyway, to enforce business and security requirements. This really just comes down to what you're writing, how app-like your web app is. It's too easy to have one's own experience focused in a certain area and estimate the remaining majority as relatively similar. (For most of what I personally work on, the DB…

> From what I can tell most of the disagreement about SPAs results from devs who are building things that aren't app-like railing against their futility vs devs who are, who become perplexed by the vitriol when they have immediate experience with their architectural benefits.

The SPA criticics from the article and this thread have repeatedly said that their issue is not with building things that need the benefits an SPA architecture brings. The criticism is that the majority of SPAs are harmed by that architecture because it is the industry default and being used when it isn't appropriate.