Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

It's time for modern CSS to kill the SPA

jonoalderson.com

Post reply on HN
Print view View original

391–400 of 516 posts

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

#391

Post by recursivedoubts »

naet wrote: post #163
throwaway7783 wrote: post #18

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.

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

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

#392

Post by abustamam »

wredcoll wrote: post #376
zero_shift wrote: post #275

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…

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

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.

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

#393

Post by esskay »

zero_shift wrote: post #315
cleoxjefbjxis wrote: post #303

Earlier quoted context omitted.

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…

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

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

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

#394

Post by benreesman »

zero_shift wrote: post #275
codingdave wrote: post #14

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…

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.

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

#395

Post by tossandthrow »

40four wrote: post #210

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

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

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

#396

Post by dataflow »

wredcoll wrote: post #376
zero_shift wrote: post #275

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…

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

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.

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

#397

Post by esskay »

zwnow wrote: post #316
cleoxjefbjxis wrote: post #303

Earlier quoted context omitted.

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…

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

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.

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

#398

Post by cnasc »

j0rd72 wrote: post #359
zero_shift wrote: post #275

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…

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

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

#399

Post by christophilus »

benreesman wrote: post #394
zero_shift wrote: post #275

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

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

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

#400

Post by robertoandred »

martinald wrote: post #368
robertoandred wrote: post #169

Earlier quoted context omitted.

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.

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.

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.
Post reply on HN