Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

It's time for modern CSS to kill the SPA

jonoalderson.com

Post reply on HN
Print view View original

51–60 of 516 posts

Re: It's time for modern CSS to kill the SPA

#51

Post by CSSer »

davidfiala wrote: post #40

SPAs are not about view transitions. TFA implies that fancy transition is important between pages (wrong!) and blames a "CMO" or "brand manager" rather than challenging their own preconceptions and exploring the value an SPA does add: - excellent frameworks for client side logic (interactivity) - separation of concerns (presentation logic vs. backend) - improved DevEx => inc. speed of development => happiness for all…

It's because it's catchy and repeatable, which really fits with this guy's broader claimed focus (SEO). I found it really ironic because I've built plenty of SPAs without page transitions of any kind (because it wasn't a relevant requirement) and only started adding them because view transitions made them easy.

Re: It's time for modern CSS to kill the SPA

#52

Post by pstuart »

chaps wrote: post #29
codingdave wrote: post #14

SPAs make sense when your users have long sessions in your app. When it is worth the pain to load a large bundle in exchange for having really small network requests after the load. Smooth transitions are a nice side effect, but not the reason for an SPA. The core argument of the article, that client-side routing is a solution for page transitions, is a complete misunderstanding of what problems SPAs solve. So absolu…

Is this true? When I think of old SPAs I think of java apps running in a browser. Those are definitely older than jQuery. (I love this silly site for downvoting this question.)

I think of java applets as being more akin to wasm; SPAs were/are a collection of html that recreate the experience of a "plain old" html web site.

Re: It's time for modern CSS to kill the SPA

#53

Post by brailsafe »

chaps wrote: post #29
codingdave wrote: post #14

SPAs make sense when your users have long sessions in your app. When it is worth the pain to load a large bundle in exchange for having really small network requests after the load. Smooth transitions are a nice side effect, but not the reason for an SPA. The core argument of the article, that client-side routing is a solution for page transitions, is a complete misunderstanding of what problems SPAs solve. So absolu…

Is this true? When I think of old SPAs I think of java apps running in a browser. Those are definitely older than jQuery. (I love this silly site for downvoting this question.)

Java applets and ASP.Net did have a superficial answer to this, as well as Flash, but they varied in terms of their ability to actually function as raw web interfaces using the URL to navigate between sections.

Being able to reliably and programmatically interact with client-side storage and the url, as well as improvements in DOM apis and commodification of hardware with more ram and faster faster CPUs, among many others factors, seem to have contributed.

Re: It's time for modern CSS to kill the SPA

#54

Post by ivape »

threatofrain wrote: post #23

I don't know what universe this SEO-consultant author lives in. The author gives Next & Nuxt as an example of the kind of frameworks going against his prescription, but that is so wrong. 1. Next won the war in the west, big time. Very very big time. Whenever people talk about new React apps they inadvertently mean Next. On the Vue side Nuxt is the default winner, and Nuxt is just the Next of Vue. That means that by d…

There was a war? News to me. Saying Next won is like saying React won. Nothing won, everyone just latched on to what they thought the crowd vetted. The blind can't lead each other. Most people that stuck to Angular or minimal or no-frameworks are truly wondering what the fuck are all these people talking about?.

Even the Facebook docs point straight to Next

Startups and SV jerk each other off by promoting each other (think affiliates). None of it means shit.

Next is probably a garbage framework, but it's people's livelihoods. It's very hard to erase something that literally defines people (yes, your resume is YOU).

Re: It's time for modern CSS to kill the SPA

#55

Post by epolanski »

andix wrote: post #17
varenc wrote: post #8

Earlier quoted context omitted.

What do you mean by 'interactive like a native app'? The article is focusing on two main parts of making things feel like an app: page view transitions and speed/preloading. To me, those seem like a big part of what makes a site/app feel interactive. And letting the browser do the work and having real URLs has other huge benefits I appreciate. But agree that for things like GMail, etc, a SPA approach definitely makes…

Imagine Gmail, ChatGPT, Slack, and so on as server side rendered websites, but with smooth transitions. This wouldn't work at all. Let's take slack as an example. We had those chat websites 20 years ago. The thread was in it's own frame and got periodically reloaded. It's just bad UX.

You are extremely confused, you can absolutely have client side JavaScript in a website and poll or stream whatever you want like chats.

It has nothing to do with being a static website or an SPA, nothing.

Re: It's time for modern CSS to kill the SPA

#56

Post by mym1990 »

da_chicken wrote: post #25
zeroq wrote: post #10

SPA is not only about seamless transitions but also being able to encapsulate a lot of user journey on the client side, without the need of bothering server too much. Let me give you an example - one of my biggest gripes about web ux is the fact that in 2025 most shops still requires you to fully reload (and refetch) content when you change filters or drill down a category. A common use case is when you come to a sho…

I don't know, I think the most painful aspect of having to do a full reload is how I efficient the site is. The actual data is a few KB, but the page itself has to download 100 MB and the web browser is burning through a GB of RAM. Like I don't find Hacker News to be egregious to navigate, and nearly every nav is a reload. It runs fine on my 2008 laptop with 4 GB of RAM. But I go to DoorDash on the same device, and i…

Hmm, I would say comparing Hacker News to DoorDash is not exactly apples to apples. There may also be ulterior motives to make a website slow(or at least not optimized) if the company wants to funnel people towards an app on the phone.

Re: It's time for modern CSS to kill the SPA

#57

Post by markbao »

The point of SPAs was never page transitions. I can’t name a single major SPA that does good page transitions, can you? They all just replace the content. And to take a popular SPA framework as an example, it’s almost impossible to do page transitions in Next.js because of the way routes are loaded. I know this because I added proper page transitions to Next.js and it has been an absolute nightmare.

There are two good reasons for SPAs that I can see:

1. Your app probably needs interactivity anyway; for most apps, it’s not just going to be HTML and CSS. Writing your app in some unholy combination of React and HTML is not fun especially when you need to do things like global state.

2. Loading the structure of pages up front so that subsequent data loads and requests are snappy. Getting a snappy loading screen is usually better than clicking and getting nothing for 500ms and then loading in; the opposite is true below I’d say 100ms. Not needing to replace the whole page results in better frontend performance, which can’t really be matched today with just the web platform.

Basecamp has probably invested the most in making a fairly complex webapp without going full SPA, but click around for like 30 seconds and you’ll see it can’t hold a candle in performance to SPAs, never mind native apps.

With that said, I agree that I’d want the web to work more like the web, instead of this weird layer on top. All the complexity that Next.js and SPAs have added over the years have resulted in more responsive but sometimes more tedious-to-build apps, and gigantic bundles. I just don’t think you can match the performance of SPAs yet with just HTML.

Re: It's time for modern CSS to kill the SPA

#58

Post by chaps »

chrisweekly wrote: post #47
chaps wrote: post #29

Earlier quoted context omitted.

Is this true? When I think of old SPAs I think of java apps running in a browser. Those are definitely older than jQuery. (I love this silly site for downvoting this question.)

Java applets are entirely distinct from SPAs, at least as that term is used in the webdev community.

Hm, alrighty then. Seems like an unnecessary distinction to me in that it deeply constrains what SPAs can be, but I'm not a webdev.

Re: It's time for modern CSS to kill the SPA

#59

Post by ec109685 »

zeroq wrote: post #10

SPA is not only about seamless transitions but also being able to encapsulate a lot of user journey on the client side, without the need of bothering server too much. Let me give you an example - one of my biggest gripes about web ux is the fact that in 2025 most shops still requires you to fully reload (and refetch) content when you change filters or drill down a category. A common use case is when you come to a sho…

In almost all cases the back swipe in the spa resets you to the top of the page, navigating out of the app and back in doesn’t work, etc. It’s really hard to build a multi page spa that feels good.

Re: It's time for modern CSS to kill the SPA

#60

Post by austin-cheney »

andix wrote: post #22
austin-cheney wrote: post #13

Earlier quoted context omitted.

You really don’t need the frameworks for web apps either.

I guess you never worked on a complicated web app that was 100% jQuery, because web frameworks were not a thing yet.

I was a JavaScript developer for about 15 years and I moved onto something else because most of the people doing the work can't program. Not at all. I got tired of being held hostage by people who couldn't function without more help than they needed.

I also get tired of the arguments from ignorance. The you don't know how hard life is type of bullshit arguments. I do know because I have done this work, probably much longer than you, and its not as challenging as you are claiming.

Post reply on HN