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

181–190 of 637 posts

Re: SPAs Were a Mistake

#181

Post by hinkley »

zozbot234 wrote: post #126
hinkley wrote: post #107

Earlier quoted context omitted.

It doesn’t matter‽ SPAS push giant gobs of logic and CSS ahead of the Time To Interaction and cross their fingers that nobody will notice because it’s not supposed to happen the next time due to magical cache thinking. People have been ignoring actual research on caches for the entire time SPAs have been around. First time visitors have this as their first time visit. Occasional visitors show up after the last deploy…

To be fair, there are SPA frameworks that try to minimize the amount of logic that's shipped to the client, Svelte is an example, which should be as lean and efficient as any hand-coded JS. It's more of a side effect of what frameworks you use than SPA per se.

It's still a specialty sub-discipline though. Getting the base size down is a wonderful goal for a framework. But for the behavior the company is adding, there are both diminishing returns and a lot of surface area for bugs.

Re: SPAs Were a Mistake

#183

Post by k__ »

While Web2 is moving to SSR, I think SPAs will be a huge part of Web3.

SPAs are perfect for decentralized infrastructure like IPFS and friends. Same goes for mobile apps.

Re: SPAs Were a Mistake

#184

Post by rosenjcb »

ColonelPhantom wrote: post #175
rosenjcb wrote: post #162

Earlier quoted context omitted.

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.

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.

Re: SPAs Were a Mistake

#185

Post by amackera »

wackget wrote: post #169
aminerman wrote: post #40

Earlier quoted context omitted.

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 redunda…

I think it's just regular old click bait.

Re: SPAs Were a Mistake

#186

Post by prmph »

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.

Of course if only a small part of your app is interactive, then SPAs don’t come into the picture in the first place.

My point is that for very interactive web apps, this is a significantly better architecture that a huge monolithic SPA

Re: SPAs Were a Mistake

#187

Post by laerus »

ravenstine wrote: post #154

Nah, they weren't a mistake, at least not in isolation. Much of modern software development is a mistake, generally speaking. When you look at it that way, SPAs only failed in the sense that Object-oriented Programming failed, as well as the failure of various design patterns, microservices, write-once-run-anywhere, test-driven development, decentralization... I can go on and on with the number of engineering and com…

why do you think TDD failed :(

Doesn't every other science field work pretty much the same way though? We make mistakes, we iterate, we make new and better mistakes. It may be too obvious in software cause it's easy to create stuff and iterate very fast cause there aren't so many natural constraints. Someone may even argue that this is what makes software also an art.

Re: SPAs Were a Mistake

#188

Post by Zanfa »

ysavir wrote: post #160
Zanfa wrote: post #130

Earlier quoted context omitted.

> Where in this process did you need to start adding navigation via JS? Did that functionality really require JS, or was it implemented that way just because other parts are JS, and the trend was continued? Could you have used Stimulus controllers to manage functionality on the page itself, but when it came time to navigate to a new page, just done a basic browser redirect? In my specific example, the navigation itse…

Thanks for sharing! That helps me understand things better. > you need to hook into navigation APIs to handle backing into a partially-filled form after submitting to rebuild the UI to reflect the state before the user hit submit Was this a hard requirement for the feature or just a nice-to-have? I understand why you'd want that behavior ideally, but it also seems the sort of thing that adds much additional complexit…

A little bit of both probably. Supporting it when navigating back is probably a nice-to-have, but persisting file upload previews etc through a form submit that might fail due to some unrelated ActiveRecord validation (maybe a blank field) is a must.

Re: SPAs Were a Mistake

#189

Post by vlunkr »

hombre_fatal wrote: post #17
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…

Exactly. I've been in the position various times where I'm embedding a JS app on a page to help the user do something highly interactive, usually creating/editing content. And then as it's expanding to integrate with other things on the site, I start to wish more of the site was in the JS-app side of things. Sometimes I realize a SPA would have simply served the user better, and it doesn't necessarily take much to be…

The other thing people who hate SPAs need to think about is that rendering blogs/news/static sites isn't a problem that developers really work on anymore. Businesses will just pick from the huge pile of existing CMSs or hosted solutions because it's easier and cheaper. So if you're wondering why all these developers are building SPAs, it's because we're building custom applications, not blogs.

Re: SPAs Were a Mistake

#190

Post by rosenjcb »

WillPostForFood wrote: post #173
rosenjcb wrote: post #149

Earlier quoted context omitted.

I agree. These people hating on SPAs are mostly not frontend developers. They're backend devs that think returning an HTML page is all you need to do. Modern websites are very complex.

Or users who hate watching a whole application load to display some text.

If the only purpose of your site is to load some text or an image, go use a framework with SSG like NextJS. Then you get fast websites without having to pretend that writing stateful updates (e.g. jQuery) to the DOM is fun.
Post reply on HN