[HN Gopher] It's time for modern CSS to kill the SPA
___________________________________________________________________
It's time for modern CSS to kill the SPA
Author : tambourine_man
Score : 140 points
Date : 2025-07-25 21:08 UTC (1 hours ago)
(HTM) web link (www.jonoalderson.com)
(TXT) w3m dump (www.jonoalderson.com)
| andix wrote:
| This reads more like "ditch Next.js" for traditional SSR.
|
| A good SPA has a lot of benefits. Because it can be interactive
| like a native app. It can only use those benefits, if it is
| interactive to some extent (like gmail or google docs). Smooth
| navigation is a very bad reason for picking a SPA.
| varenc wrote:
| 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 sense. I just think most SPA sites I come
| across aren't in that category.
| andix wrote:
| 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.
| strken wrote:
| I think you're using "single-page app as opposed to no or
| limited JS on the client" while an alternative would be
| "single-page app as opposed to multi-page app". There's no
| reason you have to implement something like Slack by
| reloading an iframe.
| andix wrote:
| Not reloading the document via HTTP while updating the
| content is the definition of a SPA.
| epolanski wrote:
| 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.
| ndr wrote:
| I'm against bloat as anyone, but to see a wildly different
| perspective check out what people working on local-first have
| been doing.
|
| You can pay some upfront cost and have wildly more performant
| apps.
| ozim wrote:
| _Rolling eyes_
|
| Another person mixing up web apps with web sites.
|
| We do need frameworks for web apps. Yes people were wrongly
| making websites using frameworks.
|
| But I am busy building web apps and without frameworks it is not
| feasible to build one.
| andix wrote:
| Exactly. I remember the times when webmail clients were SSR
| applications. Roundcube and Gmail were game changers. Webmail
| finally felt smooth and usable.
|
| Web shops are somewhere in the middle, they need a little bit
| of interactivity for the cart, especially if the user opens
| multiple tabs.
|
| But static websites should never be SPAs.
| austin-cheney wrote:
| You really don't need the frameworks for web apps either.
| andix wrote:
| I guess you never worked on a complicated web app that was
| 100% jQuery, because web frameworks were not a thing yet.
| ozim wrote:
| Second that.
|
| Add to it dev churn each 6 months one dev leaves an new
| joins full of fresh new ideas how to jquery. In the
| meantime also 2 freelancers adding their stuff.
| zahlman wrote:
| I did, around 15 years ago. It was honestly not that bad.
| cweagans wrote:
| What if I told you that you didn't need jQuery either.
| andix wrote:
| Using the DOM APIs directly? Please do that. Have fun!
| austin-cheney wrote:
| I do it and its just not significant. You should try it
| before evoking a holy war against it.
| austin-cheney wrote:
| 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.
| micromacrofoot wrote:
| I support a lot of this, especially for sites that don't _need_
| to be applications... but SPAs aren 't just about flashy
| transitions and persistent elements. If you've got a bunch of
| live data you want to change on interaction an SPA is still hard
| to beat.
| sergiotapia wrote:
| This article would benefit from an example page to show how these
| "feel".
| prisenco wrote:
| Here are a series of demos. They work in Chrome or Safari.
|
| https://view-transitions.chrome.dev/
|
| Here's an older, more designed demo that only works in Chrome.
|
| https://live-transitions.pages.dev
| austin-cheney wrote:
| I completely agree.
|
| My SPA navigation solution is just simple CSS toggle of display
| none/block and then force it on page load if there is a matching
| URL fragment. Total JavaScript to make this SPA navigation is
| about 20 or so lines of JS. Everything else is CSS and
| WebSockets. The state management is almost as simple.
| zeroq wrote:
| 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 shop, click on "books"
| (request), then on "fantasy" subsection (another request),
| realize the book you're looking for is actually a "sci-fi", so
| you go back (request, hopefully cached) and go to "sci-fi"
| (another request).
|
| It's much better ux when a user downloads the whole catalogue and
| then apply filters on the client without having to touch the
| server until he wants to get to the checkout.
|
| But it's a lot of data - you may say - maybe on Amazon, but you
| can efficiently pack sections of most shops in data that will
| enable that pattern in less kilobytes that takes one product
| photo.
|
| I've been building web apps like that since ca. 2005 and I still
| can't understand why it's not more common on the web.
| throwaway7783 wrote:
| HTMX (and similar) solves a lot of this. It so happens that we
| end up building two apps one frontend and one backend with SPAs
| as built today. I'd rather build a lot of it on the server
| side, and add some dumb interactivity on the client (show/hide,
| collapse/expand, effects). There is still a place for SPA
| though.
| da_chicken wrote:
| 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 it takes 30s to
| load up a list of 50 items. They give you a countdown for a
| double dash, and I genuinely don't think it's possible to order
| some curry and get a 6 pack of soda in less than 3 minutes. And
| 2.5 minutes is waiting for it to render enough to give me the
| interface. Almost none of it is a full reload.
| cosmic_cheese wrote:
| Yeah, the enemy isn't the need to reload, it's reloading
| taking a long time due to too much garbage that's not the
| content the user is interested in having to come down off the
| wire and render. A site that requires an occasional split
| second reload is always going to be preferred to a behemoth
| that doesn't need reloading but has me staring at blank
| screens and loading spinners half the time I'm using it.
| nine_k wrote:
| An SPA can be lean and fast. React is the prevailing Web
| framework today? Preact is like 5 KiB of code.
|
| What makes SPAs unwieldy is not the technology but the lack
| of desire to optimize. It loads fine on yesteryear's Macbook
| Air? Enough, push it.
|
| I very well remember heavy, slow-loading websites of, say,
| year 2000, without any SPA stuff, even though lightweight,
| quick-loading pages existed even then, in the epoch of dial-
| up internet. It's not the technology, it's the desire to cram
| in more, and to ship faster, with least thinking involved.
| mym1990 wrote:
| 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.
| dzhiurgis wrote:
| Gmail takes 3s to load. And HN is a website, not an app.
| ec109685 wrote:
| 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.
| dzhiurgis wrote:
| Never thought about scroll position (tho SPA I've built
| recently I think does it ok). How do you solve it?
| throwawaylaptop wrote:
| I'm a self taught PHP/jQuery/bootstrap guy with a small
| saas. I handle page scroll position by literally saving it
| into some session data cookie and when you go back I check
| where your scroll was and I fix it for you. I'm not a
| genius or skilled... But I cared so I did it.
| ndriscoll wrote:
| You can do that with checkbox selectors. e.g. see [0]. Note
| that I don't really do frontend and I asked chatgpt to vibe
| code it, so this may not be the best way to do it.
|
| [0] https://html-
| preview.github.io/?url=https://gist.githubuserc...
| LegionMammal978 wrote:
| There's still value in web applications what can perform most of
| their operations client-side, when feasible. Lots of websites
| seemingly operate under the assumption of "If the client manages
| to connect to the server once, then surely it can maintain a
| stable, low-latency connection in perpetuity." This renders those
| websites unusable on flaky connections or with very high latency.
| Of course, plenty of SPAs are guilty of using 15 million
| unnecessary round-trips, but I worry that the current SSR-
| everywhere push will worsen this effect.
| Cthulhu_ wrote:
| Consider also the origins of SPAs and their accompanying
| backends - mobile apps. I've worked with various projects where
| both web and mobile frontends would be using the same backend.
|
| In theory you could build a SSR on top of that same backend,
| but for some reason that feels wrong, like an extra layer of
| indirection.
| codingdave wrote:
| 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 absolutely, if
| you shared that misunderstanding of SPAs and used them to solve
| the wrong problem, this article is 100% correct.
|
| But SPAs came about in the days of jQuery, not React. You'd have
| a complex app, and load up a giant pile of jQuery spaghetti,
| which would then treat each div of your app is its own little
| mini-app, with lots of small network requests keeping everything
| in sync. It solved a real problem, of not wanting to reload all
| that code every time a user on an old browser, with a slow
| connection, changed some data. jQuery made it feasible to do SPAs
| instead.
|
| Later, React and other frameworks made it less spaghetti-like.
| And it really took off. Often, for sketchy reasons. But the
| strongest argument for SPAs remains using them as a solution to
| provide a single-load of a large code bundle, that can be cached,
| to provide minimal network traffic subsequent to the load when
| the expected session time of a user is long enough to be worth
| the trouble of the complexity of an SPA.
| buffalobuffalo wrote:
| I don't know if a bunch of sloppy jQuery modules were ever
| really a viable option for an SPA. People tried to do it, sure,
| but I'd say the SPA era really started with backbone.js
| kassner wrote:
| ExtJS/Sencha was quite powerful and complete. I've built tons
| of SPAs with it in the late 00s.
| TimTheTinker wrote:
| Low-bandwidth/spotty connections (combined with aggressive
| caching) are one of the strongest cases in favor of SPAs
| (emphasis on the A for Application, not website). Visit (and
| cache) the entire frontend for the app when you have a good-
| enough connection, then further use of the app can proceed with
| minimal bandwidth usage.
| andix wrote:
| Latency might even be more relevant than bandwidth.
| Especially if it's a good SPA, that uses optimistic updates
| (or sync), and some kind of caching for fetching data
| (tanstack query or similar).
| cosmic_cheese wrote:
| It really depends. There's a lot of SPAs which are
| practically unusable on a bad connection simply because it's
| a challenge to even get the whole thing loaded in the first
| place. There's been several occasions where I've had poor
| cell connectivity and a huge chunk of the web was effectively
| off limits due to this.
|
| So in addition to aggressive caching, I'd say keeping the
| app's file size down is also pretty important to making it
| useful on poor connections. That's frequently something
| that's barely optimized at all, unfortunately.
| chaps wrote:
| 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.)
| chrisweekly wrote:
| Java applets are entirely distinct from SPAs, at least as
| that term is used in the webdev community.
| chaps wrote:
| 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.
| threatofrain wrote:
| Those apps came from an era when these terms weren't even
| coined yet.
| pstuart wrote:
| 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.
| brailsafe wrote:
| 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.
| kassner wrote:
| ExtJS came about in the late 00s, and it was possible to
| build SPAs with it, overlay/draggable windows, and had
| powerful grid/form components.
| kassner wrote:
| https://extjs.cachefly.net/ext-3.4.0/examples/
| unfortunately most of the data examples don't work, but I
| believe everyone browsing the web back then remembers this
| blue tinted interface.
| Cthulhu_ wrote:
| > and load up a giant pile of jQuery spaghetti
|
| I'll have you know I spent time on organizing and structuring
| my code with early JS design patterns like IIFEs to limit
| scope, lazy loading of modules, and minification.
|
| Anyway, in my experience, AngularJS was the biggest attempt at
| making structured front-end applications, and it really
| appealed / appeals (Angular is still very popular apparently)
| to Java developers; biggest ones was its modularization (which
| wasn't a thing in JS yet), dependency injection, and
| testability.
|
| When we started out with an app in Backbone (to replace a Flex
| app because it wouldn't work on the ipad), I actually advocated
| against things like testing, thinking that the majority of
| functionality would be in the back-end. I was wrong, and the
| later AngularJS rebuild was a lot more intensive in front-end
| testing.
|
| Of course, nowadays I'm repulsed by the verbosity, complexity
| and indirection of modern-day Angular code. or Java code for
| that matter.
| QuadrupleA wrote:
| Side note, sick of jQuery being always associated with
| spaghetti in the tech lexicon.
|
| Any Turing-complete system is spaghetti in the hands of bad
| programmers. And simple & clear in the hands of good ones who
| know how to design.
| sverhagen wrote:
| Languages... (is jQuery a language, I guess so, let's go with
| that)... live in a context... there is culture, tooling,
| libraries, frameworks. Some languages have good culture, some
| have bad culture. I guess it's not even so black and white:
| language have good or bad culture in different areas:
| testing, cleanliness, coding standards, security, etc. If
| jQuery is misused in the hands of bad programmers ALL THE
| TIME, that becomes the culture. Not much to do about it
| anymore once the concrete has set. You can't still be an
| exception to rules, good for you! But that doesn't change the
| culture...?
| jiggawatts wrote:
| The real reason SPAs are popular is because JavaScript is the
| new Visual Basic and there are millions of developers that know
| nothing else.
|
| Workforce market forces like that have a vastly greater effect
| than "bandwidth optimisation".
|
| My evidence for this is simple: every SPA app I've ever seen is
| two orders of magnitude slower than ordinary HTML would have
| been. There is almost never a bandwidth benefit in practice.
| Theoretically, sure, but every app I come across just dumps
| half the database down the wire and picks out a few dozen bytes
| in JS code.
|
| Another angle is this: if you had a top 100 site with massive
| bandwidth costs, then sure, _converting_ your app to a SPA
| might make financial sense. But instead what I see is tiny
| projects _start_ as a SPA from day one, and no chance that
| their bandwidth considerations -- either cost or performance --
| will ever be a factor. Think internal apps accessed only over
| gigabit Ethernet.
|
| I've seen _static content_ presented as a SPA, which is just
| nuts to me.
| geraldwhen wrote:
| Can't hire for anything else. Competence in development no
| longer exists. And AI is making this march to idiocy worse.
| matt_s wrote:
| If you work at a place that has a modern CI/CD pipeline then
| your multiple deployments per day are likely rebuilding that
| large bundle of JS on deploy and invalidating any cache.
|
| HTTP 2 has been adopted by browsers for like 10 years now and
| its multiplexing makes packaging large single bundles of JS
| irrelevant. SPA's that use packaging of large bundles doesn't
| leverage modern browser and server capabilities.
| prisenco wrote:
| The View Transitions API is beautiful and I can't wait for it to
| become widely available.
|
| I've soured on SPAs in the past few years. So much more can be
| done with standards than people realize. SPAs were best for
| specific use cases but we made them the default for everything.
| Marketing pages are built in React! Basic pages with marketing
| copy have a build step and require hundreds of megabytes of
| dependencies.
|
| Like the author I've transitioned to a mantra of "let the web be
| the web."
|
| But we have a whole generation of developers and designers that
| have come of age with SPA and mobile-like ux as standard. Getting
| everyone back to basics and understanding hypermedia, markup
| languages and cascading styles is a big ask.
| 725686 wrote:
| "The View Transitions API is beautiful and I can't wait for it
| to become widely available."
|
| a few comments below
|
| "The view transitions API is a disaster."
|
| I love HN.
| nosefurhairdo wrote:
| This argument is tired and ignorant. Try building linear.app
| without a SPA framework. The idea that "Native CSS transitions
| have quietly killed the strongest argument for client-side
| routing," is dubious at best.
| 0xCMP wrote:
| This doesn't seem fair to say. Linear is special even among
| SPAs; it's by far not the norm. No one said "ban SPAs and
| remove javascript from the browser".
|
| Linear's speed comes from being "offline-first", but I
| challenge you to name almost any other product in common usage
| that does it that way. It's just not common. On the other hand
| if I want to buy tickets I'd rather most of that website be SSR
| and do SPA where you actually still need it. Or forums, news
| sites, blogs, and informational sites.
|
| There is so much out there that would be better developed with
| SSR and then use CSS to make it feel SPA-like than to actually
| be a SPA.
| epolanski wrote:
| No one said SPAs have no place, but 99% of websites out there
| don't need to be one.
| unsupp0rted wrote:
| One of the reasons people like SPA so much is componentization.
|
| Here's my header component, and all its scoped CSS, and here are
| the 5 subcomponents that make it up, and all their individual
| scoped CSS.
|
| Page transitions are 0.001% of the desire to go the SPA route.
| TheRealPomax wrote:
| Fun fact: custom elements exist. They're just as hard to work
| with as React components (i.e. complete nonsense until you stop
| fighting them and do it right). Except they don't violate the
| browser model and don't require you to be married to a specific
| framework.
| threatofrain wrote:
| 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 default, by reflexive
| instinct, people are choosing Next and MPA as their strategy. If
| you want to correct the overly extreme pendulum motion then you
| should be telling people to try out SPA. The last 8 years has
| been a feverish push for MPA. Even the Facebook docs point
| straight to Next, totally deprecating Create React App. This is
| also Facebook ceding their battle to Next.
|
| 2. Whenever people complain about the complexity of Next, they
| are complaining about the difficulties of cutting edge MPA
| strategy, which evolves on a year to year basis. SPA on the other
| hand is a story that has frozen in time for who knows how many
| years. Almost a decade?
|
| 3. Doing MPA is strictly harder than doing SPA, much much harder.
| You have to observe the server/client distinction much more
| closely, as the same page may be split down the middle in terms
| of server/client rendered.
|
| 4. If you're writing an SPA and want to be more like MPA and load
| data at the time of hitting a user-navigable endpoint, that's on
| you, benefits and costs and all. You can also load data with
| anticipation so the client navigation is basically instant.
|
| 5. For every sexy SEO-able front-facing property you're going to
| have many teams with internal apps or dashboards backing that
| front-facing property. That's where many React devs are employed.
| Do not unnecessarily take on burden because you're so eager to
| ship the first "frame" of your app in a perfect way.
| ivape wrote:
| 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).
| threatofrain wrote:
| > Startups and SV jerk each other off by promoting each other
| (think affiliates). None of it means shit.
|
| No, this is FB ceding the battle. They absolutely didn't want
| this. They dropped CRA because social media celebrities were
| shitting on the React team for lacking the judgement to know
| they lost. Dan Abramov had to do a complete 180 in a single
| day, after writing a long thoughtful essay in defense of CRA.
| ivape wrote:
| You are in your own little universe. Social media
| celebrities shitting on React? I don't even want to enter
| your world.
|
| "Bro, you should see the celebrities shitting on React"
|
| Like WHO!? What developer celebrity, what universe have I
| been missing out on?
|
| Anyway, I do love me a good ol' fashioned "fuck SPAs, back
| to HTML" punching bag post on HN. It's always the same
| discussion over and over.
| afavour wrote:
| Wars, battles, personalities on social media... I don't
| want to sound too much like a grouchy old man but these
| frameworks are tools. Nothing more than that. I can't
| understand why anyone would become emotionally invested in
| any of them.
|
| When starting a project the right move to examine what best
| fits your project, not which one was recently victorious in
| a war. I've grown to dislike React because I see it being
| abused so often for a site where it isn't necessary. There
| are plenty of projects where it _is_ necessary too, but
| that's not universal.
| lunarcave wrote:
| I don't know how I feel about this one, honestly.
|
| > Build a site like a site. Use HTML. Use navigation. Use the
| platform.
|
| Sure, but what about all the other problems that aren't solved by
| View Transitions? There's some truth to the fact that frameworks
| like Next.js has jumped the shark. But they're not solving the
| problems of _just_ the SPA.
| ivape wrote:
| Websites and apps that feel like quality are generally made by
| people who can achieve it. You'll get shit static sites or shit
| SPAs if you have shitty devs. It's not beyond reason. If you are
| shitty chef, your food is going be shitty. So yeah, here's the
| big secret about programmers:
|
| _They are mostly shitty_
|
| ---
|
| Interestingly, every landing page or website for recent AI apps
| have looked AMAZING. Designers and standard website developers
| are totally on point. It's just, crappy developers who can't
| create a rich experience on top of incredible design that's the
| issue. CSS is not going to fix what can't be fixed (some people
| are not supposed to be in this profession, but hey, it pays ...
| for another three or so years).
| calvinmorrison wrote:
| SPAs and packaging your app inside a chrome container needs to
| die a hard death. Why is everything in 1 window. Why in 2025 can
| i not have multiple chat windows open?
| davidfiala wrote:
| 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
|
| The sad thing is that an article like this will get plenty of
| eyeballs due to comments like my own adding to the algo, but it
| should have never made it above the fold.
| CSSer wrote:
| 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.
| jenscow wrote:
| Page transitions aren't the reason we're creating single page web
| apps
| epolanski wrote:
| I'm fully convinced that it's time to kill SPAs on 99% of
| websites and that the community is too defensive on the topic.
| kavok wrote:
| It's because the people that built and maintain the SPAs were
| beat into submission with the "SSR" bad message. Now people
| want them to do SSR again.
| Cthulhu_ wrote:
| You're kind of already answering your own statement; websites
| should not be SPAs and vice-versa. Personally I think that an
| SPA should be something that lives behind a login.
| yoz-y wrote:
| For me the promise of SPAs has nothing to do with fluidity and
| all to do with having a separate data API and separate frontend
| (that can be native or web or both)
|
| That's why I don't like SSR mixed with client side rendering.
| Either do a website or an app.
| markbao wrote:
| 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.
| rossdavidh wrote:
| I once worked at a place where (for involved reasons not worth
| rehashing for this conversation) some of the backoffice, admin
| pages got rewritten in SPA fashion, after they had already been
| written in server-side fashion. It was an accidental experiment
| that showed me that the backend code did not decrease in size,
| whereas the frontend ballooned up to the same size as the backend
| (for fairly simple functionality even).
|
| Now, this means you will need approximately twice as many
| developers. On the plus side, more work gets done on the client-
| side, so you probably need fewer servers for your billion users,
| and you may save in servers (and sysadmins) more than it costs
| you in developers to handle approximately twice as much code.
|
| Except...99.9% of the shops using SPAs don't (and never will)
| have enough traffic for that tradeoff to make sense. The devs
| want (or at least wanted, back in the day) to go work at a
| company that did, so they wanted to use tools that would make
| sense if you're Facebook-sized. But, for the great majority of
| shops that made SPAs, there was no good reason to do so. This
| isn't Facebook's fault, but it is a reason why SPA's are annoying
| to so many people; they are almost always used in places that
| don't need them, and shouldn't be using them, in order to pad out
| a resume.
| Cthulhu_ wrote:
| Cost is one factor, but what about user experience? Rich front-
| ends that users spend a lot of time in can save them time and
| the company money. Case in point, I work at a company where one
| team works on the front-end for customer support employees.
| They have to run through certain legal processes from time to
| time, like sending customers emails with contracts and the
| like, or looking up various data from various services. Their
| efforts have helped save these agents a lot of time, and part
| of that is putting more and more into a rich, clear and
| convenient front-end.
|
| Of course, a lot of the effort also went to tying together
| various systems, replacing outdated ones, developing smarter
| and better chatbots and voice bots to guide users towards
| answers or self-service, etc.
| ConstrPlus8561 wrote:
| Any website that is an app is going to need SPA like features.
|
| Especially if they have some kind of AI integration feature.
| andrewstuart wrote:
| The view transitions API is a disaster.
|
| I spent weeks trying to get it to behave predictably and failed
| entirely.
|
| Don't use this api if you value your sanity it's the worst api
| I've used in a browser.
| game_the0ry wrote:
| CSS is uderrated and almost never even discussed in front end
| interviews. Its all javascript javascript javascript.
|
| Javascript is over-rated.
|
| CSS > JS
| Cthulhu_ wrote:
| I don't know if CSS is underrated, but it's definitely a
| speciality that a lot of software developers don't (want to)
| specialize in. It's like the front-end equivalent of SQL; so
| much is possible in SQL, but most logic is built in application
| code because SQL is scary.
| briandw wrote:
| Sounds like the major complaint here is trying to make the web
| into something it's not. It's something like 17 years since the
| iPhone app store. Web apps were not comparable to native apps
| then, and while they've made progress, web UX is still much
| poorer than a good native app. The Youtube mobile app has its
| problems but is so much better than the web interface.
|
| Native and web have different strengths, that's ok.
| SoylentOrange wrote:
| I'd like to add to the reasons for why you want an SPA over
| something with SSR:
|
| * You have a large number of users compared to your resources and
| you can't afford for your user base to always hit your server.
| Comparatively, deploying API-only apps is far cheaper when you're
| resource-starved (eg early stage startup).
|
| * You don't care about SEO, for example you're building internal
| tooling. You then don't need to care about hydration at all. Much
| simpler to separate concerns (again esp at the beginning).
|
| * Offline mode (eg PWA or reusable code in Electron) or cases
| where you want to be resilient to network failures. In the case
| that your app is dependent on the server for basic functionality
| like navigation, you can't support any type of offline mode.
| suralind wrote:
| Great post. Didn't know about these new features.
| yahoozoo wrote:
| lol who even used SPAs because of "smooth transitions"? I've
| never noticed anything resembling a transition on any React/Vue
| site
| ninetyninenine wrote:
| >The reason SPAs became the default wasn't because they were
| better. It was because, for a while, they were the only way to
| deliver something that felt fluid - something that didn't flash
| white between pages or jank the scroll position.
|
| This was NOT the reason why.
|
| SPAs are better because it offloads as much processing as
| possible to EDGE cpu's. The idle compute among all users
| aggregates to a massive amount so might as well use it and
| minimize html construction and routing on the server side.
| pawelduda wrote:
| When SPA framework in CSS?
| karaterobot wrote:
| A lot of people are responding with other technical
| considerations that may lead you to consider using an SPA
| pattern. But, note that the article is about responding to the
| stakeholder's request that it should 'feel like an app', and his
| point is that you can make it _feel_ like an app without being an
| SPA. Non-technical stakeholders rarely bring up deep technical
| considerations, they almost always talk about what something
| should feel like. So, I think his argument, while unlikely to
| work on anybody, is valid.
| dusted wrote:
| but is it ever going to be time to kill the CSS ?
___________________________________________________________________
(page generated 2025-07-25 23:00 UTC)