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

131–140 of 637 posts

Re: SPAs Were a Mistake

#131

Post by kaba0 »

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…

It was probably never too beautiful of a technique, but JSF does solve this problem splendidly. You basically have a view-flow besides the usual ones and it can act in many of the ways SPAs can.

Re: SPAs Were a Mistake

#133

Post by onaworkcomputer »

horsawlarway wrote: post #103
zozbot234 wrote: post #64

Earlier quoted context omitted.

Preloading is a browser-native feature, you don't need a SPA for that. And just as often you can't know in advance what data will be requested by the user.

> And just as often you can't know in advance what data will be requested by the user. This is a cop-out. Storage is insanely cheap, and abundantly available on most machines. Plus the browsers will usually give it to you. Can I know precisely what series of pages this user might hit? Nope. Can I load ALL the data this user might need to read? Probably.

> Can I load ALL the data this user might need to read? Probably.

You can do that with HTTP/2 server push on a multi-page app, too. The main difference is that with an SPA, you get to reinvent it all yourself.

Re: SPAs Were a Mistake

#134

Post by kaba0 »

efdee wrote: post #82
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…

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.

This is pretty in line with grandparent’s comment in that the browser was simply not made for this - aka SPAs are sort of a hack on the traditional page-based approach.

Re: SPAs Were a Mistake

#135

Post by kizer »

Here's the thing: so-called "JAM stack" apps are the cheapest to run, right? I realized this while I was thinking about how to create the cheapest site possible. Mainly, you want to minimize bandwidth. Well, SPAs are designed to do this. The site gets cached on the first hit, and runs usually JSON requests in the background after. So I think a big motivation for building SPAs is because they're cheap to host/run.

Re: SPAs Were a Mistake

#136

Post by giantrobot »

horsawlarway wrote: post #103
zozbot234 wrote: post #64

Earlier quoted context omitted.

Preloading is a browser-native feature, you don't need a SPA for that. And just as often you can't know in advance what data will be requested by the user.

> And just as often you can't know in advance what data will be requested by the user. This is a cop-out. Storage is insanely cheap, and abundantly available on most machines. Plus the browsers will usually give it to you. Can I know precisely what series of pages this user might hit? Nope. Can I load ALL the data this user might need to read? Probably.

Storage is cheap but bandwidth is not guaranteed. Getting content from your server to my device is not necessarily fast. Making wrong assumptions about my device's environment makes for a poor experience for me.

Re: SPAs Were a Mistake

#138

Post by freedomben »

8note wrote: post #91
freedomben wrote: post #68

Earlier quoted context omitted.

Have you tried to use a heavily SPAed site from a slow, distant (high latency), or metered connection? A SPA that works and feels great from a big city quickly becomes unbearable when internet access isn't as ideal. There are ways to handle this nicely, but maybe 5% of devs actually think about and test that, and no PM will allocate sprint time for it.

Using the web at all is your problem there. If that's your targeted usecase, send an exe on a thumb drive, and get them to call you back over the phone

I know this is/was not your intention, but to be honest, I find that attitude insulting and frankly discriminatory.

The internet has become essential to modern life, and many people have no choice but to use it. Most of my monthly bills don't have any alternative to paying online. (Some will take a payment by phone but they'll charge a $20 "phone fee" or similar).

There are certainly sites/apps that just can't work without requiring a big and short pipe, but it's extremely defeatist to suggest that it's hopeless and we shouldn't even try.

You're certainly not alone with your opinion. I suspect that attitude is a big part of why this is such a problem nowadays.

Re: SPAs Were a Mistake

#139

Post by bastawhiz »

zozbot234 wrote: post #14
onion2k wrote: post #2

SPAs are a pattern that's been applied too broadly IMO, but it's going a bit far to call them a mistake. The aims of an SPA are pretty noble - the idea of essentially removing the network round trip when a user clicks on something is not a bad one. It means things are faster, they work if your connection is flaky, they can do things like offline support. Those are good features. They might not be actual requirements…

> 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 progressively with appropriate loading indicators. For SPAs that have ~long sessions, it's arguably a good thing to have multiple API calls, because each can be cached individually: the fastest API call is the one you've already cached the response for. This is stuff we were doing at Mozilla in 2012, it's nothing new.

There's also nothing stopping you from making purpose-built endpoints that return all the information you need, too. Your proposed solution (SSR) is literally just that, but it returns HTML instead of structured data.

Re: SPAs Were a Mistake

#140

Post by kizer »

stevebmark wrote: post #49

Don't limit this to SPAs, include the Jamstack, which has all the same problems, and the false promise that if you can statically render a few pages or parts of pages and put them on a CDN, everything will be fast. It won't, because to load dynamic content, you still have to do a lot of work and talk to a (gasp) centralized API over the internet. SPAs and Jamstack favor developer convenience over end user experience.…

But there's a cost savings, right? JSON requests for just the data necessary vs. sending the whole HTML page each time.

Personally I'd prefer to develop a website the old-fashioned way, but I see that the bandwidth savings is a major point for SPAs and if you're running a business...

Post reply on HN