Live data from Hacker News

It's time for modern CSS to kill the SPA

jonoalderson.com

381–390 of 516 posts

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

#381
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; }
    }
  }

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

#382
post #359

Earlier quoted context omitted.

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

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

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?

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

#383

Earlier quoted context omitted.

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

Gmail takes 3s to load. And HN is a website, not an app.

That's the discussion being had.

HN would've been considered an app if it was built as SPA

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

#384
post #144

Earlier quoted context omitted.

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

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

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).

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

#385
post #69

Earlier quoted context omitted.

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.

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".

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".

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

#386
post #163

Earlier quoted context omitted.

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.

HTMX does the opposite of this, it requires many more round trips to the server instead of using client side JS to do work.

Many more round trips to the server is okay - it is the server after all and it is easy to scale it.

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

#387

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

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

[dead]

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

#388
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.

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

#389
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"

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

#390
post #359

Earlier quoted context omitted.

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

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

> 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.

Post reply on HN