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

161–170 of 637 posts

Re: SPAs Were a Mistake

#161

Post by horsawlarway »

giantrobot wrote: post #136
horsawlarway wrote: post #103

Earlier quoted context omitted.

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

if you cache well - you will absolutely use less bandwidth with an SPA.

Sure - that first load is going to be bigger, but literally every subsequent request will use less data.

I try to reward consistent and current customers - and I'm not selling a news article or a social media site...

Now - if you do things like attempt to refresh all of the cache often, then sure, you have some problems to deal with.

> Making wrong assumptions about my device's environment makes for a poor experience for me.

Tough shit? I go way out of my way to make sure that loads on bad lines (or no lines) don't interfere with my users. You could just as easily say "I'm on gigabit why is this app using my disk space? Making assumptions makes for a poor experience. WAAAH".

Re: SPAs Were a Mistake

#162

Post by rosenjcb »

slashdev wrote: post #24

I hate SPAs. I would never do another SPA again if it were up to me. It just adds too much mental context switching and overhead. I can develop fully server-side apps that are lighter, run faster, and at least 20% less development effort (I actually compared that for the same task: https://medium.com/@mustwin/is-react-fast-enough-bca6bef89a6 ). So why would I ever do an SPA again if it were up to me? I would use http…

Template based UI programming is like going back to the year 2007. Your views should be reactive. Elm, Flutter, React, Et Cetera understand this. Having a function that takes data and returns a view is much better.

Re: SPAs Were a Mistake

#163

Post by horsawlarway »

onaworkcomputer wrote: post #146
horsawlarway wrote: post #99

Earlier quoted context omitted.

Yes - that's literally exactly what I talked about. I can tell you - My app renders immediately in these cases, precisely because I lean heavily on a cache. I preload basically all the data a user might need at startup (prioritizing the current page) and then optimistically render from cache. I'm very familiar with these kind of situations (I have developed software designed explicitly to handle offline-only cases, a…

> 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

Re: SPAs Were a Mistake

#164

Post by specialp »

mdoms wrote: post #150
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…

At the risk of a pile on, this is what jQuery was brilliant for. And frankly the native browser APIs have caught up enough that scenarios like what you want to achieve are simple to implement with just a script tag and a sprinkling of JS. I don't know what "Stimulus controllers" or "Turbo frames" are but they don't sound necessary.

Yes. Nobody should have to make a SPA to accomplish what JQuery did with sprinklings of JavaScript. JQuery was maligned because many people used it to make all XHR requests all over the place resulting in non-deterministic async behavior. JQuery was made to make adding small bits of JS easy and work in almost all browsers.

Bringing in React and turning that non-deterministic events firing all over the place greatly improved that situation, but this has become if someone needs JS, bring in SPA framework. This is in spite of the browser world getting much better. So just as JQuery was used to make SPAs to bad effect, SPA frameworks have been used to do minimal JS actions in a bad way.

Re: SPAs Were a Mistake

#165

Post by stevebmark »

kizer wrote: post #140
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...

SSR by default, and then if you want, client side hydration and navigation so subsequent page loads happen in the client. However, the size difference between an HTML response and a JSON response is negligible, and HTML responses don't have to wait for Javascript to download, parse, execute, kick off off a request over the internet, get the data back, execute the result, and update the DOM. Browsers have literally decades of optimization to show HTML to users as fast as possible, and doing this in Javascript is fundamentally slower.

Re: SPAs Were a Mistake

#166

Post by toqy »

vinceguidry wrote: post #87

They were necessary from a perspective of "we need a way to develop a company's web presence in a way we can send kids to code camp to get the gist of." Of course they weren't a wonderful thing in terms of actually building sustainable infrastructure, but what's that to stand in the way of business's need to go to market yesterday? Code camps don't have time or resources to educate their students so we got the reinve…

I don't think that's accurate. SPA's arise from the desire to put something like Slack in a web page. If bootcamps are responsible for that, I don't see how. Isn't it more likely that they meet the demand rather than create it? And bootcamps taught Rails long before they taught React.

And let's be honest, making a server rendered site with some traditional Python framework is in many ways just as easy or easier than making a SPA.

Re: SPAs Were a Mistake

#167

Post by prmph »

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…

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

Re: SPAs Were a Mistake

#168

Post by giantrobot »

horsawlarway wrote: post #161
giantrobot wrote: post #136

Earlier quoted context omitted.

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.

if you cache well - you will absolutely use less bandwidth with an SPA. Sure - that first load is going to be bigger, but literally every subsequent request will use less data. I try to reward consistent and current customers - and I'm not selling a news article or a social media site... Now - if you do things like attempt to refresh all of the cache often, then sure, you have some problems to deal with. > Making wro…

No post body was provided.

Re: SPAs Were a Mistake

#169

Post by wackget »

aminerman wrote: post #40
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…

He was just unable to follow and understand the trend, and thinks that therefore the whole industry made a MISTAKE :D

>> He was just unable to follow and understand the trend, and thinks that therefore the whole industry made a MISTAKE :D

That's not true, though. 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 multi-page application which works and behaves much like an SPA.

It makes his anti-SPA post kind of redundant and a bit hypocritical, but he clearly knows roughly what he's doing.

Re: SPAs Were a Mistake

#170

Post by wackget »

horsawlarway wrote: post #54
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…

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.
Post reply on HN