Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SPAs Were a Mistake

gomakethings.com

Post reply on HN
Print view View original

471–480 of 637 posts

Re: SPAs Were a Mistake

#471

Post by nfw2 »

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 complex session state and full interactivity that a SPA provides trivially.

This whole thread seems like a huge echo chamber of people who seem annoyed that FE development is getting too complex.

But do you all really think that the entire industry is so disconnected from its needs, and the entire community of FE engineers just have their heads in the sand about the requirements of working in their domain of expertise?

And to everyone saying SPAs are sometimes useful in very rare occasions, what web apps do you use regularly? Gmail? Jira? Slack? LinkedIn? Figma? Notion? Docs? Dropbox? Airbnb? Netflix? Airtable? ...

How many of these use javascript to do the heavy lifting on the client?

Re: SPAs Were a Mistake

#472

Post by ksec »

whatshisface wrote: post #312
finniananderson wrote: post #303

Earlier quoted context omitted.

Totally agree. We built a product in ~5 months with real-time collaboration, extensive interactivity, Oauth, Stripe and Gmail integrations with a standard Ruby on Rails stack. It's rock-solid, performant, dead-simple and extremely productive to work with. Why're we throwing away years of learning to build unstable, complex and inaccessible applications?

> Why're we throwing away years of learning to build unstable, complex and inaccessible applications? 1. Smart people seek out difficult problems. 2. Difficult problems drive the creation of complex, niche tools, that bear cultural associations with the smart people who made and use them. 3. People who want to be smart seek out complex, niche tools.

Smart and YOUNG, seek and try to conquer complexity, pushing open The Gate of Truth. Only to be completely consumed and burned by it.

There are abundance of smart people. Wisdom, has and possibly always will be in short supply.

Re: SPAs Were a Mistake

#473

Post by notatoad »

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…

>e.g. you're building Figma

i think what it comes down to is if you have to make a decision of "should i build an SPA?" the answer is no. the web is good at doing pages. if your app has pages, use the web's default page mechanism.

and i don't say this as a hater of single-page apps. i love webapps, and i think that building a webapp should be the default for most cases. there's a lot of apps that don't naturally break into a "page" metaphor, and all the technologies that are part of the single-page app concept are great for those cases.

figma is a perfect example, because there's no obvious division between what would be one page versus another. it's not a paginated website that has been built as an SPA, it's literally just one page that has a whole bunch of interactivity.

Re: SPAs Were a Mistake

#474

Post by Ziggy_Zaggy »

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…

Totally agree.

Re: SPAs Were a Mistake

#475

Post by baby »

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 suggest we go back to iframes

Re: SPAs Were a Mistake

#476

Post by nfw2 »

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

Re: SPAs Were a Mistake

#477

Post by chilldsgn »

me_me_mu_mu wrote: post #176

I had the pleasure (aka hell mode) of building a content site as a SPA because some non-technical manager kept pushing it (it was one of those companies). It was an insane task to meet all the SEO requirements, we ended up doing server rendered pages, and keep in mind this was years ago so there was not a whole lot of support or tutorials on how to do it. Oh well, I got paid to learn a bunch of new stuff so I can't c…

Yeah, I was gonna say SPAs are not really good for marketing type of sites. Doesn't work easily with SEO. I learned this the hard way, but there are other use cases for SPAs. Just don't use it for sites that require good SEO.

I am pushing for a rebuild of that site using Laravel and minimal amount of javascript, actually :D

Re: SPAs Were a Mistake

#478

Post by porker »

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

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?

Re: SPAs Were a Mistake

#479

Post by simonw »

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…

"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 of the world sees the internet through a cheap, CPU and bandwidth constrained Android phone. And SPAs on those are just miserable.

Re: SPAs Were a Mistake

#480

Post by zh3 »

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…

>....taking advantage of the supposed benefits of SPAs: there are no snazzy animations between states....

If that's the main benefit, let's hear it for MPAs. I want a website that's fast, responsive, clicky, sharp and to the point - not some soft-focus pastel cartoon movie. As the author says, that's fine for audio/video sites (and reasonable for other entertainment-focussed sites) - for information sites it just gets in the way (animated elements - especially persistent ones - are a terrible idea when trying to concentrate on textual content).

Post reply on HN