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

411–420 of 516 posts

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

#411

Post by nromiun »

kristopolous wrote: post #406
nromiun wrote: post #313

Earlier quoted context omitted.

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.

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

It is also possible to create fast and functional websites on modern tech. But for some reason some people go completely crazy with Javascript.

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

#412

Post by elktown »

christophilus wrote: post #404
elktown wrote: post #320

Earlier quoted context omitted.

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

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

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.

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

#413

Post by pyman »

maccard wrote: post #310
pyman wrote: post #294

Earlier quoted context omitted.

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.

They would have done the same thing with a MPA too though.

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.

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

#415

Post by suzzer99 »

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…

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.

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

#416

Post by girvo »

Capricorn2481 wrote: post #334
zero_shift wrote: post #315

Earlier quoted context omitted.

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…

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

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

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

#417

Post by chuckadams »

layer8 wrote: post #345
xyzsparetimexyz wrote: post #283

Earlier quoted context omitted.

How is HN not an app? All the content is user generated. Everything is interactive. What's the difference?

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.

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.

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

#418

Post by pyman »

docmars wrote: post #353
pyman wrote: post #285

Earlier quoted context omitted.

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…

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

I agree. There's a rich ecosystem for building SPAs with MACH architecture. There’s no going back now, not even for basic apps.

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

#419

Post by chuckadams »

aquariusDue wrote: post #255
naet wrote: post #163

Earlier quoted context omitted.

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

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.

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!

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

#420

Post by TacticalCoder »

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…

[dead]
Post reply on HN