SPAs Were a Mistake • Hacker News Board

Re: SPAs Were a Mistake

#501

Post by democracy » Thu, Mar 03, 2022, 7:13 AM UTC

nfw2 wrote: post #476

democracy wrote: post #468

I also notice how much longer it takes to build the same crap we built 15 years ago with just html/css/js, and no, projects these days are not more sophisticated. Same old form submissions, but with a monstrosity of a project and crazy rates of devs who wants to constantly upgrade/update/migrate so some newer JS framework :shrugged :evilsmile

Many projects are absolutely more complex than they were 15 years ago. The web is now a space for fully-interactive applications, not just interlinked documents and forms

I am comparing apples to apples (CRUD to CRUD), not some random websites.

Re: SPAs Were a Mistake

#502

Post by shroompasta » Thu, Mar 03, 2022, 7:14 AM UTC

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 mean, of course the co-creator of Django would say this.

I wouldn't recommend newer generation of developers to build traditional web apps, let alone use jQuery.

I don't understand why people think we're still in the age of form submissions and blog posts - There has to be a good majority of us here that has worked on something complex that required SPAs here, no?

Not only would it be detrimental to a young developer's career to suggest avoiding SPAs in regards to hiring, but only limiting that developer to create blog post styled content is severely restraining.

Let them develop their blogs in SPAs, at least when they are needed to go into something a bit more complex, they at least have the foundational knowledge required to move towards that.

What you're suggesting is to learn two things, (one that is inevitably being phased out), and spend the mental effort to discern when to use either one, when the more beneficial alternative is to learn SPAs and just go with it.

No 18-25 year old is trying to make a Weblog where walls of text is the main content - Youtube shorts, instagram reels, tiktoks and all these bite sized content has done a great job at destroying that level of attention span.

They're going to be building something else, something quick and visual, something pleasing to the eyes - and more often than not, it's going to require a SPA.

Re: SPAs Were a Mistake

#503

Post by numlock86 » Thu, Mar 03, 2022, 7:17 AM UTC

SPAs are great, not a mistake. If you use the wrong tool for the job you can make look anything like a mistake. Sure, your two-page hobbyist blog won't benefit from being an SPA, having a well-partitioned Cassandra cluster holding your three-paragraph posts nor having a serverless autoscaling architecture, but that's how people like to build it.

Re: SPAs Were a Mistake

#504

Post by lmm » Thu, Mar 03, 2022, 7:19 AM UTC

porker wrote: post #478

lmm wrote: post #419

Earlier quoted context omitted.

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

Is this the Wicket you're referring to? https://wicket.apache.org/ What's the best intro you know to how it's components work, and the benefits and tradeoffs over other approaches?

That's the one. I learnt it by pair-programming (which is great but not necessarily replicable). From a quick search, their userguide has a fairly light introduction to why: https://nightlies.apache.org/wicket/guide/9.x/single.html#_w... . And the book https://livebook.manning.com/book/wicket-in-action/chapter-2... has a more detailed explanation of the what.

Re: SPAs Were a Mistake

#505

Post by shroompasta » Thu, Mar 03, 2022, 7:22 AM UTC

simonw wrote: post #479

rtpg wrote: post #464

Earlier quoted context omitted.

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…

"It also seems extremely uncontroversial that sending data for a single item is going to require less text generation than sending over that data + the entire page." And yet... so many SPAs feel so much slower than MPAs. They suck down MBs of JavaScript, constantly poll for more JSON and consume crazy amounts of CPU any time they need to update the page. If you're on an expensive laptop you may not notice, but most o…

Even if that is the case, is that your demographic?

Are those the people calling for an uber?

Are those people ordering off of doordash?

Furthermore, code splitting / lazy loading is available on many SPA frameworks so you don't have to download all the Javascript in one go.

Re: SPAs Were a Mistake

#506

Post by Tabular-Iceberg » Thu, Mar 03, 2022, 7:23 AM UTC

onaworkcomputer wrote: post #128

horsawlarway wrote: post #45

Earlier quoted context omitted.

I pretty strongly disagree with this. The distinct advantage of an SPA is that, done correctly, cached data lets you render pages instantly. Who CARES if the SPA had to make 3xRTT in the background, if it can serve the next page up instantly because that data is already present and cached, it's a huge win. The server rendered app will ALWAYS have to wait at least 1xRTT for every new render. The SPA does not. Still do…

> The distinct advantage of an SPA is that, done correctly, cached data lets you render pages instantly. Yeah, but full page caching is a thing, and in my experience, teams writing traditional server-rendered pages are much more aggressive in their use of response caching than are teams writing JSON APIs. Honestly, a Rails/Django/Laravel app with smart caching headers and a Varnish instance in front feels more reliab…

How does that work if a user is logged in and private data is visible on the page?

I’m thinking of building something that only renders public data on the server, and then later gets that which pertains to individuals through an API. But I don’t want to spend more time on a lot of complicated plumbing than on core functionality in my application.

A SPA seems like the path of least resistance here, since all you have to do is put the appropriate cache control headers on your API endpoints, and let the browser abstract it away for you. I know programmers like to build bespoke caching solutions, been there, done that, but you don’t actually need to.

My biggest gripe with SPAs is the overhead of building and maintaining an API for everything, but GraphQL takes away a lot of that pain.

Re: SPAs Were a Mistake

#507

Post by westoncb » Thu, Mar 03, 2022, 7:28 AM UTC

shkkmo wrote: post #490

westoncb wrote: post #375

Earlier quoted context omitted.

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

I get that that's the biggest problem, but there are plenty of people in the thread talking about how they're a bad idea in general (including the comment I was replying to)—which incidentally lines up with the (apparently) clickbait title "SPAs were a mistake".

Re: SPAs Were a Mistake

#508

Post by nfw2 » Thu, Mar 03, 2022, 7:36 AM UTC

porker wrote: post #487

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.

State is a pretty loaded word, but what I meant more specifically is complex application state, and by that I mean the ephemeral state that manages a user's usage of the application.

For example, in the real estate use case, there may be, all on the same page:

- a table of listings and grid of listings that can be toggled between

- a map that can be displayed alongside the table with all the listings plotted

- dynamic updates on the map that highlight listing when it is hovered on the table

- a detail modal that displays whenever any listing on the table or map is clicked

- pagination that can controlled from either the modal or the table

- selection state for each row on the table and a bulk action bar that conditionally appears when the row is selected.

- filters and search that need to work quickly and not disrupt the user experience

None of these things are particularly unusual or groundbreaking, but trying to control all these stuff via server-rendering or jquery would be a huge mess and potentially a jarring UX.

Re: SPAs Were a Mistake

#509

Post by nfw2 » Thu, Mar 03, 2022, 7:36 AM UTC

porker wrote: post #487

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.

As for your question about persisted data, yeah it definitely needs to be modeled on the backend, right? How much modeling should be done on the FE is a good question. This question is sort of why GraphQL exists. GraphQL provides a contract between the backend and the frontend about what the data sent between the two needs to look like. Apollo provides a pretty good and easy-to-use GraphQL implementation in my experience.

As for real-time updates, this hasn't been a real concern in most of my professional work. If I needed to support this, I think what I would do is:

1.) Define a clear set of actions for everything that needs to be streamed to users real-time (IE, I wouldn't try to stream the full state tree itself, this is where conflicts would arise)

2.) Determine how each action mutates the graphql tree

3.) Add a process that watches for these actions at the top of the React tree and manipulate the GraphQL cache as necessary in response to the incoming actions, (coming from a WebSocket connection, for example).

If you stream the actions, you may be able to resolve simultaneous edits naturally. Or, if you really want to block simultaneous edits, I think you should 1.) definitely ensure the edit is really blocked on the backend, and 2.) stream on "disable" action to the user via webso

Re: SPAs Were a Mistake

#510

Post by randomsearch » Thu, Mar 03, 2022, 7:54 AM UTC

i_have_an_idea wrote: post #292

randomsearch wrote: post #282

Earlier quoted context omitted.

SEO for SPAs is a solved problem

It is definitely not solved for the vast majority of SPAs out there. Where it is solved, it is not solved for free or cheaply, as it would've been if these apps used server-rendering tech.

Obv there’s next Nuxt etc but Doesn’t Google’s crawler “render” JS now?