28 ms·

It's time for modern CSS to kill the SPA

• andix 1y ago
  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 1y ago
    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 1y ago
      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 1y ago
        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 1y ago
          Not reloading the document via HTTP while updating the content is the definition of a SPA.
          • strken 1y ago
            I would argue that the line between an SPA and not is blurred. Consider progressive enhancement; or, per the Slack example, pages with content that's updated dynamically but which rely on reloading a whole page for navigation. I would even argue that passing snippets of HTML around like e.g. Hotwire is still a middle ground.
      • epolanski 1y ago
        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.
    • nfw2 1y ago
      Those aren't the main parts of feeling like an app. Feeling like an app means taking an action doesn't load a new page. Feeling like an app means the concept of a page mostly goes away.
      • varenc 1y ago
        I guess that's my point. With instant loading thanks to preload and smooth view transitions, taking an action, while actually loading a new page, shouldn't feel like loading a new page. Should be indistinguishable from a SPA action. At least that's the theory. There might be other tells that degrade the experience, but not sure what they are?
• deleted 1y ago
  [deleted]
• ndr 1y ago
  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 1y ago
  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 1y ago
    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 1y ago
    You really don’t need the frameworks for web apps either.
    • andix 1y ago
      I guess you never worked on a complicated web app that was 100% jQuery, because web frameworks were not a thing yet.
      • ozim 1y ago
        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 1y ago
        I did, around 15 years ago. It was honestly not that bad.
        • ozim 1y ago
          How many people did you have on your team? What was employee turn over on the project? How long was the development?
• micromacrofoot 1y ago
  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 1y ago
  This article would benefit from an example page to show how these "feel".
  • emseetech 1y ago
    Here are a series of demos. They work in Chrome or Safari. https://view-transitions.chrome.dev/ https://view-transitions.chrome.dev/ Here's an older, more designed demo that only works in Chrome. https://live-transitions.pages.dev https://live-transitions.pages.dev
  • 9dev 1y ago
    Run this snippet from TFA in the console on GitHub: document.startViewTransition(() => { document.documentElement.dataset.colorMode = 'dark' // 'light' }); Then try to update the attribute manually instead, and compare the butter-smooth transition with view transitions vs. without.
• austin-cheney 1y ago
  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 1y ago
  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.
  • ec109685 1y ago
    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 1y ago
      Never thought about scroll position (tho SPA I’ve built recently I think does it ok). How do you solve it?
      • throwawaylaptop 1y ago
        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.
        • 1y ago
• LegionMammal978 1y ago
  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_ 1y ago
    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.
  • sfn42 1y ago
    This works for some websites, not all. And often it results in significant loading times, because you're loading tons of unnecessary data. In many cases it is much better to send requests more frequently, similarly to how a server side rendered website would behave. Instead of fetching 10,000 products, just fetch a page of products. Much faster. Have endpoints for filters and searches, also paginated. This can be fast if you do it right. Since you're only sending minimal amounts of data everything is fast. The server can handle lots of requests and clients don't need a powerful connection to have a good experience. Network requests themselves are not slow. Even a computer with a bad connection and long distance will probably have less than 500ms round trip. More like 50 to a few hundred at most. Anything beyond that is not the client, it's the server. If you make the backend slow then it'll be slow. If you make the request really large then the bad connection will struggle. It's also worth mentioning that I would much rather deliver a good service to most users than make everyone's experience worse just for the sake of allowing someone to load the page and continue using it offline. Most websites don't make much sense to use offline anyway. You need to send some requests, best approach is simply to make them fast and small.
• codingdave 1y ago
  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 1y ago
    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
    • deleted 1y ago
      [deleted]
    • kassner 1y ago
      ExtJS/Sencha was quite powerful and complete. I’ve built tons of SPAs with it in the late 00s.
      • gjtorikian 1y ago
        Wow, I remember Sencha! It’s been a while since I’d heard that name.
• emseetech 1y ago
  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 1y ago
    "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.
    • revskill 1y ago
      i hate it.
  • dickersnoodle 1y ago
    Less is more, usually.
• deleted 1y ago
  [deleted]
• nosefurhairdo 1y ago
  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 1y ago
    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.
    • nfw2 1y ago
      The article's title is it's time to kill SPAs
  • epolanski 1y ago
    No one said SPAs have no place, but 99% of websites out there don't need to be one.
    • zarzavat 1y ago
      SPA means single page app. For example, Google docs, Figma, Google calendar, etc. Apps that use web technologies instead of being native apps. A long time ago some webdevs started abusing the SPA concept to build simple websites. However that is not within the original meaning of the term SPA, because simple websites are not web apps. The author assumed that everyone would just understand that they are talking about SP"A"s and not SPAs, because for a certain subset of webdevs working on websites, the antonym of SPA is MPA, and it's normal to refer to your website as an "app". However for a certain other subset of webdevs, the antonym of SPA is simple website, and what the author is talking about are not SPAs at all.
• unsupp0rted 1y ago
  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 1y ago
    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 1y ago
  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 1y ago
    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).
• lunarcave 1y ago
  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 1y ago
  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 1y ago
  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 1y ago
  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 1y ago
    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.
  • racecar789 1y ago
    What does TFA stand for?
    • Contax 1y ago
      Among others (e.g.: "trans fatty acid"), in this particular case either "today's featured article" or "the f**ing article". I guess the latter.
• jenscow 1y ago
  Page transitions aren't the reason we're creating single page web apps
• epolanski 1y ago
  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 1y ago
    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_ 1y ago
    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.
  • MentallyRetired 1y ago
    I agree. SSR that hydrates to an SPA is a pain in the butt and not necessary most of the time. This is why I favor something like Astro for websites... I can drop in a react embed when I need to. It's just a right-tool-for-the-right-job situation imo.
    • woutr_be 1y ago
      I absolutely love Astro, and it's my default for new projects. And I honestly feel like it's the only framework using React/Vue for their intended purposes; which is as an interactive layer on top of your SSR UI.
• yoz-y 1y ago
  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.
  • mexicocitinluez 1y ago
    Not just for you, but for most people. The author of this article is making shit up to justify writing an article where they can show of their CSS skills. It's lame and dumb.
• markbao 1y ago
  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.
  • causal 1y ago
    3. APIs. If you already have a client facing API for your iOS and Android apps, and maybe one for developers, a SPA is just another app to plug into that backend.
  • pas 1y ago
    tiny correction Next is not an SPA (you can in theory write one using NextJS, but by default it's an MPA with aggressive prefetch)
  • gizzlon 1y ago
    > 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 Really? I just started using it, and it feels fast. Most SPA's are slow and/or buggy (in the "fails to mimic real browser behaviour" kind of way)
• vaenaes 1y ago
  [dead]
• rossdavidh 1y ago
  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_ 1y ago
    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.
  • sfn42 1y ago
    I completely agree that SPAs are overused, but I also disagree that they necessarily balloon in size. An SPA is supposed to be a view, it is only supposed to concern itself with view logic. People just overcomplicate them endlessly with unnecessary crap.
• ConstrPlus8561 1y ago
  Any website that is an app is going to need SPA like features. Especially if they have some kind of AI integration feature.
• andrewstuart 1y ago
  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.
  • wizzwizz4 1y ago
    What particular issues have you experienced?
    • andrewstuart 1y ago
      It’s extremely hard to use reliably. Anyone enthusing about this API hasn’t done much with it.
      • martrapp 1y ago
        What exactly hurt the reliability? Early on, I often ran into false starts because I did not pay enough attention to proper render blocking.
        • andrewstuart 1y ago
          It’s a ridiculous API that is way too complex. Try using it and you'll see. It takes huge amount of setup which it then seems to pay attention to or not, depending on his knows what factors. Go ahead try it for something beyond basic usage then tell me how reliable and easy it was.
          • martrapp 1y ago
            I tried something here: https://vtbag.dev https://vtbag.dev Took me a while to figure things out, but I'm happy to share what I learned. That's why I asked: I would be glad to help with concrete problems.
• game_the0ry 1y ago
  CSS is uderrated and almost never even discussed in front end interviews. Its all javascript javascript javascript. Javascript is over-rated. CSS > JS
  • Cthulhu_ 1y ago
    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.
    • nfw2 1y ago
      Most logic is built in application code because it makes it easy to structure, reason about, and test. Developers should be scared of code that is hard to test and reason about.
• briandw 1y ago
  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 1y ago
  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 1y ago
  Great post. Didn’t know about these new features.
• yahoozoo 1y ago
  lol who even used SPAs because of “smooth transitions”? I’ve never noticed anything resembling a transition on any React/Vue site
• ninetyninenine 1y ago
  >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 1y ago
  When SPA framework in CSS?
• karaterobot 1y ago
  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 1y ago
  but is it ever going to be time to kill the CSS ?
• gerdesj 1y ago
  "... someone says the words. A CMO. A digital lead. A brand manager. ... it’ll be an SPA." Why not spell out CMO and SPA and a civilian such as myself will not have to toddle off and dig out a search engine? If you are going to get all assertive and pissed off, please be inclusive too.
  • MentallyRetired 1y ago
    The problem is he's confidently wrong in believing Single Page Applications are about page transitions. Not at all. It's more about keeping state and an application-like experience. Like playing a song on spotify and changing to the search page and the song keeps playing... that type of thing.
    • gerdesj 1y ago
      Thank you for giving me a starting point to work with. FFS, I have a degree in Civ Eng but if I start wittering on about bridges and roads I will define abbreviations. Its common courtesy. With regards your analogy involving Spotify: I ripped all my CDs to FLAAC some years ago. The tapes and records took a little longer. No idea what a Spotify is. Well I do, I'm an IT consultant, but I don't actually care, I'm a 50 something IT consultant! I bought my music years ago and listen to it on my gear and from my gear alone. This SPA thing sounds like it is getting out of hand and it also sounds like there are tribal divisions being drawn up. IT does love a tribe! We even have multiple internal tribes: devops, webdev and so on. I'm nominally a PHB ...
• fleebee 1y ago
  It's worth noting that the Speculation Rules API and the View Transition API are not stable in Firefox and therefore aren't supported by all major browser.
  • fcpguru 1y ago
    yeah, if it's not in firefox it doesn't count. https://bugzilla.mozilla.org/show_bug.cgi?id=1823896 https://bugzilla.mozilla.org/show_bug.cgi?id=1823896 also mobile safari so basically all iphones.
    • bornfreddy 1y ago
      Basically it is supported just in Chromium & derivates then. Hard pass.
    • mattvr 1y ago
      It does appear to be supported by iOS Safari 18.2+, which is the majority of iOS users. https://caniuse.com/?search=view%20transitions https://caniuse.com/?search=view%20transitions
  • ethan_smith 1y ago
    This browser compatibility gap is a crucial point - without Firefox support, these APIs can't be considered production-ready for sites that need cross-browser consistency, undermining the article's central argument.
  • adamredwoods 1y ago
    For me, this is the key takeaway from the article, leveraging experimental browser extensions for preloading future pages. In other words, exactly what a properly thought-out SPA does.
• Hackbraten 1y ago
  The site feels so laggy on my mobile browser that I had to stop reading. Looks like CSS is not inherently performant.
• deleted 1y ago
  [deleted]
• davidbanham 1y ago
  I was completely unaware of view transitions and speculation rules. All of my products are server rendered for speed and simplicity. It’s amazing how snappy the interface is when your pages just load quickly because your software is performant. These seem like a great way to add an extra 10% of flavour.
• niutech 1y ago
  I agree. What is more, you can even use HTMZ instead of JS frameworks and Pure HTML Out-Of-Order Streaming using Declarative Web Components: https://github.com/niutech/phooos https://github.com/niutech/phooos
• jfvinueza 1y ago
  The thing about SPAs is that computation can be done in the customer's machine. That usually makes it worse for everyone, both devs and users (although sometimes it doesn't). I personally believe that we can create better experiences routing more pages with more imagination, but at times this industry is quite vocal on what "user expectations" are.
• andrewaylett 1y ago
  What counts as "SPA" and what's an "MPA"? I've got a NextJS site (my personal website, you can probably find it given you know my last name and that I'm in the UK) that renders pretty much everything server-side. Technically it's still an SPA because if you turn on Javascript it'll load RSC and do client-side navigation. If you turn off Javascript? Pages with client-only components (like the 100% client-rendered QR code generator) will show their fallback, everything else will load and render perfectly -- if a little less quickly -- than if you let Next do its thing. It's all rendered into the HTML, and it's actually more effort to not render components on the server. Progressive enhancement for the win!
  • skydhash 1y ago
    > What counts as "SPA" and what's an "MPA"? By how many times the Window's load event fire for your app.
• etchalon 1y ago
  If you think SPA's became the dominated architecture because of page-to-page transitions, I'm not sure how to have a productive conversation with you.
• onehair 1y ago
  Props for teaching me about View Transition API. Absolute disagree with the way you're arguing though.
• 867-5309 1y ago
  Single-page Application
• rezmason 1y ago
  The author looks like Edward Norton. "I am Jack's native declarative transition."
• jmull 1y ago
  The author is living in some crazy land bubble... or I am. I can't relate to the situations, problems, or solutions this article seems to just take for granted.
• user3939382 1y ago
  If full page requests have an ability to persist complex state, cache to the point of imperceptibility parts of the page that aren’t changing and never blink, I guess?
• jraines 1y ago
  I wonder if my slop radar is oversensitive to em dashes and the construction: “it’s not just about foo, it’s about bar” because this post seems human written but the indicators are flashing
  • Anamon 1y ago
    There are also many non sequiturs. The sentences only read fine if you don't think about what the author might be trying to say. I also think that this reads like the "author" was an LLM and, therefore, isn't trying to say anything. À propos of nothing – I'm human and I like using special characters, including en dashes. ;)
• wyuenho 1y ago
  I swear if I see another "SEO" guy or some rando web dev who joined the workforce after Covid complaining about SPAs by misrepresenting it, I'm gonna explode. As someone who's been developing web apps since the 2000s, let me tell you the origin of SPA has few things to do with the "false promise of SPAs" he listed, but largely due to companies in the late 2000/early 2010s wanting to go "mobile first". This usually meant they still had a desktop second somewhere, which implied they were architecting the entire system to completely separate the frontends and the backend. Before, what web devs meant by frontend was essentially server-side rendered HTML templates with perhaps a little bit of jQuery running on the client-side. Now, since mobile and desktop web apps are to share some business logic and the database somehow, people had to rediscover REST by reading Roy Fielding's Phd dissertation that inspired the original HTTP. This meant now every company was moving to service-oriented architecture and started exposing their backend APIs onto the open internet so their mobile apps and SPAs running in the browser can share the same APIs. This was a cost saving measure. This period also coincided with the steady decline of full-stack webapp frameworks like Ruby on Rails and Django because for a couple of years, these frameworks had no good ways to support an API only applications. Django hadn't even reached 1.0 back then. This was a time when NodeJS was really starting to pick up momentum. Once people had started being more comfortable with JS on the server-side, lots of people suddenly realized they could push a lot of business logic to increasing powerful desktop browsers and phones, application hosts people now call "edge devices". This is the true impetus of SPA. How is CSS going to kill this need?
• incomplete 1y ago
  i see "SPA" and my mind immediately reads that as "special purpose account" lol.
• fnord77 1y ago
  there's lots of SPAs that look like normal web pages. Twitter for instance.
• bpev 1y ago
  Most of my personal app projects are SPAs, because it’s easy to just pop some static files in my static file server and serve a whole app with routing and functionality without having any server logic. Way simpler to maintain, since I can just sync my ‘apps’ dir and all my mini-projects are deployed.
  • wordofx 1y ago
    Can do all that without a SPA.
    • bpev 1y ago
      Not really... like sure if you want a static site, but I'm talking about static apps. Like if you want to handle /id/$id routes with data based on user-generated content saved in localStorage... you'll have to handle routing somewhere. Basically, what I'm saying is that if you have an stateful app that doesn't require server state, I think SPA+PWA is pretty ideal.
• diegof79 1y ago
  Ok, now try to implement a tree component in an MPA. But not a crappy tree component that only opens one branch at a time, like in a page from 1998. A tree component that remembers the open/close state of each branch. Before the SPA, these were common issues. That’s why there were a gazillion Java server pages frameworks to solve them. You also have frameworks that tried to encode the UI state in some way. My favorite was Seaside, which used continuations to store the UI state. The following article should probably be titled “It’s time for modern bloggers to kill the clickbait titles” and discuss the trade-offs of each architectural decision more balancedly.
• dkarl 1y ago
  I think this article is unfair to SPAs. SPAs are a lot more effort, but they are better. For a long time they have been the only way to "make it feel like an app." (I think the author says "make it feel like an app" because they know we all resent app fatigue, all the apps we have to download that should just be web sites, but I think we also all know that when something really is an application, it's rare for a "web app" to match the experience of a local native application, and an SPA is the only way to make a sincere attempt.) The comparison of bloated SPAs with lean web sites is bogus. If someone takes the effort to make their web site lean, they'd do the same with an SPA. If someone makes a slow, bloated SPA with megabytes of Javascript, they'd make a slow, bloated web site with megabytes of Javascript. I think we've all seen enough of the web to know this is true. I click on articles like these because I've seen the effort that goes into a good SPA, and I'm interested in anything that would allow people to deliver an equivalent experience with less effort. All I see here is a tiny bit of cosmetic polish. Polish is appreciated, but this doesn't seem like something that would tip the balance between building an SPA or not. Am I missing something?
  • adamtaylor_13 1y ago
    “But they are better” By what measure?
    • nfw2 1y ago
      Performance, developer experience, user experience
      • donatj 1y ago
        I'm sorry but what!? Have you talked to your users? The ones that actually are forced to use your app day in and out? They want functional back buttons, they want to be able to open any action in a new tab. No one who actually uses your product would prefer an SPA once the flash wears off. Let me tell you as a developer who has been on both sides of things, developing server rendered pages and not having to worry about the server disagreeing with the client is the ultimate developer experience. Build a competent app that can serve full pages in .1 seconds and no one will care that your site isn't an SPA. They want a fast reliable site.
• calrain 1y ago
  I like how client side state is managed in a SPA more than an MPA
• martinald 1y ago
  Everyone is completely missing the point of this article, which I find amusing and terrifying in equal measure. He is _not_ talking about a SaaS dashboard SPA. He's talking about marketing sites and other content heavy stuff like blogs, landing pages, etc. It mentions this in many places if you go past the headline. He is completely correct. SPAs should not be used for marketing sites full stop. Perhaps there are some edge cases where it may make sense (though I cannot think of any) but in general, if you are building anything that resembles a blog or landing page with nextjs et al you have done it wrong, close the code editor and start again. I'll give you a pass if you are developing an MVP of something and you need something up very quickly, but if you have any commercial traffic you will thank my later. I have done a lot of audit work for this kind of stuff. Things I've seen: 10MB+ of React/JS libs to load a simple blog page Putting images in the bundle, base64d. So badly that the page crashes OOM on many devices. And my favourite of all time - shipping 120MB (!) of JSON down for a catalog. It literally loaded _the entire database_ to the front end to show _one_ product. It wasn't even an ecommerce site; it was literally a brochure of products you could browse for.
  • robertoandred 1y ago
    You of course don’t need 10MB of JS for a React blog or 120MB for an e-commerce site. You’re not mad at SPAs, you’re mad at bad developers.
    • martinald 1y ago
      But even the most well optimized nextjs/react 'blog' or ecom site performs and order of magnitude worse than a SSR version, simply because you have to bring in runtime stuff? I'm giving extreme examples; but I've seen very very able development teams totally shoot themselves in the foot with this.
      • robertoandred 1y ago
        Next/React sites can be SSRd just fine. If a db call is slow it's going to be just as slow for a PHP page as for a React page.
• krish860870707 1y ago
  [dead]
• sidcool 1y ago
  Good article. But could have shown some examples.
• bstar77 1y ago
  This guys is really on a mission. Is there really a war against SPAs? Well designed SPAs can be incredible.
• throwaway984393 1y ago
  [dead]
• rustystump 1y ago
  Once again people totally miss the point of SPA. What does SPA stand for? Hint, there is no website in there. Id argue all the grousing of spa is because people made websites as apps when they should have been websites instead. Btw view transitions are pretty slick and require zero js to get snazzy transitions. Edit: there are some significant limitations with view transitions around performance and a few other gochas I should mention when they are used with pure css. I still love em tho.
• frollogaston 1y ago
  CSS is a mess for anything besides basic static layout. You can force it to do fancy things, but it's hacky and gives you code that doesn't really say what it does. You can do scss, sass, etc, but still eh.
  • senfiaj 1y ago
    Yeah, like this https://lyra.horse/fun/tic-tac-nohtml/ https://lyra.horse/fun/tic-tac-nohtml/ tic tac toe without JS and HTML, only a <style> tag. I mean it's incredible, but you know what will happen to you if you write a production code like this.
• oc1 1y ago
  As others have noted this guy isn't qualified to write about this topic as he doesn't understand the difference between MPA and SPA.
• ken47 1y ago
  The main premise of this article is that SPA frameworks are primarily about transitions. This is yet another passionate argument built on a false foundation.
• austin-cheney 1y ago
  [dead]
• deleted 1y ago
  [deleted]
• positron26 1y ago
  It's time for... No, you found some tradeoffs and decided that the drawbacks are worse than the advantages. If industry disagrees, they tend to have their reasons, but as we love being tortured artists and really feeling our individualism, offbeat hot takes are always in demand. That's all I see in quite a few HN titles ;D
• 40four 1y ago
  This article is getting a lot of pushback from the SPA champions, deservedly so, but it makes some good points to. I can’t be the only one, but I myself am getting very tired of the amount of websites where I have to sit and look at a skeleton loading for way too many seconds, then the data loads and it looks nothing like the skeleton. There is an over abundance of really crappy SPAs out there. Sorry not sorry
  • pyman 1y ago
    I thought about your comment, and IMO the reason some (or most) SPAs are badly built comes down to the inexperience of developers and hiring managers. They don't know much about performance, they don't measure it, they don't handle errors properly, they ignore edge cases, and some are learning as they go. Bottom line: they build the SPA, but leave behind a terrible UX and tech debt the size of Mount Everest.
    • maccard 1y ago
      They would have done the same thing with a MPA too though.
      • pyman 1y ago
        Yeah, of course. But I was thinking more from a user experience point of view. MPAs usually render pages server-side, which cuts down on frontend dependencies and expertise. That's why companies used to hire experienced engineers for the backend, and CSS/jQuery devs for the frontend. It used to make sense, but not anymore. These days, apps built with MACH architecture rely heavily on client-side code. This means companies are supposed to hire experienced engineers to architect apps on the client side but instead, they end up hiring JS devs with little to no software architecture experience. For example, I've seen SPAs that don't log any error messages from the app, which means developers have no idea what problems users are running into.
  • tossandthrow 1y ago
    This is not intrinsic to SPAs. You'd likely have to wait an equal amount of time for a non SPA - just without any skeleton
• sibeliuss 1y ago
  SPAs are _applications_ folks. Just like app-apps are made -- spas are apps for the browser. SPAs in themselves are not complicated. State in an app is complicated. This is such a tired misunderstanding.
• nektro 1y ago
  might wanna consider redesigning your site, it looks like AI spam
  • rhet0rica 1y ago
    Yeah, it's really missing the charm you'd expect from a AI-free spam site. Maybe more flashing text?
• 65 1y ago
  The SPA test should be: can you keep a picture-in-picture video element playing while navigating between pages? If the vanilla web can't do this easily, then it's not a good solution to your need for a SPA.
• deleted 1y ago
  [deleted]
• d--b 1y ago
  Yeah… Let’s see how less terrible those MPAs with CSS tricks are.
• np1810 1y ago
  On one hand, SPAs took off and became massively popular. On the other, I’m still curious why PWAs—especially the kind with service-worker-powered offline access—never really did. I don't like SPAs only if I find them bloated and with a messed up browser history that back button moves you out of the website. Imagine an e-commerce site that lets you review your order history and product pages offline (even if a bit outdated). That kind of experience feels genuinely useful—much more so than the "you're offline, here’s a cute dog (I love the pictures though)" fallback most sites provide. Over the weekend, I experimented with service workers for the first time (assisted by Vibe coding). My initial impression was honestly a bit magical—“this website works offline, unlike most mobile apps these days that are just WebView-wrapped SPAs and crash offline.” [1] That said, debugging was rough. Vibe coding output had subtle issues I found hard to untangle as a newcomer, cache saved v/s cache matching was being done incorrectly in the code, which LLM wasn't able to point out (cors/non-cors requests had issue).And Chrome’s DevTools made debugging manageable, but Firefox’s service worker support felt clunky in comparison (personal take). Curious if others feel the same—are PWAs underused because of DX hurdles, lack of awareness, or just industry momentum around SPAs? [1]: https://ball-sort-game.vercel.app/ https://ball-sort-game.vercel.app/
  • gabesullice 1y ago
    Offline is good for things like your ball sort game or a calculator. But the developers of that sort of thing want to make money, so they sell apps in the app store. Offline order history is only a marginal improvement on the e-commerce experience from a customer and business perspective, so it's more appealing to us engineers who appreciate it as a feat of engineering prowess. In other words, offline isn't PWAs killer feature. Besides, native apps can do it too. PWA's killer features are circumventing the app store and the app store tax and not maintaining two codebases for Android and iOS. Another Hacker News client would be a good example of a good PWA that you might install to your phone. It could have niceties like "save for later" or special styles applied to your favorite commenters. Offline support would be useful too, of course but not the main reason to develop a PWA. Uncensored, paid content is another significant use case.
    • 1y ago
• softwreoutthere 1y ago
  "It is a couple MB payload, so its bad" never really reasonated with me. YouTube serves hundreds of MB payloads to serve information. Even a bloated SPA is tiny in comparison. Although, I think YouTube is also an SPA. Some websites serve hundred MB payloads to show a hero video. Why is JS optimization the great evil when there is often so much more waste in media or design choices?
• gethly 1y ago
  I strongly disagree with this. SPA has its place and a very important one. It is not just about replacing JS animations with CSS animations. Of course it depends on the use case - SPA makes little sense in many cases and a lot of sense in few. But it still has it's stable place. From my own point of view and experience, SPA makes the most sense when you do not want to bundle backend and frontend together in your server code. Having a separate FE and BE with clearly set API(json) is very important in many many many cases and it allows you to use the same BE for different FE, like desktop website, mobile website, desktop client(electron), mobile application... trying to do this on the server would be hell. Also worth mentioning is that if you want to make changes in your FE, you have to bring down you BE in order to deploy them, whereas if you have BE and FE separated, you can deploy the FE without any downtime. There is a lot more that could be said but the main point is that moving data rendering into FE and letting BE just serve raw data is the way to go in many situations. We have been moving computation between FE and BE for decades now, but I think the tech is now sufficient to not force us to pick one over the other but chose what works best. Personally, I think that rendering the UI on BE is archaic and should be handled on the client via some bundled thin client code, ala SPA. So I will always prefer client-rendering over server-rendering, no matter the setup. PS: You might be interested in https://data-star.dev/ https://data-star.dev/ which came out of dissatistfaction with HTMX and I think will be the way to go about bridging FE and BE in the future.
• aatd86 1y ago
  Some people download mobile apps everyday but are afraid all of a sudden of SPAs which is a similar development model. Doesn't make sense.
• nromiun 1y ago
  Lots of pushback here in the comments. But I can't think of the last time I enjoyed using a SPA website over a multi-page one. The initial loading feels delayed, the page scrolling feels unnatural and jarring (completely opposite of how a native app feels). Also, one of my banks recently changed their old website to a new SPA one. And it is now completely useless. It can't load information in time, so most of the forms are empty. You can't even go back because it is a SPA. So I can only log out, log in and try again. Kind of scary when you are handling a lot of money. And it is not just one website. As I said I can't recall ever using a good SPA website. So yeah, I can't wait until they are all gone.
  • kertoip_1 1y ago
    Yeah, the worst thing is when parts of the same application are under the hood different SPAs. First example that comes to my mind: web version of ProtonMail. Going to settings feels like loading a completely separate website. Or OVH dashboard.
  • tossandthrow 1y ago
    > But I can't think of the last time I enjoyed using a SPA website over a multi-page one. You likely don't even notice that most of what you browse are SPAs. The reason why there is pushback is because the article is straight up misinformation.
    • nromiun 1y ago
      Actually the static address bar and the refresh button behavior makes it obvious.
      • tossandthrow 1y ago
        What? Most SPAs use full on routing. You can not distinguish refresh and address bar behavior between a SPA and static pages. Furthermore, SPAs integrates perfectly with the browsers navigation stack. Where does this bs come from?
• jpc0 1y ago
  I don’t want to write an article but I think when SPAs are called for they are the least worst option. Usually I want to ship an app to customers, but for that I need an app the targets Apple platforms, hopefully I can built it to target iOS, iPadOS and MacOS but maybe those are three different apps. I need an app that targets Android. I also need an app that targets Windows, and I need a linux app. Then I need to distribute all those apps, so I need to get onto the AppStore for MacOS, the play store for linux, and whatever Huawei/other Chinese manufacturers use, and whatever amazon uses, and probably have an “official” APK available for stuff like fdroid. I need a windows installer, maybe a portable package for windows, and get onto MSStore (which will then cover winget). I need to pick some collection of linux distros to target, usually targeting having a deb release and rpm can be good enough. And you can build an “installer” yourself if you are so inclined. Or I could just ship an SPA, I had to build out the same servers if the data was not local anyway.
• eric-burel 1y ago
  TL;DR: article means traditional websites with server navigation (now dubbed MPAs, multi page applications) have evolved positively with better handling of page transitions. But they choose to frame this idea by trashing SPA, while both MPA and SPA have a role to play.
• Pavilion2095 1y ago
  > 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. So they were better.
• aswerty 1y ago
  I'm not a fan of the SPA, or at least in practice, but there is something very attractive about going with a solution that everybody knows. At work we are building a new "website like" frontend and it is a SPA (that internally operates as a MPA) built with React. The main reasons are we: know this setup well and know when hiring we will find people who know this setup as well. Beyond that, it will allow us to build out more application like features in the future if needed. This approach has been popular in the industry for over 10 years now. Whereas most of the current discussion and tech on the frontend feels like churn and betting on the next thing. A lot of people just want tools that are mature and can get the job done regardless of them being the best tool under specific criteria.
• tossandthrow 1y ago
  This is the biggest mess of an article I have read for a long while. The concerns of SPAs and CSS are completely orthogonal.
• vasco 1y ago
  It's incredible to write an article about UX with a main argument of "this way is as good as that way" without visual examples to prove they actually behave the same.
  • bigtones 1y ago
    Right, I would like to see some examples of what he is talking about considering his tone of voice - he is literally telliong people to change their ways and use modern CSS and the entire article is devoid of such css.
• Einenlum 1y ago
  Honestly, I never used an SPA because of transitions. I recently decided to use one because of the persistent state. Not sure how CSS solves this.
• victorbjorklund 1y ago
  I see some people claim that client-side routing isnt the strongest argument for SPA:s. And that is probably true from a technical point of view. However, lots of times users/clients want that even if they dont care about the rest (which is why I love how easy HTMX and Astro make it to add client side routing on top of a normal MPA).
  • maccard 1y ago
    Astro is a breath of fresh air in this space really.
• mrb 1y ago
  SPA = single page app
• DrStartup 1y ago
  is the author secretly the ceo of htmx?
• curtisblaine 1y ago
  Not only SPAs are here to stay, but they're eating up native app on the desktop (with Electron et al., it's much easier to hire TS devs and write your app once rather than have different native codebases for Windows, Macos and Linux). Now, I understand the argument that simple article-based websites shouldn't necessarily be SPAs. Page transitions are perfectly doable in pure HTML and CSS. But if you have less then trivial local state and complex + specific components, forcing the MPA pattern will only complicate your codebase.
• wlll 1y ago
  It's time for sending HTML rendered on server with CSS, and JS for enhancement only to kill the SPA. I'm not talking about this from a technical standpoint, though there are many reasons that in most cases this is the best technological fit. I'm talking about this from the position of "what I want to use". I'm sick of loading and navigting overly JS heavy, overly styled, fragile "apps". When I encounter a "proper" website that loads fast, and I can understand easily it's like a breath of fresh air.
• withakay 1y ago
  If this wasn’t written by Claude then Claude was trained on the authors posts!
• rorylaitila 1y ago
  CSS, URLs, links, forms, POST-Redirect-GET, page reloads. Efficient and user friendly on the modern web. HTML & browsers have smoothed out a lot of rough edges.
• nsonha 1y ago
  what a nonsensical title, clearly written by people that only program skins around applications instead of applications themselves. CSS and SPA do not even solve the same problem. I'm sure there exist (foolish) efforts to make CSS somehow able to do some UI logic, but that is never a good idea. CSS is a poorly made/overly complex spec that deserves to die. It's too late to make that argument unfortunately, but to want even more of CSS in the modern web stack is kinda lunatic.
• mexicocitinluez 1y ago
  > Native CSS transitions have quietly killed the strongest argument for client-side routing What? This guy wanted to show off how much he knew about CSS and decided the only way to do it was completely make stuff up about a hot-button topic in webdev.
• adamddev1 1y ago
  SPAs are good for making offline-available apps/sites. Not everyone has (or wants to have) an internet connection all the time.
• Alifatisk 1y ago
  Speculation rules works the same as instant.page, by prefetching the url onhover. Right?
• larodi 1y ago
  it makes more sense than ever to deploy a semantically correct page with clearly distinguished templatnig, styling, animation logic and most importantly - data semantics. so that the robots and LLMs can slurp it without clicking too much. all the styling can follow in a very standards-compliant manner.
• insane_dreamer 1y ago
  SPA was primarily about reducing ajax-type calls to make the page more responsive, not CSS-type transitions. (I do agree that SPA is waaaaaay overused and most of them would work just as well with server side logic with less complexity.)
• Bridged7756 1y ago
  "It’s faster, simpler, and better for everyone." For who? In the modern day and age most devices can handle some JavaScript just fine. The DX provided by front end frameworks/libs is just unrivaled. Vanilla JS/jQuery work fine for small stuff, things quickly get out of hand in complex projects, when you have to bake in things like UX, validations, and have to program around the limitations of HTML. I'm confused as to why make such a claim as "Don't do SPAs for websites" and then throw in a dumb broad statement like "Just do vanilla". Yes, you can use CSS and achieve a lot of complex functionality. Yes you can use the existing HTML tags for a lot of things. Is it more maintainable than just using React? No. You can't live in a silo. Yes, if plain HTML works for your website, why bother with anything else? Just do forms for any submit, input validation, there you go. But for a company competitive in the industry, particularly B2C SaaS, UI/UX does matter. And lagging behind, more than a trend, means customer perception. We tend to be biased in our takes as tech-literate people (I do), but the average person gets lost if a button isn't emphasized enough.
  • mantas 1y ago
    A lot of website-in-spa break basic web stuff that simply works in old school HTML. It’s possible to do all that stuff correctly in react, but vast majority of people working on those simple websites seem to not give a damn. Vast majority of information/portfolio websites have best UI/UX with classic HTML with some JavaScript sprinkled on top where it matters. Nothing says competitive-in-the-industry like contacts page that takes ages to load.
  • sirsinsalot 1y ago
    > The DX provided by front end frameworks/libs is just unrivaled How? I spent 6 months exploring React, Vue, Node, Next,... The DX for all of them sucks. The documentation sucks. Everything is wrappers of wrappers of npm scripts of wrappers of bootstrappers of boilerplate builders of... Seriously. The worst.
    • Bridged7756 1y ago
      Sucks compared to what? Vite (build tool) + React is all you need, and a command line away from setting up React with TypeScript. If you don't like how "heavy" it is, you can use Preact. Similarly, for a Node (express) project, all you gotta do is `npm i express`, with additional setup if you want TS and other dev. niceties. Or just use a batteries included framework like Nest/Adonis and skip all that. It's not that complicated, the frontend targets the browsers, so you have to transpile if you want to ensure compatibility, prevent theft, reduce the size, or not, and you could just wing it using the plain source code. Again, it's the best for writing APPS. For an app, with complex navigation, features, UI states, it find it asinine that your biggest complains are about the packages.
• moribvndvs 1y ago
  > Native CSS transitions have quietly killed the strongest argument for client-side routing Huh? We didn’t build my company’s product as a SPA because of transitions. We did so because it is a shared codebase with native and because it has an offline mode.
• franey 1y ago
  For anyone looking to use this, I recommend using this CSS before the closing body tag. It disables the fade effect for visitors who prefer reduced motion, and the old page fades out while the new one fades in. (I've got an optional rule that keeps my header in place while the rest of the content fades out/in) @media (prefers-reduced-motion: no-preference) { body > header { view-transition-name: header; } @view-transition { navigation: auto; } ::view-transition-old(root) { animation: fade-out 0.3s ease; } ::view-transition-new(root) { animation: fade-in 0.3s ease; } @keyframes fade-in { from { opacity: 0; } to { opacity: 1; } } @keyframes fade-out { from { opacity: 1; } to { opacity: 0; } } }
• VikRubenfeld 1y ago
  Plus which, the author says that the next page will be conveniently pre-loaded when the user hovers over the link. Plenty of time there's ~0 hover time, especially for experienced users. So the user is still going to be looking at a spinner while the full page (which could be pretty beefy) is loaded in from the server.
• odyssey7 1y ago
  I looked up the compatibility table: https://caniuse.com/cross-document-view-transitions https://caniuse.com/cross-document-view-transitions Safari has supported this on both desktop and iOS since last year. But I had to look, because the article makes it sound like Chrome and its family are the only browsers that are modern enough for the feature. Safari uses WebKit, not Chromium. "Modern browsers – specifically Chromium-based ones like Chrome and Edge – now support native, declarative page transitions. With the View Transitions API"
• kristopolous 1y ago
  Ie4 had these. It was pretty cool. I forget how they implemented it. Maybe active x?
• palmfacehn 1y ago
  It is possible to deliver a lite, PWA/SPA with vanilla JS and no loading spinners. Users can install it on their mobile device. I've done as much with blockchain dApp front ends. It isn't necessary to hijack the address bar or abuse the back button to achieve this. Modal dialogs, collapsible elements, tabs and simple anchor elements are enough. Yes, you can allow in-app back buttons to return to the previous modal's state, although that might suggest that the UI pattern should be simplified. "State management" from a framework seems ridiculous. Developers should be able to handle their application's state with JSON objects representing reasonable abstractions of concerns. Typically, this would be similar to the data you query from the web. Therefore, upon launch, you can populate your document using <template> elements from cached data in localStorage or some of the newer options. When network connectivity is available, you can update the state using the same functions. Perhaps this isn't something you would trust your large enterprisey team to do competently, but for a solo developer with a distaste for React and heavy frameworks, it seems like the obvious approach. Interested to hear how others building sans frontend frameworks. If you love React and loading spinners by all means feel free to ignore this. To each their own.
• Surac 1y ago
  But designers will always find a way to make our live miserably. They are told to never accept same behavior and always press users to there way of navigation and thinking. The bullshit they call design is there way of expression
• ptsd_dalmatian 1y ago
  is this a growth hack article trying to get attention on SPA hate on HN?
• swyx 1y ago
  i think this is good for websites but my current struggle with Astro is the long build times for a blog with many many pages. current build time is 10 minutes and it does not spark joy.
• fmajid 1y ago
  To be frank, I tried the cross-page fade transition on my Hugo static site, hosted on AWS ClousFront, and I couldn't see the difference. It's probably only relevant if your site is bloated to begin with.