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.
It's time for modern CSS to kill the SPA
431–440 of 516 posts
Re: It's time for modern CSS to kill the SPA
#432Earlier quoted context omitted.
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.
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
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.
Re: It's time for modern CSS to kill the SPA
#433It'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.
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.
Re: It's time for modern CSS to kill the SPA
#434Earlier 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…
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.
Re: It's time for modern CSS to kill the SPA
#435I 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 d…
[deleted]
Re: It's time for modern CSS to kill the SPA
#436Earlier 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 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 t…
[deleted]
Re: It's time for modern CSS to kill the SPA
#437Earlier quoted context omitted.
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.
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
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)
Re: It's time for modern CSS to kill the SPA
#438Earlier quoted context omitted.
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 complai…
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).
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?
Re: It's time for modern CSS to kill the SPA
#439SPA 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 sho…
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…
> 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.
Re: It's time for modern CSS to kill the SPA
#440SPAs 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…
Some of us have been building web apps since before Node.js existed, and we remember the problem that CSS was invented to solve.