@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; }
}
}It's time for modern CSS to kill the SPA
381–390 of 516 posts
Re: It's time for modern CSS to kill the SPA
#382Earlier 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…
Re: It's time for modern CSS to kill the SPA
#383Earlier 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.
HN would've been considered an app if it was built as SPA
Re: It's time for modern CSS to kill the SPA
#384Earlier 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…
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
#385Earlier 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".
Re: It's time for modern CSS to kill the SPA
#386Earlier 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.
Re: It's time for modern CSS to kill the SPA
#387SPAs 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…
Re: It's time for modern CSS to kill the SPA
#388Re: It's time for modern CSS to kill the SPA
#389Safari 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
#390Earlier 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…
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.