[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 : 687 points
Date : 2025-07-25 21:08 UTC (1 days 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.
| nfw2 wrote:
| 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 wrote:
| 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?
| 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.
| ozim wrote:
| How many people did you have on your team? What was
| employee turn over on the project? How long was the
| development?
| 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.
| cweagans wrote:
| What if I told you that you didn't even really need
| _javascript_ for most things - even more involved web
| apps. HTML and CSS is plenty for many things.
| 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
| 9dev wrote:
| 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 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.
| naet wrote:
| HTMX does the opposite of this, it requires many more round
| trips to the server instead of using client side JS to do
| work.
| throwaway7783 wrote:
| I meant for the SPA-like experience.
| aquariusDue wrote:
| I find Datastar to be a better replacement for HTMX,
| especially now that it can also do plain requests instead
| of Server-Sent Events. You also don't need Alpine.js
| combined with HTMX anymore.
| chuckadams wrote:
| First time I've heard of Datastar. Not sure what to make
| of it yet, but the video on data-star.dev is certainly
| one of the cutest things I've seen all year!
| goatlover wrote:
| Does it matter how many round trips are made to the server
| if they're fast enough to be seamless?
| princevegeta89 wrote:
| Many more round trips to the server is okay - it is the
| server after all and it is easy to scale it.
| recursivedoubts wrote:
| htmx does not require many more round trips to the server,
| front end scripting is perfectly compatible with htmx:
|
| https://hypermedia.systems/client-side-scripting/
|
| in addition to native html features like <details>, etc.
|
| htmx can often _decrease_ the number of trips to a server
| because in the hypermedia model you are encouraged to
| deliver all the content for a UI in one fell swoop, rather
| than in a series of chatty JSON requests that may be made
| due to opaque reactive hooks.
| 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.
| thaumasiotes wrote:
| > 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.
|
| Sure, lightweight, quick-loading pages _existed_ , but
| sometimes you want to see a picture.
| nine_k wrote:
| Google appeared in 1998. It was very noticeable how fast
| it loaded compared to competitors like AltaVista and
| Yahoo. None of them featured large photos.
|
| This was visible not only on a 33600 phone connection at
| home, but also on a megabit connection at work, because,
| shockingly, how fast your backend is also plays a major
| role.
| Izkata wrote:
| Speaking of speed, don't forget when gmail and google
| maps first came out: With the data copied locally they
| could separate the UI from server requests for a lot of
| interactions so a lot of the UI was actually instant and
| you could keep doing things while the requests were
| handled in the background. This seems to have been missed
| by a lot of modern stuff that doesn't bother figuring out
| if this is even possible and opts to show a loading
| spinner instead.
| 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.
| paulryanrogers wrote:
| > Gmail takes 3s to load
|
| On a 2008 device, in 2025? On a mobile connection?
| xyzsparetimexyz wrote:
| How is HN not an app? All the content is user generated.
| Everything is interactive. What's the difference?
| dzhiurgis wrote:
| Most of the time spent is content consumption (viewing
| html documents), rather interaction (which is only 2
| simple actions).
| xyzsparetimexyz wrote:
| I suppose that's valid. Feels fairly arbitrary though
| da_chicken wrote:
| Navigating to a thread isn't much different than
| navigating to a store.
|
| Upvoting isn't much different than adding to the cart.
|
| Payment isn't much different than adding a comment.
|
| I think the interaction levels are incredibly similar.
| The primary difference is the amount of images displayed,
| but that really isn't a significant aspect of web design
| or Internet traffic in 2025.
| dzhiurgis wrote:
| When you posit like that makes me think doordash
| shouldn't be an app at first place.
| layer8 wrote:
| Document-centric, form-driven websites aren't
| traditionally called apps. The Wikipedia website isn't an
| app. Web forums aren't apps. "App" implies that essential
| parts of the interaction logic are driven by client-side
| code (JS, not HTML) that couldn't similarly be
| implemented by HTML forms.
| chuckadams wrote:
| Sure Wikipedia is an app, long as you think of static
| websites as a subset of web apps. One might say that
| makes the term meaningless, I say it's a deliberately
| vague term because people don't want or need to get
| cornered by fine distinctions. Otherwise it's endless
| quibbling over whether things like search do or do not
| count toward a site being a "real" app.
| MYEUHD wrote:
| That's the discussion being had.
|
| HN would've been considered an app if it was built as SPA
| Aurornis wrote:
| > But I go to DoorDash on the same device, and it takes 30s
| to load up a list of 50 items.
|
| > And 2.5 minutes is waiting for it to render enough to give
| me the interface.
|
| I have a very old MacBook Air (one of the painfully slow
| ones) that I use for development reference for what a slow
| machine looks like.
|
| I just tried clicking around DoorDash and didn't see anything
| nearly this bad. Not even close.
|
| Every time there's a Hacker News thread about how slow
| websites are, there are dozens of comments like this claiming
| extremely large latency numbers. I can't tell how much of it
| is exaggeration for effect, or if some people have
| configurations with weird quirks that make them abnormally
| slow.
|
| I suspect it's a lot of this:
|
| > on my 2008 laptop with 4 GB of RAM.
|
| Sorry, but I don't think it makes sense for companies to
| optimize their websites for computers that are nearly two
| decades old and don't even have enough RAM to run a modern
| operating system.
|
| The intersection between people who spend money on a
| expensive luxury service like food delivery to their door and
| people who won't spend the cost of a couple DoorDash
| deliveries to upgrade from a 2008 laptop to a 2018 laptop in
| 2025 is negligibly small.
| 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.
| PaulHoule wrote:
| I've done it like that. It's not a lot of code.
| cyco130 wrote:
| I write some of my thoughts on this sone years ago. The
| library described at the end is now fairly out of date but
| the ideas and suggestions are still good, I think.
|
| https://dev.to/cyco130/how-to-get-client-side-navigation-
| rig...
| fleebee wrote:
| Depends on what you're using for routing.
|
| In Tanstack Router it's a boolean you set when creating the
| router. The documentation nicely lays out what's being done
| under the hood, and it's quite a bit.[1] I wouldn't try
| that at home.
|
| In React Router you just chuck a <ScrollRestoration />
| somewhere in your DOM.[2]
|
| [1]: https://tanstack.com/router/v1/docs/framework/react/gu
| ide/sc...
|
| [2]: https://reactrouter.com/6.30.1/components/scroll-
| restoration
| zeroq wrote:
| It's funny you've mentioned that.
|
| It reminded me of the time when I joined Wikia (now Fandom)
| back in, I think it was 2006. One of the first things that
| landed on my desk was (I can't recall the context)
| deeplinking.
|
| And I remember being completely flabergasted, as I came
| Flash/games background, and for us that problem was
| completely solved for at least 4 years at the time (asual
| swfaddress package). I felt kind of stupid having to
| introduce that concept to much more senior engineers that I
| was at the time.
| 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...
| crazygringo wrote:
| Generally speaking, companies don't _want_ you to download
| their entire catalog. They don 't want competitors to be able
| to analyze it easily like that.
|
| And if a store is selling books, it might have hundreds of
| thousands of them. No, it's not a good experience to transfer
| all that to the client, with all the bandwidth and memory usage
| that entails.
| zeroq wrote:
| That's really weak argument.
|
| If it's one their website the competitors can write a simple
| crawler and create that catalog.
|
| And you don't have to send every single field you have in
| your database. Once the user selects a category you can send
| a metadata that enable the client to scaffold the UI. Then
| you cache the rest while user interacts with the site.
|
| Barnes and Nobles - according to their FAQ - has 1 million
| unique items in their catalog. But they also have tons of
| different categories. A single book cover weights around
| 30kb.
|
| I'll leave it as an excercise to figure out how much data you
| can fit into 30kb to make usable filtering system.
|
| btw: opening their front page downloads 12.1MB already.
| what wrote:
| >I'll leave it as an excercise to figure out how much data
| you can fit into 30kb to make usable filtering system.
|
| Not even 1 bit per item in the Barnes and nobles catalog?
| So not much.
| crazygringo wrote:
| > _I 'll leave it as an excercise to figure out how much
| data you can fit into 30kb to make usable filtering
| system._
|
| Into 30kb? That's just 300 items at 100 bytes each. So not
| a lot?
| mirkodrummer wrote:
| Thing is, and I believe it's a valuable example counterpoint,
| if I shift-click on a link, like sci-fi category, to open it in
| a new tab(very common thing people do), having a multi page
| application is zero work added, on an spa you have to manage
| that. If the link doesn't exist and categories can only be
| accessed by a select input then ux isn't that great
| paffdragon wrote:
| This is so annoying when SPAs break browser functionality
| like open link in new tab. Even if it works often it has to
| reload a bunch of JS again, which makes things veeery slow.
| This is why I really don't like Linear, I often open issues
| in separate tabs, which is every time a pain, browser freezes
| for seconds just to open a link in a tab...
| nevertoolate wrote:
| I think it was not designed for your use case. It is
| conveniently running in the browser but not a collection of
| links to html pages. The people quarreling in this comment
| section seemingly ignore that life is complex, web browsers
| are complex, web development is complex. Maybe you should
| think about linear as a desktop app and call it a day :)
| brulard wrote:
| Modern SPA frameworks give you this by default. You can deep
| link and get the specific page with all the
| parameters/filters etc applied server rendered in
| remix/react-router, next, sveltekit and most other
| frameworks. I agree that too many apps have basic things like
| CMD+click broken
| ThatPlayer wrote:
| In a similar use, a few of my hobby projects are hosted on
| static web servers. So instead of rendering out everything into
| individual pages, which would've been tens of thousands of
| pages, I have a JSON file that gets rendered by the client in a
| SPA. I have even used Github Pages for this
|
| I'm playing around with a newer version that uses a sqlite
| database instead. Sqlite officially has wasm builds, and the
| database file is already built to be separated into pages. With
| HTTP Range Requests, I can grab only the pages I need to
| fulfill any queries.
|
| Sqlite full text search even works! Though I'm hesitant to call
| that a success because you do end up grabbing the entire FTS
| table for shorter searches. Might be better to download the
| entire database and build the FTS table locally.
| danielscrubs wrote:
| Pjax was the goat.
| Zanfa wrote:
| Please no. Whenever I see an online store as a SPA catalogue I
| shudder, because it usually breaks after browsing a bit in a
| weird state. And it resets to somewhere random should you hit
| back, refresh or try to send a link to somebody.
| lblume wrote:
| Yes, SPAs should store simple user state in the URL as well.
| SenHeng wrote:
| > 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.
|
| This is what we[0] do too. We have a single JSON with a
| thousand over BOMs that's loaded directly into the browser.
| Previously we loaded the inventory data via an API as is
| usually expected. The fact that there's even an API meant
| requiring progress and loading bars, API unavailability
| scenarios, etc.
|
| Having it all as a single preloaded JSON meant that all of the
| above goes away. Response is instantaneous.
|
| [0]: https://chubic.com
| brulard wrote:
| This wouldn't work for 90% of apps out there. While I would
| love that approach, it has so many problems that in practice it
| never worked out for me. First problem is that data change.
| Either you edit it, or you need updates from server applied to
| your copy. This is quite complex (although there are some
| solutions, I had little luck in making this work reliably).
| Second - you don't want to share the whole catalog in one
| request. Third - in most cases there is a lot of data. It's not
| uncommon to have tens of thousands of items and for each you
| likely need some kilobytes. Four - you are downloading the
| whole catalog even for deep links which might not care about
| all but a tiny fraction of that data.
| kerkeslager 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.
|
| True, but as a user, I don't want you encapsulating my journey.
| You can wax poetic about hypothetical book categories, but the
| reality of SPAs is that they break back buttons, have terrible
| accessibility anti-patterns, attempt to control my attention,
| and expose my computer to all your bad security practices. SPAs
| usually contain half-assed implementations of half the features
| that ship standard in a modern browser, and the only motivation
| for all that effort is to make the site more favorable to the
| server's owner.
|
| When a site is implemented with simple HTML and careful CSS, I
| can configure it to my needs in the browser quite easily.
| That's a site that favors me, not your opaque blob nonsense.
| 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.
| sfn42 wrote:
| 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.
| LegionMammal978 wrote:
| > 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.
|
| Not if the client is, e.g., constantly moving between cell
| towers, or right near the end of their range, a situation
| that frequently happens to me on road trips. Some combination
| of dropped packets and link-layer reconnections can make a
| roundtrip take 2 seconds at best, and upwards of 10 seconds
| at worst.
|
| I don't at all disagree that too many tiny requests is the
| cause of many slow websites, nor that many SPAs have that
| issue. But it isn't a defining feature of the SPA model, and
| nothing's stopping you from thoughtfully batching the
| requests you do make.
|
| What I mainly dislike is the idea of saving a bit of client
| effort at the cost of more roundtrips. E.g., one can write an
| SSR site where every form click takes a roundtrip for
| validation, and also rejects inputs until it gets a response.
| Many search forms in particular are guilty of this, and also
| run on an overloaded server. Bonus points if a few filter
| changes are enough to hit a 429.
|
| That is to say, SSR makes sense for websites with little
| interaction, such as HN or old Reddit, which still run great
| on high-latency connections. But I get the sense it's being
| pushed into having the server respond to every minor redraw,
| which can easily drive up the number of roundtrips.
|
| Personally, having learned web development only a few years
| ago, my impression is that roundtrips are nearly the
| costliest thing there is. A browser can do quite a lot in the
| span of 100,000 ms. Yet very few people seem to care about
| what's going over the wire. If done well, the SPA model seems
| to offer a great way to reduce this cost, but it's been
| tainted by the proliferation of overly massive JS blobs.
|
| I guess the moral of the story is "people can write poorly-
| written websites in any rendering model, and there's no
| panacea except for careful optimization". Though I still
| don't get how JS blobs got so big in the first place.
| sfn42 wrote:
| > Not if the client is, e.g., constantly moving between
| cell towers, or right near the end of their range, a
| situation that frequently happens to me on road trips.
|
| Right, but how often is a user both using my website _and_
| on a roadtrip with bad coverage? In the grand scheme of
| things, not very often. I also think this depends on what
| the round trip is for. Maybe the 10s round trip is simply
| because it 's a rather large request.
|
| > I don't at all disagree that too many tiny requests is
| the cause of many slow websites
|
| That's not really what I was saying, though I don't
| disagree with it. If you're sending multiple small requests
| then there are two ways to go about it: You can send all of
| them at the same time, then wait for responses and handle
| them as they come back. The other option is to send a
| request, wait for a response, then send the next etc. The
| latter option causes slowness, because now you're stacking
| round trips on top of one another. The former option can be
| completely fine.
|
| But I'm not saying the client should be sending _lots_ of
| requests. I 'm saying they should get the data they need
| rather than all the data they could possibly need. This can
| be done in one request that gets a few kilobytes of data,
| you can fit 64kb in a single tcp packet. That's quite a bit
| of data, easily enough space to do useful stuff. For
| example the front page of HN is 8kb. It loads fast.
|
| I'm also not saying you should use SSR. I do think that SSR
| is a great way to build websites, but my previous comment
| was specifically about SPAs. You don't have to send
| requests for every little thing - you can validate forms on
| the frontend in both SPAs and SSR.
|
| Round trips are costly but not that much. A lot of round
| trips are unavoidable, what I'm saying is that you should
| avoid making them slower by sending too much data. And also
| avoid stacking them serially.
| Izkata wrote:
| > 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.
|
| This is actually a great example of what I mentioned
| elsewhere about how people seem to have forgotten how to make
| a SPA responsive. These are both simpler implementations, but
| not really the best choice for user interaction. A better
| solution is to take the paginated version and pre-cache what
| the user might do next: When the results are loaded, return
| page 1 and 2, display page 1, and cache page 2 so it can be
| displayed immediately if clicked on. If they do, display it
| immediately and silently request and cache page 3 in the
| background, etc etc. This keeps the SPA responsive with few
| to no loading spinners if they take the happy path, and
| because it's happening in the background you can
| automatically do retries for a flaky connection without
| bothering the user.
|
| This was how gmail and google maps blew peoples' minds when
| they were first released, by moving data to the frontend and
| pushing requests to the server into the background, the user
| could keep working without interruption while updates
| happened the background without interrupting their flow.
| sfn42 wrote:
| Yeah you can do that, but it's not necessary. You'll have
| to figure out a clever way to first wait for the data the
| user actually needs on the first load, then silently cache
| the other stuff in the background. Then you'll have the
| best of both worlds, but it complicates the application. It
| might make sense for Gmail and google maps, but there are a
| lot of web apps for which it does not make sense to put the
| work into this.
| 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.
| gjtorikian wrote:
| Wow, I remember Sencha! It's been a while since I'd heard
| that name.
| dsego wrote:
| I mostly remember doing $(document).ready blocks in php
| templates :)
| PaulHoule wrote:
| I wrote my first SPA, a knowledge graph editor, using GWT
| (Google Web Toolkit) which compiled a dialect of Java to
| JavaScript circa 2006 or so.
| 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.
| tomnipotent wrote:
| All three comments to this thread have missed the point
| that OP said installable SPA, not website SPA. This means
| the primary bundle is downloaded offline and only API
| network requests are necessary.
| jaredklewis wrote:
| I work on an SPA with hundreds of screens. We package it
| using off the shelf tooling with barely any configuration.
| All of the code and styling is still far under a megabyte
| gzipped.
|
| So unless it is an all text app, the size of the code
| bundle is probably going to be quickly dwarfed by the size
| of media like images, animated images, or videos.
|
| If a site has an SPA with a, say, 3mb code bundle, I think
| in most cases, that's not an architecture issue. It's
| probably an issue of poor engineering and switching to a
| MPA is not suddenly going to make those engineers
| competent.
| niutech wrote:
| Check out how bloated is MS Teams web app, for instance.
| throw-the-towel wrote:
| This is not true. In practice SPAs break completely when some
| network request fails which happens a lot on bad connections.
| heisenbit wrote:
| Sadly the art of error handling is often neglected by some
| SPA developers. I suspect that failures on the client are
| also less tracked this is tolerated by businesses.
| renegade-otter wrote:
| That has nothing to do with them being "SPA developers".
| They are just bad developers, lazy, or inexperienced.
|
| Errors/messages/warnings is one of the first things I do
| in an app framework, since it's incredibly hard to "bolt
| that on" later.
| wolpoli wrote:
| Honest question: Where are the places with low-bandwidth
| internet? Are we talking about cruise ships and satellites
| internet use cases?
| TimTheTinker wrote:
| There are folks who work with US-based nonprofits, NGOs,
| and agencies who live all over the world, including regions
| where local internet access is either non-existent or very
| slow. Some US-based organizations they work with have had
| to set up low-bandwidth methods of communicating. Yes -
| sometimes geosynchronous satellites are the only
| connectivity available.
| jcpst wrote:
| All over the world, including the United States.
| paradox460 wrote:
| Anyone attending a major event, or in a disaster zone.
| Things are getting better, but if you live near a ball park
| or something, there will be periodic times when your
| cellular Internet is unusable
| bobthepanda wrote:
| Also, anyone traveling on a train or motor vehicle will
| just sometimes have worse reception, particularly with
| anything like a tunnel.
| luis_cho wrote:
| There is this post about a experiment on google where they
| reduced the page weight and the traffic went up instead of
| down. That was because it open the site to countries with
| low internet bandwidth
| https://blog.chriszacharias.com/page-weight-matters
| tanduv wrote:
| TBH even in the SF Bay Area "tech capital of the world"
| you'll find areas with spotty reception.
|
| https://www.reddit.com/r/bayarea/comments/1cqhr4i/what_is_u
| p...
| PaulHoule wrote:
| Crazy hills will do wireless in anywhere. In a rural area
| I am maybe a mile from the tower as the neutrino flies
| but a photon can't make it. I have a bar of 5G in the
| pasture in front of the house but in the house it
| promises a bar of LTE but whether I can get out a text
| (w/o WiFi) depends on atmospheric conditions.
|
| Out in Cali they have ring of fire conditions.
|
| Too much crowding can do it too. A decade ago I was going
| to Cali a lot and thought it was funny to see so many ads
| for geospatial apps on TV that always showed a map of San
| Francisco when for me SF was where GIS went to die.
| Taking my Garmin handheld to the roof of the Moscone
| center because it was the only place it could get a clear
| view of the sky to sync up with GPS, so many twisty
| little streets that routing algorithms would struggle....
| Being guided around to closed restaurant after closed
| restaurant and walking past 10+ open ones because a co-
| worker was using Yelp, etc.
| leptons wrote:
| Back around 2001 I visited South Carolina, and it was
| like being transported to the future of mobile internet.
| They had some kind of high-bandwidth cellular setup in
| the area that was far ahead of the rest of the country at
| the time, I think I recall it being around 20Mbit
| wireless. I was told the area was a testing ground for
| new tech. I was kind of shocked that somewhere that
| seemed so stuck in the past had such cutting edge tech
| deployed. I thought why is this not in SF??
| tcfhgj wrote:
| Everywhere, my provider limits me to 32 kbit/s
| goodpoint wrote:
| 3 billions people live in places with low-bandwidth /
| unreliable / expensive internet
| maccard wrote:
| I live in the middle of a major UK city, which is one of
| the most visited tourist destinations in the UK (if not the
| world). There are massive gaps of mobile coverage in the
| city - 5G is spotty at best, and it regularly falls back to
| much older protocols in the city. There are dead zones
| where you can literally walk 6 ft and drop to 0 coverage,
| and walk another 6ft and be on full blown 5G. Apps and
| sites like uber, twitter, Reddit, instagram all handle
| these awfully.
| al_borland wrote:
| Often times my house. I live in one of the 20 largest metro
| areas in the US. There is a cellular dead spot around my
| house, seemingly from AT&T and Verizon. Phones work, but
| barely. Pages with high data demands become a problem.
| andersmurphy wrote:
| I think with brotli over SSE you can do just fine with 3G and
| bad networks without needing to be a SPA. Keeping almost all
| state on the sever make realtime collaborative apps much
| simpler than data sync you need with SPA. This demo has zero
| client side state and handles concurrent interactions over a
| billion data points [1].
|
| - [1] https://checkboxes.andersmurphy.com
| 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.
| Dylan16807 wrote:
| The rule is either "uses html to render" or an even
| looser "renders in the browser". That doesn't seem like a
| deep constraint to me. You exclude a couple very popular
| but historical plugins where the browser set up a
| rectangle and handed it off to an external piece of code,
| and pretty much nothing else.
| 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.
| keeganpoppen wrote:
| oh man now THAT is a real blast from the past. oh man,
| pretty classic "where did all the time go?"... "oh yeah i
| forgot that i spent like 100s of hours battling with sencha
| back in the day". selective memory isn't always a bad
| thing, i guess.
| 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.
| aryonoco wrote:
| Angular not only appeals to Java developers, it also appeals
| to .NET developers. TypeScript of course borrowed a lot from
| C# (having the same designer) and dependency injection, MVC
| patterns etc closely resemble .NET patterns.
|
| Interestingly, new Angular is slowly moving away from these,
| introducing Signals for state management and standalone
| components, and I see these developers actually struggling a
| lot to adopt new Angular patterns.
|
| Still, I believe Angular is a really great platform for
| building B2B or enterprise apps. It's testing and forms
| handling is far ahead of every other SPA, and it actually
| fees like a cohesive framework where people have spent time
| designing things the right way; something I absolutely cannot
| say about react frameworks such as Next.js or Remix.
| youngtaff wrote:
| Angular was created so Java developers could create browser
| apps
| leptons wrote:
| Angular 1.x seems vastly different than Java. I doubt a
| Java developer would want to use it, so I'm not sure your
| claim is valid.
| aryonoco wrote:
| PS and I forgot to mention, new Angular patterns such as
| Signals and standalone components great cut down on the
| boilerplate and the verbosity. It's not (and will never be)
| something like SolidJS, but each new version is clearly
| moving away from the heavy OO-based and multi layered
| patterns.
| paradox460 wrote:
| Wasn't there the Google closure compiler before angular?
| brabel wrote:
| And GWT which allowed literally running Java on the web
| (without a plugin, it compiles Java to JS). It still exists
| and is maintained but not a Google project anymore despite
| the name.
|
| https://www.gwtproject.org/
| 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...?
| albedoa wrote:
| > If jQuery is misused in the hands of bad programmers ALL
| THE TIME, that becomes the culture.
|
| My bet is that everyone here both agrees with you and is
| able to replace "jQuery" with "HTML", "CSS", and
| "JavaScript" to reach similar conclusions about the
| cultures of each. The problem is bad programmers, not the
| tech.
| bobthepanda wrote:
| Jquery is good for dom manipulation, though most of the best
| ideas have become vanilla javascript standards.
|
| It isn't really equipped or opinionated on statefulness,
| which means that everybody was at one point kludging stuff
| onto it that didn't make sense.
| PaulHoule wrote:
| It drives me crazy when it used together with React --- I
| want to have one authoritative copy of the state of my app,
| and jQuery bypasses that, at least if I'm using controlled
| forms.
|
| Now I used to _hate_ uncontrolled forms but now I like react-
| hook-form.
| 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. There's a comment right here in this discussion
| _advocating_ for this! [1]
|
| 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.
|
| [1] "It's much better ux when a user downloads the whole
| catalogue" from: https://news.ycombinator.com/item?id=44688834
| geraldwhen wrote:
| Can't hire for anything else. Competence in development no
| longer exists. And AI is making this march to idiocy worse.
| dsego wrote:
| And the frontend-backend paradigm has seeped into the
| engineering culture and even the non-engineers on the team
| understand things in those terms. The main way we break apart
| work into tickets is API endpoints and client-side UI stuff.
| usrusr wrote:
| This. The mental model of an API with a frontend deployed
| as static resources just happens to be very attractive.
| Even more so when the SPA isn't the only frontend, or when
| you don't _know_ that the SPA will remain the only frontend
| forever. When you have an SPA sitting on top of an API,
| introducing new clients for feature subsets (e.g. something
| running on a Garmin watch) becomes trivial.
|
| If you have a huge org working on the project you might
| actually succeed in sticking to that architecture even when
| serving as plain old HTML, but smaller teams are likely to
| eventually write full stack spaghetti (which might still be
| fine for some use cases!). Once there was a fashionable
| term "progressive web app", with manifest workers
| optionally moving some backend stuff into the browser for
| offline-ish operation, and these days I also see a parallel
| pattern: progressively moving a browser UI into an
| electron-esque environment, where you can features
| requiring more local access than the browser would allow.
| jiggawatts wrote:
| > introducing new clients for feature subsets (e.g.
| something running on a Garmin watch) becomes trivial.
|
| This never happens, for some values of never.
|
| When a SPA app is initially developed, the "client" and
| the "API" are moulded to each other, like a bespoke piece
| of couture tailored to an individual's figure. Hand-in-
| glove. A puddle in a depression.
|
| There is absolutely no way that some other _category_ of
| platform can smoothly utilise such a specialised, single-
| purpose API without significant changes.
|
| The reality is that most SPA apps are monoliths, _even
| if_ the client app and the API app are in different Git
| repos in order to pretend that this is not the case.
| nemothekid wrote:
| > _every SPA app I've ever seen is two orders of magnitude
| slower than ordinary HTML would have been._
|
| I'd argue then you don't have an SPA. However I don't see how
| you could have a application like Figma or Discord and say
| "ordinary HTML is faster" (or even possible).
| jiggawatts wrote:
| For ever one real "app" like Figma there are hundreds of
| web pages with some forms and light interactivity.
| Numerically there are far more enterprise LoB apps than
| there are true web _applications_ that SPAs are well suited
| for.
| nemothekid wrote:
| You claimed "every SPA" app, now its down to "most". I'm
| not going to argue against the fact that some people have
| hammers and only see nails.
|
| Every popular technology has been over implemented -
| these same enterprises probably have a 100-node Spark
| cluster to process 1GiB of data.
| jiggawatts wrote:
| "Every SPA app I've _ever seen_ ". I'm yet to see a fast
| one. Maybe they exist! I wouldn't know.
|
| YouTube, _for me_ , is unfathomably slow. It takes about
| a minute before I can get a specific song in one of my
| playlists playing. Every view change is 5-20 seconds,
| easily.
|
| Facebook and the like now show polyfills for 10-30
| characters of text, because hundreds of thousands of
| servers struggle to deliver half a line of text over
| terabits of fibre uplinks. Meanwhile my 2400 baud modem
| in the 1990s filled the screen with text faster!
|
| Jira famously was so slow that this would never fail to
| be mentioned here any time it was mentioned. Service Now
| is better, but still slow for my tastes.
|
| Etc...
|
| If you disagree, link to me a fast SPA app that you use
| on a regular basis.
|
| PS: Just after writing this, I opened a Medium article,
| which used -- I assume -- SSR to show me the text of the
| article quickly, then _replaced it_ with grey polyfills,
| _and then_ 6 full seconds later it re-rendered... the
| same static text with a client-side JavaScript SPA app.
| 100 requests, 7 MB, for 2 KB of plain text.
| econ wrote:
| You mean a chat client? That seems a good worse case
| scenario.
|
| If you limit history to the most recent message (and have
| an link to the archive at the top) you could simply reload
| the entire page on some interval that declines with message
| frequency (and when you submit the form)
|
| Since the html document is pretty much empty the reload
| happens so fast you won't see the flashing. With
| transitions it would be perfectly smooth.
|
| With modern css you can put the elements out of order. You
| can simply append the new line to the end of the html
| document that represents the channel. (And to the archive)
| Purging a few old lines can be done less frequently.
|
| I haven't tried it but it should work just fine. I will
| have to build it.
|
| Initial load will be 100x faster. The page reloads will be
| larger but also insanely robust.
| nemothekid wrote:
| > _You mean a chat client? That seems a good worse case
| scenario._
|
| No, I mean discord. An application where you can chat,
| recieve phone calls and watch a live stream all at the
| same time.
|
| A pure html chat client is uninteresting - there have
| been realtime html chat clients since I was teenager,
| even before the release of jquery.
| econ wrote:
| The things I was wondering about were: 1) can a non spa
| chat client be as good as a spa. 2) at what point is a
| spa justified. (is chat enough?)
|
| Phone calls and live streams are things for which a tab
| needs to stay open. If you want to do other things
| simultaneously both the browser and the OS could
| facilitate it - but do so rather poorly.
|
| It's not why people make spa's it seems?
| albedoa wrote:
| > You mean a chat client?
|
| Calling Discord "a chat client [sic]" is barely one step
| removed from "I could build that in a weekend". So go
| ahead. Wait, what is stopping you?
| econ wrote:
| No audience.
| Zanfa wrote:
| Does a real-world example of bandwidth saving even exist for
| SPAs? It's always the other way around where what could've
| been a single page load, ends up being 6 separate
| asynchronous calls to different APIs to fetch random bits and
| pieces while the user stares at spinners.
| 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.
| wldcordeiro wrote:
| Lots of SPAs now are code-split too for what it's worth so
| you shouldn't really have large bundles to download if you're
| splitting things well.
| paulryanrogers wrote:
| Is this true everywhere? Isn't much of the world still on
| slow mobile networks?
| yawaramin wrote:
| Being on a slow mobile network and having to reload
| changing bundles multiple times a day to use SPAs would be
| an even worse UX.
| youngtaff wrote:
| > HTTP 2 has been adopted by browsers for like 10 years now
| and its multiplexing makes packaging large single bundles of
| JS irrelevant
|
| H2 doesn't make packing irrelevant... there's still an IPC
| overhead with many small files... and larger bundles tend to
| compress better (though compression dictionaries might help
| here)
|
| Large Js bundles are a huge problem though
| jongjong wrote:
| SPAs are nice when your app requires complex state; multiple
| rows of nested tabs, modals, multiple interlinked select inputs
| which load data dynamically, charts or graphs which can lazy-
| load data and update on the fly in response to user actions.
|
| There is a certain level of complexity beyond which you need to
| load data on the fly (instead of all up front on page load) and
| you literally cannot avoid an SPA. Choosing to build an SPA is
| not just some arbitrary whimsical decision that you can always
| avoid.
|
| Sometimes people just go straight to SPA because they're unsure
| about the level of complexity of the app they're building and
| they build an SPA just to be sure it can handle all the
| requirements which might come up later.
|
| One of my first jobs involved rebuilding a multi-page EdTech
| 'website' as an SPA, the multi-page site was extremely
| limiting, slow and not user-friendly for the complex use cases
| which had to be supported. There was a lot of overlay
| functionality which wouldn't make sense as separate pages.
| Also, complex state had to be maintained in the URL and the
| access controls were nuanced (more secure, easier enforce and
| monitor via remote API calls than serving up HTML which can mix
| and match data from a range of sources).
|
| I think a lot of the critiques of SPAs are actually about
| specific front end frameworks like React. A lot of developers
| do not like React for many of the reasons mentioned like
| 'resetting scrollbars' etc... React is literally a hack to try
| to bypass the DOM. It was built on the assumption that the DOM
| would always be unwieldy and impossible to extend, but that did
| not turn out to the the case.
|
| Nowadays, with custom web components, the DOM is actually
| pretty easy to work with directly but info about this seems to
| be suppressed due to React's popularity. Having worked with a
| wide range of front end frameworks including React for many
| years, the developer experience with Web Components is
| incomparably superior; it works exactly as you expect, there
| are no weird rendering glitches or timing issues or weird
| gotchas that you have to dig into to. You can have complex
| nested components; it's fast and you have full control over the
| rendering order... You can implement your own reactivity easily
| by watching attributes from inside a Web Component. The level
| of flexibility and reliability you get is incomparable to
| frameworks like React; also you don't need to download
| anything, you don't need to bundle any libraries (or if you do,
| you can choose how to bundle them and to what extent; you have
| fine-grained control over the pre-loading of scripts/modules),
| the code is idiomatic.
| Tokumei-no-hito wrote:
| i remember seeing web components years ago, it sounds like
| they've improved a lot.
|
| what do you do about the lack of (i assume) ecosystem? due to
| the ready ubiquity there's practically a library for
| everything. do you find that using WC you are having to hand
| roll a lot? i don't mean to be a package slave but for
| complex and tedious things like graphs / charts.
| niutech wrote:
| There is an ecosystem for Web Components: Polymer, Lit,
| WCB, ready-built web components at
| https://webcomponents.org
| dannye wrote:
| Latest blogpost on that site is from 2018
|
| I presume Web Components are so great they haven't had
| anything happen since 2018
| dannye wrote:
| > there are no weird rendering glitches or timing issues or
| weird gotchas that you have to dig into to.
|
| Ehm... define the Web Component render blocking in the head,
| because you want to prevent FOUCs. Then try to access the
| .innerHTML of your Web Component in the connectedCallback
|
| https://dev.to/dannyengelman/web-component-developers-do-
| not...
| wild_egg wrote:
| > in exchange for having really small network requests after
| the load.
|
| I'd love to see examples of where this is actually the case and
| it's drastically different from just sending HTML on the wire.
|
| Most SPAs I've worked on/with end up making dozens of large
| calls after loading and are far far slower than just sending
| the equivalent final HTML across from the start. And you can't
| say that JSON magically compresses somehow better than HTML
| because HTML compresses incredibly well.
|
| Most arguments about network concerns making SPAs a better
| choice are either propaganda or superstition that doesn't pan
| out in practice.
| raron wrote:
| > I'd love to see examples of where this is actually the case
| and it's drastically different from just sending HTML on the
| wire.
|
| There are complete CAD applications running in browsers for
| PCB and mechanical design with many layers, 3D view,
| thousands of components, etc.
|
| For example: https://easyeda.com/ https://www.onshape.com
|
| > because HTML compresses incredibly well
|
| Haven't compression under TLS have been mostly disabled after
| CRIME and BREACH attack?
| niutech wrote:
| No, HTTP compression is widely used (brotli increasingly).
| chuckadams wrote:
| BREACH would be the relevant attack for content-encoding
| compression, it's only good for guessing the content of the
| response that can't actually be read otherwise, i.e.
| stealing a csrf token in cross-site requests, requires that
| the server echo back a chosen plaintext in the response
| (e.g. a provided query string), and takes thousands of
| requests to pull it off.
|
| It's a vanishingly small number of things that are actually
| vulnerable to this attack, and I've never even heard of a
| successful real-world exploit (tho it's not like the
| attackers that might use this go and tell everyone).
| 8n4vidtmkvmk wrote:
| With HTML you have to send both the template and the data.
| With json, it's just the data. So it's less information
| total. It should compress a little better, but I don't have
| stats to back that up.
| maccard wrote:
| HTML templates are still text, text compressed well. As
| with all these discussions "it depends, profile it" is the
| only answer. People blindly assuming that X is better is
| why things are slow and shitty in the first place
| goatlover wrote:
| Do browsers have trouble loading and rendering HTML in
| 2025? Page load should be blazing fast if it's not loaded
| down with a bunch of other stuff that hasn't already been
| cached.
| 8n4vidtmkvmk wrote:
| They don't. The reason to do it is not to save bytes, but
| because you have a dynamic page that needs to respond to
| the user without doing a full page refresh on every minor
| interaction.
| wild_egg wrote:
| > I don't have stats to back that up.
|
| Your comment then falls under my "superstition" label.
|
| My experience has been that the HTML version will send
| overall _less_ data since it contains precisely what is
| required by the UI and nothing more. The JSON APIs try to
| be "generic" across clients and either send more than the
| client needs or send less and cause the client to wait on a
| waterfall of requests to load everything.
|
| You should always run benchmarks for your use case but the
| majority of web projects are not Figma or AutoCAD and
| benefit drastically from simpler approaches. A single
| compressed HTML response will beat a cascade of JSON ones
| every time.
| 8n4vidtmkvmk wrote:
| For first load, yes. The idea is that you never have to
| send the template again after that.
|
| Cascading is a separate problem. You can bundle all the
| data into a single request if you want.
|
| You can even send JSON along with the HTML in the first
| request.
| cheema33 wrote:
| > ...if you shared that misunderstanding of SPAs and used them
| to solve the wrong problem, this article is 100% correct.
|
| Agreed. The article was a frustrating read. The author is an
| SEO consultant. SEO consultants likely have a heavy focus on
| marketing websites. Actual apps and not marketing websites do
| benefit significantly from SPA. Imagine building Google Maps
| without SPA. You can animate page transitions all you want, the
| experience will suck!
| Tokumei-no-hito wrote:
| to be fair to both points:
|
| he has a really warped view that SPAs are somehow purely
| about routing.
|
| he does correctly point out that a lot of sites could and
| should be treated as sites not apps.
| pyman wrote:
| I agree with you. The author's point is that browsers have
| finally understood why some traditional sites were created
| as SPAs, which involves recreating some of the
| functionality browsers already offer today. But that
| doesn't mean all SPAs should turn into MPAs now.
|
| IMO it will be hard for some traditional sites to adapt to
| the new browser capabilities, since we've built an entire
| ecosystem around SPAs. The author's advice should've been:
| use the browser's built-in capabilities instead of client-
| side libraries whenever possible.
|
| Also, keep in mind he's sharing his own experience, which
| might be different from ours. I've used some great SPAs and
| some terrible ones. The bad ones usually come down to
| inexperience from developers and hiring managers who don't
| understand performance, don't measure it, don't handle
| errors properly, and ignore edge cases.
|
| Some devs build traditional sites as SPAs and leave behind
| a horrible UX and tech debt the size of Mount Everest. If
| you don't know much about software architecture, you're
| more likely to make mistakes, no matter what language or
| framework you're using.
|
| I realised years ago there's no "better" language,
| framework, platform, or architecture, just different sets
| of problems. That's why developers spend so much time
| debating implementation details instead of focusing on the
| actual problems or ideas. And that's fine, debates can be
| useful as long as we don't lose sight of what we're trying
| to solve and why.
|
| For example: Amazon's developers went with an MPA. Airbnb
| started as an MPA but now uses a hybrid approach. Google
| Maps was built as an SPA, while the team behind Search went
| with an MPA.
| docmars wrote:
| Even for basic sites, I tend to reach for an SPA because
| I never know when I'll be adding dynamic features,
| anything from basic showing / hiding of content, list /
| configuration-based rendering, or requesting data.
|
| It's usually inevitable, so it's easier to scaffold a
| Vite template and get cracking without any additional
| setup. The time-to-deploy is fast using something like
| Netlify or Vercel, and then I have the peace of mind
| knowing I can add additional routes or features in a
| consistent, predictable way that fits the framework's
| patterns.
|
| I'd hate to develop an MPA and realize after the fact
| that now I need complex, shared data across routes and
| for the UX to be less disrupted by page loads. Once
| you've dug that hole, you either have to live with it, or
| face a painful rewrite later.
|
| The exception I often see is targeting mobile devices in
| low-bandwidth areas where larger application bundles take
| longer to load, but I have to wonder how often this is
| the target audience. I live in a place where mobile data
| speeds are horrible, and access to WiFi is abundant, but
| even so, I rarely have a situation where I *need* to load
| up a non-critical site on the go -- and having apps pre-
| installed doesn't really help either when the data
| they're requesting is barely trickling in on mobile.
|
| So this oft-used exception doesn't really make sense to
| me unless I learned why this is so critical for some
| people.
| pyman wrote:
| I agree. There's a rich ecosystem for building SPAs with
| MACH architecture. There's no going back now, not even
| for basic apps.
| graealex wrote:
| SPAs are about APIs, and leaving the rendering entirely to
| the client.
|
| It's a reimagination of ye Olde three tier approach.
| Perfect for apps.
| cosmotic wrote:
| Google maps is a mess these days. Its glitchy, slow, has
| broken navigation, and is overloaded with unpredictable
| dynamic content. It's even worse in the native android app.
| Id totally go for the original version but with the more
| recent vector maps.
| scott_w wrote:
| The reasons it sucks are nothing to do with it being an
| SPA, though.
| danielscrubs wrote:
| I 100% would like to see an MPA Google Maps.
|
| Being able to come back to a webpage with previous
| directions? I think it would be glorious.
| pas wrote:
| You are mixing up linkability/history and being an MPA/SPA.
|
| Many websites simply have some session/state dependent
| page.
| danielscrubs wrote:
| Google Maps cant even preserve state in their iOS app.
|
| They are either the worst developers in the world or it
| is not simple.
|
| I don't rule any of the two possibilities out.
|
| Some things you get for free with the correct
| architecture. For whatever reason, SPA does not have a
| great track record with their users.
| Quarrel wrote:
| > They are either the worst developers in the world or it
| is not simple.
|
| Or they have a good reason to not do it (in some PMs
| mind).
|
| At a guess, resetting the view, and displaying the
| nearest Domino's Pizza sponsored highlight pin on the
| map, could be one of them.
| al_borland wrote:
| My biggest gripe with Google Maps is when I pan to a
| specific area, hundreds, or even thousands of miles from
| my current location, then search for something like
| "restaurants" and it pans me back home and searches
| there, so I then have to go find my distant location
| again and click the search here button.
|
| If this is an intentional choice, all in an effort to
| show me more local ads... ugh. I really hope this isn't
| the case.
| Quarrel wrote:
| I hate that too. Even when it is just across the one
| city, it is a major pain in the ass.
| DangitBobby wrote:
| Google Maps makes it really hard to explore your travel
| destination, or I am holding it wrong. That and the lack
| of weather integration are my main issues with it.
| simonw wrote:
| I have one of those!
|
| https://datasette-tiles-
| demo.datasette.io/-/tiles/basemap?no...
|
| I wish I could take full credit but it was a PR by dracos:
| https://github.com/simonw/datasette-tiles/pull/16
| luis_cho wrote:
| The author states that MPA are not a solution for
| everything. Sure google maps don't fit the MPA model but
| I've seen a lot of projects that would be much better using
| current browser features instead of react.
| tanduv wrote:
| the web app already supports history navigation.
| arccy wrote:
| that has nothing to do with an mpa
|
| these days there's a "copy link" button for directions
| which you can save / share
| thro1 wrote:
| > But SPAs came about in the days of jQuery, not React.
|
| (viper.pl 2000, philips.pl 2001 .. - are.. ' _unreal_ ' ??
|
| _' uloJSON':
| https://web.archive.org/web/20020702120539js_/http://www.vip...
|
| historised chained htmls restart onerror:
| https://web.archive.org/web/20020402025320js_/http://www.aut...
| _)
|
| jQuery 2006, React 2013
| youngtaff 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.
|
| Only for certain types of applications... the route change time
| for many SPA's is way higher than for the equivalent MPA
| KronisLV wrote:
| > SPAs make sense when your users have long sessions in your
| app.
|
| SPAs also make sense when you want to decouple the front end
| from the back end, so that you have a stable interface like a
| RESTful API and once AngularJS gets deprecated you can move to
| something else, or that when your outdated Spring app needs to
| be updated, you'll have no server side rendering related
| dependencies to update (or that will realistically prevent you
| from doing updates, especially when JSF behavior has changed
| between versions, breaking your entire app when you update).
|
| > When it is worth the pain to load a large bundle in exchange
| for having really small network requests after the load.
|
| The slight difference in user experience might not even enter
| the equation, compared to the pain that you'd have 5 years down
| the line maintaining the project. As for loading the app,
| bundle splitting is very much a thing and often times you also
| get the advantage of scoped CSS (e.g. works nicely in Vue) and
| a bunch of other things.
| jbreckmckye wrote:
| This article is full of misrepresentations and lazy takes. The
| author has had other anti-JS polemics widely upvoted on HN,
| which were just as carelessly written. But people upvote it
| anyway.
|
| What is the cause of this?
|
| 1. Bad experiences with JavaScript apps that have aggregated
| complexity (be it essential or incidental complexity)?
|
| 2. Non-JS developers mystified and irritated at a bunch of
| practices they've never really internalised?
|
| 3. The undercurrent of "frontend is not real programming"
| prejudice that existed long before React etc al. and will
| continue to exist long after it?
| cleoxjefbjxis wrote:
| You miss the whole point and the author is correct about
| this:
|
| Modern CSS is powerful, and HTML is the way to deliver web
| content.
|
| Every web framework is _literally_ a hack to make the web
| something it isn't. People who haven't seen the evolution
| often pick up the bad habits as best practice.
|
| For thise JavaScript people, I recommend trying Laravel or
| Ruby/Rails. And then once you realize that JavaScript sucks
| you'll minimize it.
| jbreckmckye wrote:
| Laravel is fine. It's not _amazing_. Like most "Modern
| PHP" it exhibits a Java fetish and when used carelessly can
| degrade into an upside-down impression of Enterprise J2EE
| patterns (but with an almost non-existent type system).
|
| What I find interesting though is the assumption that web
| dev is done by "JavaScript people", that even the best
| "JavaScript people" have no technical breadth, and
| therefore fester in a cesspool of bad ideas, unlike your
| median backend dev who swims in the azure lakes of
| programming wisdom.
|
| Now, I've done plenty of SPAs, but I've also done plenty of
| other things (distributed systems, WebVR apps,
| metaprogramming tools, DSLs, CLIs, STB software, mobile
| apps, a smidgeon of embedded and hobbyist PSOne games).
| Which gives me the benefit of a generalist perspective.
|
| One thing I have observed is that in each silo, there are
| certain programmers who assume they are the only sane group
| in the industry. They aren't interested in what problems
| the other siloes are solving and they assume any solution
| "over there" they don't understand is bad / decadent /
| crazy.
|
| These groups all regard each other with contempt, even
| though they are largely addressing similar fundamental
| issues in different guises.
|
| It's a social dynamic as much as any technical one.
| PaulHoule wrote:
| It's connected with the questions around occupational
| licensing of programmers, unions, and similar structures
| which would not be so much about getting paid more but
| about getting quality up, squashing bullshit, and getting
| our quality of life up.
|
| Without a cohesive community, mutual respect, and
| recognition of a shared body of knowledge, we don't have
| the solidarity to make it happen.
|
| As for Laravel, I'd say people were making complex
| applications (Ebay, Amazon, Yahoo) in 1999 --- Google
| Maps were better than Mapquest, which drew each image
| with a cgi-bin, but many SPA applications are form
| handling applications that could have been implemented
| with the IBM 360 and 3270 terminal.
|
| The OG web was missing a few things. Forms were usually
| written on one HTML page and received by a separate cgi-
| script. To redraw the form in case of errors you need one
| script that draws the form and draws the response and a
| router that choose which one to draw. You need two
| handfuls of helper functions, for instance
| <? draw_select($options,$selected_options,$attributes) ?>
|
| to make forms which can be populated based on what's
| already in your database. People never wrote down "the 15
| helper functions" because they were too busy writing
| frameworks like Laravel and Ruby-on-Rails that did 20x
| more than you really needed. So the knowledge to build
| the form applications we were building in 1999 is lost
| like the knowledge of how the pyramids were built.
|
| As for performance, web sites today really are bloated,
| it's not just the ads and trackers, it's shocking how big
| the <head/> of documents get when you are including three
| copies of the metadata. If you are just drawing a form
| and nothing else, it's amazing how fast you can redraw
| the whole page --- if you are able to delete the junk,
| old school apps can be as fast as desktop apps on the LAN
| and still be snappy over mobile.
| wredcoll wrote:
| > The OG web was missing a few things. Forms were usually
| written on one HTML page and received by a separate cgi-
| script. To redraw the form in case of errors you need one
| script that draws the form and draws the response and a
| router that choose which one to draw
|
| Yes, I was there, I wrote and used these pages. It
| sucked. Things are better now.
|
| > So the knowledge to build the form applications we were
| building in 1999 is lost like the knowledge of how the
| pyramids were built.
|
| Building a form with zero user affordances is not
| difficult. It just isn't good.
|
| We absolutely know how the pyramids were built. You get a
| whole bunch of humans to move a very large amount of
| stone and then stack it up in a big pile. The reason
| nobody builds pyramids today is because we have better
| alternatives.
| PaulHoule wrote:
| I've been in a happy place with React with some projects.
|
| I've worked on some where it was valid choice but boy the
| annoyances, like not being able to test your components
| because you're on an old version of React where your test
| framework can never know when the last render happened
| because you depend on a large number of components which
| don't believe they'd run on the current react but
| probably would if you could just vendorize 30 or so
| packages and patch their package.json files.
|
| Or depending on a test framework that refuses to look up
| components by class, id or selector because they want to
| force you to use aria, even when it doesn't make sense
| such as in three.js.
|
| Or depending on a routing framework that doesn't get
| maintained, instead they've been through 7 incompatible
| versions of it which leaves me thinking that _they_ didn
| 't ever believe in what they were doing.
|
| Or having to understand the internals of 5 CSS frameworks
| (including JS-heavy frameworks like Emotion) to handle
| all the components you've sucked in and still understand
| raw CSS through-and-through to fill the gaps.
|
| I worked on one system which was frankly experimental at
| a startup that was doing two week sprints building a tool
| called "Themis" for building ML training sets. The thing
| was that we were always having to add new tasks and
| between Docker and an overengineered back end and front
| end it took 20 minutes to go from source code to being
| able to interact with the thing, so it took a 20 person
| team and lots of coordination between FE and BE engineers
| to do the simplest things.
|
| I sketched out an alternative called "Nemesis" which grew
| into an HTMX-based system where it takes one programmer
| an hour to code a task and there is no build, and between
| Flask and the 15-or-so helpers it is easy. I've hacked it
| to be an RSS reader, an image sorter, and several other
| centaurs:
|
| https://mastodon.social/@UP8/114887102728039235
|
| this feels like a desktop app when I am on the LAN and
| loads well under a second on a mobile hotspot the first
| time _and every time_. The key is that the tasks are
| nearly completely independent of each other, there are no
| builds and no dependencies, so writing a new task can 't
| break old tasks. That system has plenty of screens that
| use d3.js for awesome visualizations and if I wanted to
| make a task that did something complicated which would
| really deserve React or Svelte or something I could do
| it, again, without breaking the the other tasks.
| wredcoll wrote:
| > I sketched out an alternative called "Nemesis" which
| grew into an HTMX-based system where it takes one
| programmer an hour to code a task and there is no build,
| and between Flask and the 15-or-so helpers it is easy
|
| My argument here is basically _creating that_ is really,
| really hard, and there 's no framework or library that
| will make it easy.
|
| React and friends are a mess because they're dealing with
| hard problems, kinda like systemd or kubernetes.
|
| Writing code that lives entirely inside the machine is a
| lot easier than having to interface with the messy real
| world.
| Capricorn2481 wrote:
| > One thing I have observed is that in each silo, there
| are certain programmers who assume they are the only sane
| group in the industry. They aren't interested in what
| problems the other siloes are solving and they assume any
| solution "over there" they don't understand is bad /
| decadent / crazy
|
| A lot of coders have realized there's social credit in
| trashing other programmers. I regularly see comments from
| people claiming to have a singular custodial spirit for
| their craft, unrivaled by their peers. There's obviously
| advantages to telling people that everyone else is
| holding it wrong.
|
| Then their advice is
|
| - Some niche trick that's completely irrelevant to most
| situations
|
| - Something that sounds obvious and uncontroversial, but
| is so broad and vague that it's not even worth arguing
| about.
|
| And I realize the irony of me making this comment. But I
| wish we'd get over this phase where everyone thinks
| they're an expert, and that every bad codebase or slow
| app was the result of someone who didn't care. I have yet
| to work with someone who didn't care about their code.
| girvo wrote:
| > But I wish we'd get over this phase where everyone
| thinks they're an expert, and that every bad codebase or
| slow app was the result of someone who didn't care.
|
| I can only speak to my own experience, but it's been this
| way for the entire 18 years I've been doing this
| professionally and I can't see it stopping anytime soon.
|
| I just ignore it and write off people who openly think
| that way. It shows a lack of experience and empathy.
| esskay wrote:
| > Laravel is fine. It's not amazing. Like most "Modern
| PHP" it exhibits a Java fetish and when used carelessly
| can degrade into an upside-down impression of Enterprise
| J2EE patterns (but with an almost non-existent type
| system).
|
| As opposed to Javascript, the pinnacle of tight standards
| and high quality performative code...
|
| The same arguments that can be made against PHP/Laravel
| absolutely apply to Javascript equaly, if not more so due
| to the pretty well know shiny object syndrome issues that
| many JS devs get caught up in.
| zwnow wrote:
| Even with Laravel you will write lots of Javascript unless
| you go for blade templates or that other templating thing.
| Javascript is also great for making the web interactive.
| Maybe the sheer amount of SPAs out there shows us what we
| really want from the web. Most things ppl use in their day
| to day life cant be built with HTML and CSS only
| brigandish wrote:
| > Maybe the sheer amount of SPAs out there shows us what
| we really want from the web.
|
| A distribution and installation system that works on
| almost any device?
| zwnow wrote:
| Interactivity and a way to build experiences and
| applications. Not just passing documents back and forth
| esskay wrote:
| What 'other' templating thing? I'm assuming you're likely
| talking about either Intertia or Livewire. Inertia's more
| geared towards SPAs than Livewire though. Most Laravel
| devs tend to use JS sparingly - not everything needs JS.
|
| Theres next to no reason why the vast majority of sites
| on the web would ever need to be heavily reliant on JS.
| Rendered HTML/CSS with JS being used sparingly for page
| functionality is a far better user experience. I'll never
| understand the obsession with JS for the sake of JS.
| zwnow wrote:
| Yea Livewire, couldn't think of the name.
| graealex wrote:
| Are you aware that nowadays you can write SPAs in dozens of
| languages?
|
| It's an entirely different concept. It's certainly not the
| right technology for a news site, but days ago in a
| different place, there was for example the discussion about
| how an SPA and minimalistic API services fit a lot better
| with your average embedded device.
| motorest wrote:
| > You miss the whole point and the author is correct about
| this:
|
| your comment is funny, because you are so wrong you aren't
| even aware how and why you are wrong. It's in "not even
| wrong" territory. I'll explain you why.
|
| > Modern CSS is powerful, and HTML is the way to deliver
| web content.
|
| Irrelevant. That's not why the world uses JavaScript
| frameworks. It seems you aren't even aware of the most
| basic reasons why the world migrated to SPAs. The most
| basic reasons are performance (and perceived performance),
| not only because the require less data to be moved around
| the internet but also every flow doesn't require full page
| reloads.
|
| Also, classic old timey server-side rendered WebApps end up
| being far more complex to develop and maintain as you mix
| everything together and you are unable to have separation
| of concerns regarding how your platform is deployed and ran
| and how your frontend works. SPAs even allow your frontend
| team to go to the extent of handing your backend as if it
| was a third-party service, and some SPAs are even just
| that. There are plenty of CMSs out there which eliminate
| the need for a backend by providing all content needs
| through their commercial APIs. This makes webapppp projects
| greatly cheaper and simpler to finance and support as you
| can simply bother about developing and maintaining your
| SPA.
|
| Lastly, those JavaScript frameworks you're trying to
| criticize also use CSS and HTML, by the way. So as you may
| understand your point is moot.
|
| > Every web framework is _literally_ a hack to make the web
| something it isn't.
|
| You are clearly talking about things you have no
| understanding over. It matters nothing if you specify a DOM
| with a static file or procedurally. Updating only specific
| elements or branches of a DOM is a very basic usecases. In
| fact if you had any frontend experience at all you'd be
| aware that all mainstream GUI frameworks, including
| desktop, represent their UIs with a DOM.
|
| So here you are trying to argue that frontend development
| is not frontend development just because you have an
| irrational axe to grind regarding a specific class of web
| development technologies?
|
| > For thise JavaScript people, I recommend trying Laravel
| or Ruby/Rails.
|
| If you hadn't already proven you are completely ignorant
| and detached from reality, this argument alone would leave
| no room for doubt.
| tucnak wrote:
| Thanks for dissecting all this nonsense. Although in all
| honesty, we may as well be dealing with comedy here:
| green account, recommending PHP and Rails in 2025 as if
| that's supposed to solve anything... we're being trolled.
| anonymars wrote:
| Not the person you're replying to. I agree with a lot of
| what you are saying but:
|
| > The most basic reasons are performance (and perceived
| performance), not only because the require less data to
| be moved around the internet but also every flow doesn't
| require full page reloads.
|
| I can't keep a straight face at this one. If there's one
| thing the web _isn 't_ anymore, it's "fast." Presumably
| what you are getting at is _server_ performance, because
| it 's pushing all the work to the client.
|
| Anyway there's a good talk on this -
| https://veryinteractive.net/pdfs/ceglowski-
| thewebsiteobesity...
|
| > > Every web framework is _literally_ a hack to make the
| web something it isn't.
|
| > You are clearly talking about things you have no
| understanding over. It matters nothing if you specify a
| DOM with a static file or procedural
|
| Don't be so dismissive. This is like the old anecdote
| about one fish saying to the other, "how's the water."
| The "something it isn't" is _stateful._ The web was not
| designed to be stateful, and every web framework is
| indeed a hack to work around that.
| ahartmetz wrote:
| > all mainstream GUI frameworks, including desktop,
| represent their UIs with a DOM.
|
| If you call every hierarchy of visual items with some
| kind of layout manager(s) a DOM, then yes. Notably, the D
| doesn't really apply because GUIs aren't documents, and
| that's exactly why HTML is kind of awkward for GUI
| programming: it was initially designed for documents.
|
| Edit: Sibling comment makes the good point that the main
| difference is that GUIs have mutable state while
| documents don't. I would add that GUIs also have controls
| to change that mutable state, which is a more superficial
| difference, but well, web-based GUIs are still extremely
| varied in their interaction styles, which not necessarily
| good.
| weego wrote:
| _Every web framework is _literally_ a hack to make the web
| something it isn't_
|
| This sentence is doing an awful lot of heavy lifting that
| doesn't fit with reality
| cjonas wrote:
| Ya this is nonsense. The web is what it is.
|
| You could maybe say "every framework is a hack to
| workaround protocols primarily designed in the 90's
| before we really understood the full application of the
| web"
| goatlover wrote:
| The internet isn't the web, and there are plenty of
| applications who use those protocols just fine outside of
| the web browser. It's the html tech stack initially made
| for hypertext documents and resources that's been heavily
| upgraded to do web-based applications.
| m_fayer wrote:
| I would go as far as saying that the genius of the web is
| that it can grow, develop, be hacked, modified, expanded
| through technical and institutional means to be many
| things it wasn't originally envisioned to be. Why is that
| a bad thing? Why is originalism a good thing?
| tossandthrow wrote:
| > Every web framework is _literally_ a hack to make the web
| something it isn't.
|
| Not this old grumpy person take again.
|
| Yes, the web is developing beyond delivering html content.
| j0rd72 wrote:
| I find myself agreeing with the article (although I also
| agree that it assumes you've chosen an SPA when you shouldn't
| have). To add my own perspective:
|
| I work on an app, the front-end of which essentially consists
| of 6 nav tabs, 3 of which show an index of records with
| corresponding add/edit forms. We don't have any hyper-fancy
| interactive components that would require heavy JS libraries.
| And yet... we develop in React.
|
| Yesterday, I needed to add 1 new field (representing by a
| checkbox input) to both our app and a corresponding back-end
| application we have, which uses Rails views.
|
| I checked the git logs after to see how long each took. The
| Rails view took me literally 2 minutes to update (add field
| to model, add field to controller, add input to HAML with a
| class on the parent div). The React view took me 52 minutes,
| plus I later found out that I'd forgotten a damn type on some
| interface that's a shallow copy of our model.
|
| Is this a problem with React itself? Not really. But it's a
| problem in the way that it's used, and our 6 nav tabs and 3
| forms don't need all the overhead of React. So for people in
| a similar situation, this article really rings true.
| wredcoll wrote:
| People absolutely use technologies poorly and make things
| harder than they should be.
|
| At the same time, the part of the program that interfaces
| with the physical world (e.g., people) is always going to
| be far more complex and thus harder than the bits that get
| to live entirely inside the computer world.
| thefreeman wrote:
| Just because you are comfortable with one technology and
| inexperienced or unfamiliar with another does not make one
| better than the other. How much rails have you written in
| your career? How much react?
| dinfinity wrote:
| > Is this a problem with React itself?
|
| React is far from the best tool for most jobs (if any), but
| it has a shitload of inertia.
|
| I can highly recommend looking into Lit (used to be
| Polymer): https://lit.dev/docs/
|
| IMHO it allows just the right amount of encapsulation and
| structure, whilst building on W3C web components and being
| highly interoperable with other javascript
| libraries/vanilla code. It's pretty much what web
| components should be out of the box.
| cnasc wrote:
| > We don't have any hyper-fancy interactive components that
| would require heavy JS libraries. And yet... we develop in
| React.
|
| Is React really a "heavy" library?
| https://bundlephobia.com/package/react@19.1.0
|
| > The React view took me 52 minutes, plus I later found out
| that I'd forgotten a damn type on some interface that's a
| shallow copy of our model.
|
| This sounds like bad architecture, nothing about React
| would necessitate this. And if your typechecker isn't
| catching missing types, then it sounds like your types
| aren't adding much value.
| sensanaty wrote:
| I'm sorry but that just sounds like a tooling and skill
| issue? Adding a new form field takes me a grand total of 5
| minutes in the Vue app I maintain at work, and I'm a mostly
| backend focused fullstacker. We have the form/input
| components, adding a new field to a type is trivial (and we
| generate those automatically based on our BE schema
| anyway), error handling is handled by our form/input
| components.
|
| Also, I'm not the biggest fan of React and think there are
| options that are a million times better like Vue & Svelte,
| but React is _not_ heavy. Yes, JS frontends pull in a lot
| of libraries, but React (or any other framework except for
| probably Angular and Ember) is far from being the biggest
| or heaviest dependency in any project. In fact, especially
| React does this _amazingly_ , React itself has 0 external
| dependencies. Usually people will also want react-dom, so
| for the _simplest_ possible application, that 's a grand
| total of 2 very lightweight dependencies, and for usecases
| like yours of a few forms, that's literally all you'd need.
|
| Sure, maybe your 3 forms don't need React, but it sounds
| like you're actively adding stuff to it (and even caught a
| type issue from the sound of it). The non React version of
| this work would've entailed targeting a querySelector's
| inner `.value` key, and then having to parse it if it's not
| a simple string and safe guard against the element not
| being there, or targeting a shifting ID or class or all the
| other numerous and tedious problems that arise. Or, you
| stick a `v-model` on it, send it as JSON and call it a day,
| I categorically refuse to pretend the old universe pre-SPA
| frameworks was in any way a good way of working.
| psychoslave wrote:
| That is considering that front end dev is necessarily
| implying js, which is exactly the erroneous premise one
| should try to dodge.
| wredcoll wrote:
| > Non-JS developers mystified and irritated at a bunch of
| practices they've never really internalised
|
| My current explanation goes something like this:
|
| "I'm a smart guy. Front end development looks simple. If I
| find it hard to do, that must be the fault of javascript
| somehow"
| abustamam wrote:
| I started my career in FE and still consider myself a FE
| dev despite technically being a full stack dev.
|
| Sometimes I'd be working with my team on something and
| they'd be like "why is this needed?" and I'm like "because
| javascript" or "because react."
|
| While I agree with your sentiment that FE dev is certainly
| not simple, JS and front end architecture ad a whole does
| have its faults. That's why highly skilled FE devs who can
| build scalable, beautiful FE apps (whether using SPA or
| SSR) can be highly paid.
| dataflow wrote:
| Note those are not mutually exclusive. It's entirely
| coherent to believe you find a tool hard to use for reasons
| relating to the tool itself, and that the task you're
| trying to accomplish is _also_ difficult independently of
| that.
|
| Analogy: imagine trying to give a good presentation with a
| horrible text-to-speech (or translation) system. Just
| because good presentations are hard that doesn't mean you
| don't get to complain about the program being terrible.
| wredcoll wrote:
| Yes, but now you're getting into "there are two types of
| languages, the ones people complain about and the ones
| nobody uses".
|
| There are obviously flaws and issues and annoyances in js
| world, but a lot of those come from having to solve much
| harder problems (compared to say, do a sql query and turn
| the results into json).
| vanviegen wrote:
| I'll bite. In essence a user interface just presents the
| data it got from the server in some nice looking shape,
| and sends any edits and button presses back. Should be
| simple, right?
| wredcoll wrote:
| The "Just" is doing a lot of heavy lifting there.
|
| Think about the presenting data part of it. Perhaps you
| have a table of data, prices of tickets or some such. You
| could literally just wrap each item in a <td> tag and
| each row in a <tr> tag and that would indeed be easy.
|
| But people generally want and expect more. How about
| color coding the rows to make them easier to scan left to
| right or sorting the table by each column or paginating
| through more data than can easily displayed on one screen
| or maybe you're doing "infinite scroll" instead.
|
| None of these things are impossible of course, and people
| have done them so many times and in so many different
| ways that there are dozens of libraries you can use and
| hundreds of tutorials, but even so, compare that to the
| "select from table turn to json" equivalent.
|
| The SQL can be more than a bit tricky, but aside from
| that, JSON is extremely well defined and specified, even
| without a library you can just read the specs and do it.
| Wrapping it in a HTTP response and returning it and so on
| is likewise very well specified and if you can read, you
| can follow the instructions on how to do it.
|
| Creating a UI that works the way a user wants to is the
| opposite of all that.
|
| Of course, one of the major differences here is that at
| any point you can just stop improving the UI. Maybe you
| stop after wrapping it in the table html. The UI will
| certainly work, for a very specific definition of work.
| JSON is considerably more boolean. It either is a valid
| JSON document or it isn't. You can ask a computer to
| check for you. You can't ask a computer to check if your
| users enjoy using your table.
| hasanhaja wrote:
| How does something like React help with any of the
| trickier UX problems you're describing?
| benreesman wrote:
| I don't know that there's "real" programming, that seems like
| a hard fight to fight on either side, it's like arguing about
| whether animals are conscious or something. Are people? Who
| knows, pass the blunt.
|
| But there's been this really sharp over-correction to where
| now an obvious thing that is just common knowledge and that
| was never taboo is now considered impolite to even allude to.
| Frontend programming is among the easier kinds of software
| work as measured by the number of people who can do it? I bet
| if I tried really hard, I could probably be pretty kickass at
| pickleball, small court, not a lot moving around. But to be
| like, that's the same thing as the NFL. No, no it's not. I
| would never have been able to try out for the NFL, not if I
| live a thousand times.
|
| There's pickleball and pro football in programming too.
| christophilus wrote:
| > as measured by the number of people who can do it
|
| That's a poor measure. It proves only that there's a demand
| for such programming. I have programmed in tens of
| languages professionally and many more for fun.
|
| Programming is programming. I haven't found much difference
| in difficulty between any of the stacks I've worked with.
| Except, maybe C++, but that's just C++ being garbage. I now
| happily use Zig as an alternative, and it's no more
| difficult-- easier in fact-- than building a well-
| architected, complex UI application of any kind.
| suzzer99 wrote:
| Front-end programming is _easier_ in the sense that you can
| make little mistakes and your entire app doesn 't fall
| down. As someone who's done decades of both, there's
| nothing conceptually easier about well-executed front-end
| programming over back-end. The stakes just aren't as high.
| gmadsen wrote:
| I think the argument might be that it takes less domain
| knowledge of hardware and all its abstractions, which
| does require a minimum threshold of reasoning and
| abstract thinking ability. I have high confidence someone
| who could built a database or kernel could also do front
| end work with a reasonable ramp up time.
|
| I don't share that confidence for the inverse in the
| nominal case
| kylebyte wrote:
| The backend has plenty of complexities, but frontend
| developers have to deal with something just as complex -
| the user.
|
| Given ramp up time, most backend engineers could build a
| bad frontend, or build a good one if they have a really
| good UX team that thought through everything and are just
| implementing their work.
|
| In the real world though where UX is understaffed and
| often focused on the wrong problems - I've had to rescue
| too many frontends built by backend focused teams to
| share your confidence.
| cjblomqvist wrote:
| I have seen many backend developers with this mindset and
| approach, and; 1) Tricky parts of frontend are afaict
| equally tricky as building a DB/kernel/whatever. 2) A
| typical mistake is that a lack of knowledge about the
| hard parts of frontend makes backend'ers assume frontend
| is easy, while in reality it's their ignorance (and
| arrogance) rather than the subject being the issue 3) As
| with backend, most developers don't deal with the harder
| parts. Most backend developers I've talked to do simple
| CRUDing + minor business logic from a DB. Similarly very
| few developers try to write their own drag and drop
| library from scratch.
|
| It's sad that so many seems to fall into the trap of 2).
|
| (I've done both types of development for 20+ years)
| benreesman wrote:
| I have no idea what backend developer means to this or
| that person. It seems to mean "not frontend", so like,
| directly interacting with a database and possibly using a
| compiled or even unmanaged language? But still often
| deploying through something that looks like:
|
| Haswell <- Borg Hypervisor <- Borg Pod <- KVM Hypervisor
| <- QEMU guest <- docker-compose <- docker <- golang
|
| ?
|
| I'm talking about hackers. I remember being like 24 and
| and a colleague of mine (legend) had never worked in
| JavaScript or really the web before was on our pod that
| got tasked with writing a browser for J2ME and BREW that
| implemented real web pages.
|
| He goes home that weekend, and he comes back on Monday
| with a stack machine written in JavaScript (ECMA-262, we
| ran it on Rhino back then because Spidermonkey was a
| whole thing) that executed a very cute subset of
| JavaScript, including lambda closure and therefore Church
| encoding / untyped System 1. I was like whoa, why _in_
| JS? "If I have to implement it in a month, I'm already
| two months late to start learning it."
|
| Is that guy a frontend developer? Backend? Full Stack? He
| had worked on DSPs and audio before, and on video codecs
| and embedded.
|
| My comment above about some of this stuff is harder isn't
| a diss to anyone, it doesn't make me a millimeter shorter
| that Carmack is so tall, walking around in some rarefied
| air of genius I can't even formulate a picture of: it
| inspires me to work harder, try more ambitious things,
| push every day a little past yesterday's limit, and it
| has for more than 30 years now.
|
| There's nothing wrong with programming be a job, it's a
| perfectly reasonable life choice and a very sensible one
| in light of life's other demands and opportunities. But
| some of us fucking love it, think about it all the time,
| live to be good at it. That's a different set of
| outcomes. And it does grate a bit to have everyone
| pushing this "it's all the same, we're all the same, it's
| one equivalent thing", that's my passion you're talking
| about, I take great pride in my life's singular ambition
| and pursuit. We're equal but we're not the same.
| suzzer99 wrote:
| It's also that you're at the top of the stack. If your
| stuff breaks, there's no layer above you whose stuff also
| breaks.
|
| Well except the end user, but depending on the app they
| can often be low-priority (internal apps, apps with
| captive audiences like online banking or airline
| websites, etc.).
| bigbuppo wrote:
| Most frontend development shouldn't be necessary as they're
| writing repetitive code that implements features that are
| missing from browsers. And it shouldn't be that hard to add
| those missing features to browsers. They're like half
| javascript at this point...
| reactordev wrote:
| I don't know, I think reducing bundle sizes and bloated
| javascript in favor of built in support for view transitions
| warranted a blog post against one of the primary arguments
| for why SPA.
|
| I agree with the author. I love React. I shouldn't need two
| dozen more dependencies. We ditched server side for client
| side in 2010 for speed. Now that we have 200x more compute
| power, more powerful CSS, more robust html (with web
| components), we can go back to server side rendering and only
| send what's required for the user at the time of action.
| mdavidn wrote:
| Some of us have been building web apps since before Node.js
| existed, and we remember the problem that CSS was invented to
| solve.
| hasanhaja wrote:
| Are we aligned with the claims in the article that a SPA
| architecture is not a suitable baseline architecture for
| content-focused sites with shallow sessions (low number of
| interactions)?
| twelve40 wrote:
| > When it is worth the pain to load a large bundle in exchange
| for having really small network requests after the load
|
| ...and yet, i keep running into web (and even mobile apps) that
| load the bundle, and subsequent navigation is just as slow, or
| _even slower_. Many banking websites, checking T-Mobile
| balance... you wait for the bundle to load on their super-slow
| website, ok, React, Angular, hundreds of megs, whatever. Click
| then to check the balance, just one number pulled in as tiny
| JSON, right? No, the website starts flashing another skeleton
| forever, why? You could say, no _true_ SPA that is _properly_
| built would do that, but I run into this daily, many websites
| and apps made by companies with thousands of developers each.
| jazzypants wrote:
| Yeah, I see a lot of poorly written back-end APIs too.
| layer8 wrote:
| > 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.
|
| Why would the browser have to reload the code (JS files) on
| every page transition, with proper caching headers?
| jazzypants wrote:
| Click on a link on Amazon and take notice of all the kb of
| data in the head of every document that doesn't get cached.
| layer8 wrote:
| But you were talking about code, not data, hence my
| question. Also, Amazon doesn't need to be that way (and
| wasn't twenty years ago, the motivating period we are
| talking about).
| camillomiller wrote:
| Not sure what kind of clients you work with, but in my
| experience this is actually accurate and you won't believe how
| many times I had to put my hands and fix SPAs that should have
| been a static website to begin with. I think this is a
| consequence of a generation of webdevs, especially front-end,
| that graduated from bootcamps teaching them only JS frameworks
| and React as if that's the only way the Web works. They were
| given a hammer, told how to use it, and everything then just
| looks like a nail.
| tomhallett wrote:
| Depends on the definition of SPA, but in the days of jquery, I
| hardly consider any of that single page app. For example, the
| server rendered page had most of the html initial rendered,
| jquery would attach a bunch of listeners, and then on an update
| it incrementally. If lucky, we had a duplicated x-template-
| mustache tag which had a logic-less template that we could use
| to update parts. Jquery and duplication was the "problem" which
| drove everyone to SPAs.
| matwood wrote:
| A SPA also makes it much easier to package your site into an
| app that you can put on the stores.
| 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.
| revskill wrote:
| i hate it.
| dickersnoodle wrote:
| Less is more, usually.
| 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.
| nfw2 wrote:
| The article's title is it's time to kill SPAs
| epolanski wrote:
| No one said SPAs have no place, but 99% of websites out there
| don't need to be one.
| zarzavat wrote:
| 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.
| wordofx wrote:
| So you describe the 1%? Is this to refute the person you're
| replying to?
| nfw2 wrote:
| Where is 1% coming from? None of the software jobs I've
| worked at or even interviewed to work could have
| functioned as a website
| epolanski wrote:
| Can you link those?
|
| Because I mostly built backoffices, chats, forums,
| ecommerces, all things that would've worked better as
| websites.
| zarzavat wrote:
| 1% of domains perhaps, not 1% of developers.
| nfw2 wrote:
| What does it's time to kill SPAs mean to you other than they
| have no place.
| 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 CRA. 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.
| threatofrain wrote:
| We're living in the same universe. When you read the
| documentation you see something. I'm just giving the
| story behind it.
|
| You don't need generic answers about people wanking each
| other off for "think affiliates".
| ivape wrote:
| We are absolutely not living in the same universe. Please
| don't insult me. As a self-respecting developer, I do not
| understand the word "celebrity".
| frollogaston wrote:
| said celebrity is an AI-generated Peter Griffin
| 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.
| bryanrasmussen wrote:
| > I can't understand why anyone would become emotionally
| invested in any of them.
|
| sure, but I suppose you can observe that they do? And
| hence
|
| >Wars, battles, personalities on social media
|
| become reasonable narratives to engage in to describe
| what is actually happening in the social activities that
| form around these tools
| luckylion wrote:
| > I can't understand why anyone would become emotionally
| invested in any of them.
|
| I think that's simple: because they are financially
| invested in them. That's obvious for the developers
| working on the frameworks themselves or building
| libraries / plugins / UI-themes for them, but I believe
| it's also correct for "normal" developers who build
| things with these frameworks.
|
| They know these frameworks and can use them, and they've
| made an investment in time to get to that point. Likely
| they're also making at least some of their money
| _because_ they know these frameworks. Emotional
| attachment follows the economic attachment, and then
| you'll get plenty of rationalizations.
| frollogaston wrote:
| Kinda is a war unless you're working solo, cause you're gonna
| get forced to use something or another. When I tried a few
| solo web projects instead of just being a backend guy, I
| picked up React on my own because it was the only thing that
| makes sense. The page does what the code says. And that was
| after trying other things.
|
| Now I gotta occasionally use Angular, and it's boilerplate
| hell. Adding one button involves editing 30 classes and files
| even if you don't use templates. I took a course at work
| where even the instructor got confused adding a button. Why
| would anyone ever use this besides Google, or do they even
| use it?
| Tokumei-no-hito wrote:
| in the world of frameworks it's obvious that
|
| html in your JS > JS in your html.
|
| angular is a mess. it's the java of web frameworks. if you
| want up be enterprise(tm) go for it. I'm convinced it's
| only a thing because it gives people job security since
| nobody else chooses to touch it.
| frollogaston wrote:
| There was also the actual Java of web frameworks, GWT
| brulard wrote:
| How did next win the React framework war? Is it not few years
| already that see exodus from next to remix/react router, and
| more recently to tanstack start etc. because of unnecessary
| complexity, difficulty to run next on anything but vercel,
| misguided API changes etc.?
|
| You mentioning facebook docs pointing to next, when they
| explicitly mention remix and other is quite misleading.
| threatofrain wrote:
| Well, you must know how to look at download stats, search
| metrics, GitHub activity, social media temperature, or job
| posts. I feel that seeing is believing with your own eyes is
| sufficient for anyone who wants to investigate the issue of
| whether there's any winner in popularity.
|
| To not be misleading I wouldn't have brought up the existence
| of remix lest people think Microsoft belongs in the same
| discussion as my software consultancy.
|
| To be clear I'm using Tanstack Start right now.
| brulard wrote:
| By your logic PHP and Java won the programming language
| war.
|
| And according to github stars, (which may be considered
| rough measure of overall usage, not of current trend)
| next.js has 4x more than remix. So if your sw consultancy
| is one fourth size of Microsoft, you are close to a
| trillion dollar business. Even if you exagerrated by few
| orders of magnitude, thats still very big achievement, so
| congrats.
| threatofrain wrote:
| https://npmtrends.com/next-vs-nuxt-vs-remix
|
| Also look at trajectory. Oh my, don't you think?
|
| When I choose things like Tanstack Start, I am very clear
| that this is beta software and an early bet. When I'm
| talking about winners in the ecosystem, I am not going to
| bring up Tanstack and most definitely not Remix. I don't
| want to confuse people into thinking they belong on the
| same table of discussion for ecosystem winners.
| brulard wrote:
| Your information are outdated. Let me correct your chart
| a little https://npmtrends.com/next-vs-nuxt-vs-react-
| router-vs-remix
|
| Remix no longer exists as it was all migrated to react-
| router. react-router v7 is what remix v3 should have
| been.
| 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.
| racecar789 wrote:
| What does TFA stand for?
| 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.
| MentallyRetired wrote:
| 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 wrote:
| 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 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.
| mexicocitinluez wrote:
| 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 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.
| causal wrote:
| 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 wrote:
| 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)
| 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.
| sfn42 wrote:
| 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 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.
| wizzwizz4 wrote:
| What particular issues have you experienced?
| andrewstuart wrote:
| It's extremely hard to use reliably.
|
| Anyone enthusing about this API hasn't done much with it.
| martrapp wrote:
| 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 wrote:
| 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 wrote:
| I tried something here: 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 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.
| nfw2 wrote:
| 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 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 ?
| gerdesj wrote:
| "... 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| yeah, if it's not in firefox it doesn't count.
|
| https://bugzilla.mozilla.org/show_bug.cgi?id=1823896
|
| also mobile safari so basically all iphones.
| bornfreddy wrote:
| Basically it is supported just in Chromium & derivates then.
| Hard pass.
| mattvr wrote:
| It does appear to be supported by iOS Safari 18.2+, which is
| the majority of iOS users.
|
| https://caniuse.com/?search=view%20transitions
| ethan_smith wrote:
| 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 wrote:
| 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 wrote:
| The site feels so laggy on my mobile browser that I had to stop
| reading. Looks like CSS is not inherently performant.
| davidbanham wrote:
| 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 wrote:
| 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
| jfvinueza wrote:
| 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 wrote:
| 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 wrote:
| > _What counts as "SPA" and what's an "MPA"?_
|
| By how many times the Window's load event fire for your app.
| etchalon wrote:
| 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 wrote:
| Props for teaching me about View Transition API.
|
| Absolute disagree with the way you're arguing though.
| 867-5309 wrote:
| _Single-page Application_
| rezmason wrote:
| The author looks like Edward Norton.
|
| "I am Jack's native declarative transition."
| jmull wrote:
| 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 wrote:
| 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 wrote:
| 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
| wyuenho wrote:
| 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 wrote:
| i see "SPA" and my mind immediately reads that as "special
| purpose account" lol.
| fnord77 wrote:
| there's lots of SPAs that look like normal web pages. Twitter for
| instance.
| bpev wrote:
| 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 wrote:
| Can do all that without a SPA.
| bpev wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| "But they are better"
|
| By what measure?
| nfw2 wrote:
| Performance, developer experience, user experience
| donatj wrote:
| 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.
| unchar1 wrote:
| We did an A/B test of an old SPA app, and a modern re-
| write using SSR and server-rendered pages.
|
| By every performance metric, the new app was faster.
|
| But we kept getting user feedback that the new site was
| "clunky" and "slow", even though we saw that the p90 was
| much lower on the new site. Most of our users asked us to
| enable a toggle to let them go back to the old "fast"
| site.
|
| I'm not sure if this is a universal experience, but I
| think a lot of other sites that tried the CSR -> SSR move
| had similar experiences. It's just harder to talk about,
| since it goes against the usual narrative.
| bob1029 wrote:
| SSR can feel worse than SPA if you don't get the end-to-
| end latency under a certain threshold. If your SSR pages
| are taking upward of 100ms to render on average, it's
| going to start to feel like shit once you factor in the
| network latency.
|
| My design goal for modern SSR pages is 500 microseconds
| render time on the server. A modern CPU can crank through
| several gigabytes of UTF8 text _per second_. There really
| isn 't any excuse from a technology perspective. SSR
| pages being perceived as clunky & slow boils down to a
| skill / people / organizational problem. The computers
| and associated networks can definitely do it well.
| nfw2 wrote:
| Every single action should have no perceivable latency
| between the action and the feedback that the action was
| received. You can implement that with SSR but it is
| clunky and also requires a lot of JS generally.
| romanovcode wrote:
| Developer experience - Yes, in most cases.
|
| Performance - No, in most cases.
|
| User experience - No, in most cases.
|
| What are you talking about. Majority of SPAs have abysmal
| performance compared to regular HTML rendered websites and
| that reflects poorly on user experiences.
| elktown wrote:
| > Developer experience - Yes, in most cases.
|
| I think if people remembered how productive you could be
| before the SPA frontend/backend split they'd reconsider.
| Being able to take a feature from A to Z without either
| context-switching between ecosystems or, even worse,
| involving other people, was incredibly productive and
| satisfying. Not to mention a much more streamlined dev
| env without a bloated js ecosystem of bundlers/compilers
| and whatnot.
| christophilus wrote:
| I write an SPA for my day job. I write Postgres queries
| myself. I create endpoints and background workers and
| cron jobs myself, and I build out the UI myself. It's all
| typescript with static types end-to-end. It's a fantastic
| developer experience. Much, much better than I ever had
| in Rails or ASP.NET.
|
| Also, I love components for UI as opposed to templates.
| And I don't think I could ever really go back to the way
| I did things in my MPA days.
| elktown wrote:
| If there's no clear backend/frontend split wrt to
| language and roles in your particular project my point
| doesn't really apply for you. But it seems that you're
| lucky that you can use js on the backend to get closer to
| that. I would still prefer to not have to do a SPA unless
| obviously required for the job, but at least you got some
| of the fundamentals in place to be individually
| productive.
| nfw2 wrote:
| Performance - For pages that have different content for
| every user, the best performance will be reached by
| caching the app code on the client, only loading the data
| needed to render, and rendering once on the client.
| Rendering on an aws machine that is weaker than my 15
| year old macbook is not a recipe for good performance.
|
| User Experience - Every single user action should have no
| perceptible latency between the action and the feedback
| that that the action was received. This can't be done
| gracefully without javascript. Moreover, SPAs enable a
| better ux by enabling developers to build complex
| features that wouldn't be possible on traditional
| webpage.
| calrain wrote:
| I like how client side state is managed in a SPA more than an MPA
| martinald wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| sidcool wrote:
| Good article. But could have shown some examples.
| bstar77 wrote:
| This guys is really on a mission. Is there really a war against
| SPAs? Well designed SPAs can be incredible.
| rustystump wrote:
| 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 wrote:
| 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.
| oc1 wrote:
| 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 wrote:
| 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.
| positron26 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| They would have done the same thing with a MPA too though.
| pyman wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| might wanna consider redesigning your site, it looks like AI spam
| rhet0rica wrote:
| Yeah, it's really missing the charm you'd expect from a AI-free
| spam site. Maybe more flashing text?
| 65 wrote:
| 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.
| d--b wrote:
| Yeah... Let's see how less terrible those MPAs with CSS tricks
| are.
| np1810 wrote:
| 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/
| gabesullice wrote:
| 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.
| np1810 wrote:
| > PWA's killer features are circumventing the app store and
| the app store tax and not maintaining two codebases for
| Android and iOS.
|
| Agreed, I wish we lived in world where PWAs had atleast an
| equal share compared to mobile apps. Apps winning, mostly
| have been a suicide for privacy.
|
| Coincidentally, there's another HN story with even more
| relevance to our discussion. [1]
|
| [1]: https://news.ycombinator.com/item?id=44689059
| softwreoutthere wrote:
| "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 wrote:
| 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/ 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| Actually the static address bar and the refresh button
| behavior makes it obvious.
| tossandthrow wrote:
| 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?
| nromiun wrote:
| Because less than 1% of actual SPAs use those things.
| Hell, look at HN's search page in the bottom if you want
| an example. You can load entire HN by the time it loads
| up and searches something.
|
| Prefect example of the sufficiently advanced compiler
| argument.
| tossandthrow wrote:
| HN's search is hosted on Algolia, and is not a part of
| the HN "App".
|
| Hacker news is not a SPA.
|
| Algolia's search _is_ a SPA, but is perfectly utilizes
| the search so you can refresh a page (besides the error
| that they don 't use page-based search), and is largely
| indistinguishable from a non-SPA site.
|
| > You can load entire HN
|
| You obviously have not context what so ever on how much
| content is hosted on HN.
| nromiun wrote:
| Yes, I am well aware it is separate from HN. That is why
| I called it HN's search page.
|
| You underestimate how fast modern internet is. With MPA
| website like HN there is no need to wait for any script
| to render first.
| croes wrote:
| You think bad programming is restricted to SPAs?
|
| If they botch the back button in an SPA they will botch other
| things in an MPA
| nromiun wrote:
| But this bank's old MPA worked pretty well. By trying to
| modernize it they completely broke it instead.
| maccard wrote:
| I'd put big money on it not being the same team that made
| the new app.
| nromiun wrote:
| Probably. The old website was several decades old.
| maccard wrote:
| The toupee fallacy strikes again here. Gmail, slack[0], Netflix
| and Spotify are top tier examples - they actually work. Most
| are true garbage though.
|
| [0] I am firmly on the slack-performance-is-a-disgrace train,
| but their web client is a great example of a well done SPA -
| it's miles better than the app other than notifications.
| nromiun wrote:
| Gmail really? The same one that takes 10-20 seconds on 5G to
| even show the loading page? What is it doing in that time?
| Loading emails or downloading an AAA game? It is not just a
| one time penalty either, you reload and get the same loading
| page again.
|
| Just a few days ago I had to get an OTP via email and it was
| completely frustrating. No indication nothing, just a loading
| circle. The old MPA version was much better.
| kristopolous wrote:
| If it was built like we were in 1995, with tables and html
| 3.2 without JavaScript and just the old school inline
| attribute styles, it would be way more usable
| nromiun wrote:
| It is also possible to create fast and functional
| websites on modern tech. But for some reason some people
| go completely crazy with Javascript.
| jpc0 wrote:
| 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 wrote:
| 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 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.
|
| So they were better.
| aswerty wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Astro is a breath of fresh air in this space really.
| mrb wrote:
| SPA = single page app
| DrStartup wrote:
| is the author secretly the ceo of htmx?
| curtisblaine wrote:
| 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 wrote:
| 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 wrote:
| If this wasn't written by Claude then Claude was trained on the
| authors posts!
| rorylaitila wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| SPAs are good for making offline-available apps/sites. Not
| everyone has (or wants to have) an internet connection all the
| time.
| Alifatisk wrote:
| Speculation rules works the same as instant.page, by prefetching
| the url onhover. Right?
| larodi wrote:
| 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 wrote:
| 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 wrote:
| "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 wrote:
| 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 wrote:
| > 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.
| moribvndvs wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| I looked up the compatibility table: 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 wrote:
| Ie4 had these. It was pretty cool. I forget how they implemented
| it. Maybe active x?
| palmfacehn wrote:
| 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 wrote:
| 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 wrote:
| is this a growth hack article trying to get attention on SPA hate
| on HN?
| swyx wrote:
| 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.
___________________________________________________________________
(page generated 2025-07-26 23:02 UTC)