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

381–390 of 637 posts

Re: SPAs Were a Mistake

#381

Post by Closi »

emteycz wrote: post #108
Closi wrote: post #59

Earlier quoted context omitted.

I think the fundamental issue with SPAs is that it's building on multiple levels of technology that fundamentally weren't designed to support being a single page application. The browser multiple pages paradigm is pretty much how the web evolved, so SPA's just end up being one giant hack to get everything working. UWP/WPF/any other desktop app framework demonstrates how easy developing a 'single page application' can…

At least since HTML5 and CSS3 and ES6 (so many years already) these technologies are made for SPAs. There aren't many better UI frameworks, and WPF isn't that by a long shot.

I wouldn't really say that - CSS3 was made in 1999 so was hardly made for SPAs.

Additionally HTML5 wasn't really 'made for' SPAs, it added features to HTML which could help support SPA's but it's main design decision was to be 100% backwards compatible with the older HTML spec. HTML5 is made for SPAs the same way that a stretched limo is made for commuting.

Re: SPAs Were a Mistake

#382

Post by philipphutterer »

well summarized.

its easy to make bad SPAs nowadays. imo more time needs to be spent in the tool/environment/framework/language selection and evaluation process.

also, many SPAs cant even handle basic forms correctly anymore, because developers learn more javascript than html5. like the author pointed out, rebuilding features in js that already exist, just because one is unaware of the fact that it exists or what the underlying design choices have been, often is a bad idea.

are there actually still people that care about noscript? i mean, i get that most people dont care and js is enabled by default in most browsers, but the no-js-web-world is also quite interesting.

Re: SPAs Were a Mistake

#383

Post by thevagrant »

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. It also ensures end users are endlessly frustrated by inconsistent UI / UX handling.

Re: SPAs Were a Mistake

#384

Post by tracker1 »

dlisboa wrote: post #179
prmph wrote: post #167

Earlier quoted context omitted.

Exactly, the best approach seems to be where the app is composed of traditional pages with server navigation between them, but each page is implemented as an SPA. This approach eliminates the need for a client-side router, keeps any centralized page state small, and improves the SEO and bookmarkability of the app. I have implemented this architecture in several projects, and it’s effective

I disagree with that. There's no real reason for each page to be a separate SPA, most likely only a small part of that page will be interactive, and most of it will be cacheable. Extracting only the interactive parts of a page into components is what I'm talking about. In some cases that'll be all of the page, but there are very few apps that meet that criteria.

Not only that but bundle splitting allows for extra areas of the application to be loaded at runtime on demand.

All of that said, I'm not opposed to approaches like Next/Nuxt/Aleph.

Re: SPAs Were a Mistake

#385

Post by tracker1 »

manigandham wrote: post #237
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.

What’s wrong with razor pages? They’re fantastically simple and productive. And WebForms wasn't a misunderstanding. It was a deliberate and brilliant design that brought WinForm developers and their experience to the web and allowed them to build complex web apps two decades ago that still work to this day.

I just remember massive state being injected into forms, and it wasn't pretty, was massive at times and just unpleasant regarding WebForms. It was fine for internal apps with a network connection, the experience was horrible if you were a dialup user. Especially in components that a change triggered effectively a full server round trip to update the whole page.

It got better by ASP.Net 3, but MVC/Razor was much, much better imo.

Re: SPAs Were a Mistake

#386

Post by v0idzer0 »

I usually bite my tongue when these articles pop up weekly, but let’s ask ourselves a question: did Facebook, Apple, Amazon, Netflix, Google, etc all make a terrible engineering mistake? Or did this guy with a blog miss something?

I’ve recently worked on converting a large code base to an SPA and the improvements in DX, UX and performance are enormous. Even the old timers that resisted the project have all come around.

This doesn’t mean your blog should be an SPA. It shouldn’t. but reducing the valid use cases for them to Youtube is equally ignorant.

I generally agree they are being overly applied, but that’s not an indictment on the technology whatsoever. Fads in technology happen (“rewrite it in rust” is a recent one). The fact that many people are falling into this fad says nothing about Rust as a technology other than people love it enough to overuse it.

Re: SPAs Were a Mistake

#387

Post by tracker1 »

mike_hearn wrote: post #259
efdee wrote: post #82

Earlier quoted context omitted.

In my opinion, UWP/WPF/aodaf makes it easy because it just doesn't implement the things a user is used to in a browser (bookmarkability, back button, ...). If you ignore those things in your SPA, much of the "cruft" is negligible.

Many desktop apps have back buttons, and of course mobile apps always have them. They're also more reliable; there is no desktop/mobile equivalent of the "warning: need to re-POST this form" problem. As for bookmarks, that's semi-right, but the web platform conflates the back button with bookmark-ability in ways that are quite confusing. If you want the back button to get the user out of your settings screen, then yo…

You could just use `history.back()` instead of pushing a new url... beyond this, you may need to listed to history changes so that your UI response... most spa frameworks have a router that supports this without much issue.

Re: SPAs Were a Mistake

#388

Post by lmilcin »

I love SPAs. When used correctly.

SPA stands for Single Page Application.

It makes sense when what you expect is an actual application. Tools that just happen to be running within a browser for convenience. The browser just happens to be delivery mechanism.

On the other hand if the user expects navigable, hyperlinked content, SPAs just get in the way of navigation and make users' lives miserable for no good reason.

I want to move forward, move backwards, make a bookmark, open multiple tabs. It is frustrating when the application makes it impossible when those would be completely reasonable operations on, say, news site.

Re: SPAs Were a Mistake

#389

Post by giaour »

horsawlarway wrote: post #163
onaworkcomputer wrote: post #146

Earlier quoted context omitted.

> I preload basically all the data a user might need at startup This can be a great strategy when you're dealing with bounded data that's not sensitive, but it's important to recognize that this approach is often inappropriate. A web app may be allowing users to wander around terabytes of data, or it may need to make highly consistent authorization determinations before allowing a user to see specific data, or you ma…

> Still doesn't make an SPA the right fit for everything

I would counter that data freshness and authZ concerns make SPAs a poor fit for most things. What you're proposing in this thread is that good SPAs essentially need to hold all data client side and not have to worry about out of band cache invalidation, which seems like a pretty rare set of circumstances.

Re: SPAs Were a Mistake

#390

Post by gefhfffh »

lolinder wrote: post #376
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…

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…

> a bit of extra text

Doesn't really sound like an application, but a website.

In a web app it can happen that you use it for an hour without the backend doing a single thing.

> There are only fewer languages to deal with if you aren't in charge of writing backend code.

You don't have to deal with them at the same time

Post reply on HN