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

191–200 of 637 posts

Re: SPAs Were a Mistake

#191

Post by sitzkrieg »

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.

ok dont look up how long grid layout has existed in wpf

Re: SPAs Were a Mistake

#192

Post by ColonelPhantom »

rosenjcb wrote: post #184
ColonelPhantom wrote: post #175

Earlier quoted context omitted.

Isn't a template essentially a "function" that takes data and returns a view? I don't have much experience with UI programming but I don't really see the conceptual difference.

No, the template is usually a static file that is read into memory and served over HTTP or locally if it's a JS only site. But before being served, it's being picked at via imperative operations. And if it's really bad, then when a user presses a button it triggers some event that actually statefully changes the view itself.

I don't see template operations as imperative, rather I see them as declarative: you write the HTML and declare lists/placeholders inside the HTML. You also don't generally do much with the data except insert it into HTML; the rest of the backend is responsible for fetching/etc the data.

Re: SPAs Were a Mistake

#193

Post by candiodari »

bastawhiz wrote: post #139
zozbot234 wrote: post #14

Earlier quoted context omitted.

> the idea of essentially removing the network round trip when a user clicks on something is not a bad one. Practical SPA's have many more network roundtrips than the equivalent server-rendered web interface. Every AJAX request is an extra roundtrip, unless it can be handled in parallel with others in which case you're still dependent on the slowest request to complete. With SSR, you can take care of everything with…

> Practical SPA's have many more network roundtrips than the equivalent server-rendered web interface. Every AJAX request is an extra roundtrip, unless it can be handled in parallel with others in which case you're still dependent on the slowest request to complete. This is largely solved with innovations like GraphQL (which you don't need a SPA to use). Pages that require multiple API calls can show their UIs progre…

What they're meaning is that the total time is longer for the SPA if you don't go all out (and nobody does).

SPA:

    1. get html from server (1 roundtrip)

    2. get resources (js/jpg/movies/gifs/favicon/...) from server (1 roundtrip)

    3. get ajax calls from server (1 roundtrip)

    4. process answer from server + update page (not a roundtrip, but not zero)
Vs traditional:

    1. get html from server (1 roundtrip)

    2. get resources from server (1 roundtrip)
Also if there are sequential ajax calls required to build the page (like a list -> detail view), it goes up a lot without speed oriented (very bad code style) API design. For instance you need a separate "GetListOfUsersAndDetailsOfFirstUser()" (or more general "getEverythingForPageX" calls). You can't do "GetListOfUsers()" and "GetUserDetail()" separately.

So to match traditional webpage total load time you cannot do any ajax calls in your SPA until after the first user action. And even then, you only match traditional website performance, you don't exceed it.

Time until the first thing is on screen however, is faster in SPA's. So it's easy to present "a faster website" in management/client meetings, despite the SPA version actually being slower.

You can make SPAs faster than traditional websites ... but, for example, you cannot use javascript build tools. Since you need to do the first calls server-side and have javascript process them, and only send the result of the preprocessing, and the resulting dom to the client, after optimization and compression. After that you need to then do image inlining, style inlining, etc. I know react can do it, but does anyone other than facebook actually do that?

Re: SPAs Were a Mistake

#194

Post by horsawlarway »

wackget wrote: post #170
horsawlarway wrote: post #54

Earlier quoted context omitted.

Yeah - I think a lot of it might be developers who don't understand that SPA and caching go pretty much hand in hand. I'll admit that can make your life as a developer harder sometimes (to be blunt - caching is hard - full stop) but an SPA rendering from cache is basically a rocket compared to a server rendered page on a bad connection. Absolutely no one enjoys waiting 2-5 seconds after clicking the back button to se…

If you read [his next blog post]( https://gomakethings.com/how-to-make-mpas-that-are-as-fast-a... ) you'll see he has lots of experience with architecting an advanced, cache-heavy multi-page application which works and behaves much like you describe.

Yeah, interesting.

I think that approach is fine if you have an application that's light on interactivity (like school curriculum or tutorial, in his case).

And I agree 100% on the service workers (Seriously, I'm right there with him - they're magic). I would also recommend leaning more heavily on persistent storage (localstorage/indexdb) but I'm also trying to handle offline only cases.

I think some of the advice falls down when you're genuinely trying to create an interactive experience. I probably won't expound much farther, since I really try to keep business out of HN, but... I write applications that have been used for following treatment programs in education environments - think speech therapy or ABA for autistic students, where the user is inputing data frequently - as often as once a second - and the UI is updating in response to calculations done client side, that influence the instructors program and plan in real time.

It's a lot of screens, often customized locally on the application, and removing JS (or even just writing pure js) hurts a lot. That's... hard to do with minimal js. Really, really hard.

Re: SPAs Were a Mistake

#195

Post by [deleted] »

trevex wrote: post #177
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

Isn’t this basically what NextJS and NuxtJS provide, if you only leverage their static rendering?

[deleted]

Re: SPAs Were a Mistake

#196

Post by unfocussed_mike »

WillPostForFood wrote: post #172
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

Do you lose performance because each page has to load the SPA?

Not if the SPA subsequently takes over, (internally) routing links it recognises. (Nuxt does this)

Re: SPAs Were a Mistake

#197

Post by gls2ro »

softwarebeware wrote: post #29

I'm not clear why the author thinks that "media sites, really" are the only SPA use case. Have they never used webmail (like GMail), map apps (like Google Maps), or social networks (like Twitter)?

I give you Google Maps is a perfect example maybe for SPA.

But Gmail? Why do we need SPA for that? Receiving emails notifications could be websockets and clicking on email should go to a new page displaying the email. I dont know if the initial gmail was SPA or not, but the current version is very very slow and consumes a lot of memory to display some emails that worked even in terminal clients, remember Pine?

The same for twitter? I anyhow have to press "Load 39 new tweets" to load the new ones so why is it a SPA? Just for that notification? If you would give me a twitter client where I need to refresh the page to load new tweets but works faster and consumes less memory I will happy use that.

Re: SPAs Were a Mistake

#198

Post by gowld »

antihero wrote: post #30

This article seems to be directed at dealing with people that use SPAs to make more content focused websites, which quite obviously are better made with the browser. However, for an application with a persistent UI, I fail to see how constant page loads and navigation just because "the browser can do this" make any sense at all. Even the example is a bit silly - SPAs that should be SPAs don't really have "links" per…

jQuery days were bad?

Re: SPAs Were a Mistake

#199

Post by [deleted] »

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…

[deleted]

Re: SPAs Were a Mistake

#200

Post by Zaskoda »

In my humble opinion, SPAs are not the fundamental mistakes. SPAs are applications. There's nothing wrong with having applications. The mistake was not maintaining a distinction between applications and content. The difference between a static document, a collection of hypertext documents, and a web application is very blurry. If it were less blurry, there would have been things we would have been able to do that we are not currently able to do.
Post reply on HN