Live data from Hacker News

It's time for modern CSS to kill the SPA

jonoalderson.com

441–450 of 516 posts

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

#441

Earlier 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

It's also that you're at the top of the stack. If your stuff breaks, there's no layer above you whose stuff also breaks.

Well except the end user, but depending on the app they can often be low-priority (internal apps, apps with captive audiences like online banking or airline websites, etc.).

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

#442

Earlier quoted context omitted.

Thing is, and I believe it's a valuable example counterpoint, if I shift-click on a link, like sci-fi category, to open it in a new tab(very common thing people do), having a multi page application is zero work added, on an spa you have to manage that. If the link doesn't exist and categories can only be accessed by a select input then ux isn't that great

This is so annoying when SPAs break browser functionality like open link in new tab. Even if it works often it has to reload a bunch of JS again, which makes things veeery slow. This is why I really don't like Linear, I often open issues in separate tabs, which is every time a pain, browser freezes for seconds just to open a link in a tab...

I think it was not designed for your use case. It is conveniently running in the browser but not a collection of links to html pages. The people quarreling in this comment section seemingly ignore that life is complex, web browsers are complex, web development is complex. Maybe you should think about linear as a desktop app and call it a day :)

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

#443

Earlier quoted context omitted.

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?

The "Just" is doing a lot of heavy lifting there.

Think about the presenting data part of it. Perhaps you have a table of data, prices of tickets or some such. You could literally just wrap each item in a tag and each row in a tag and that would indeed be easy.

But people generally want and expect more. How about color coding the rows to make them easier to scan left to right or sorting the table by each column or paginating through more data than can easily displayed on one screen or maybe you're doing "infinite scroll" instead.

None of these things are impossible of course, and people have done them so many times and in so many different ways that there are dozens of libraries you can use and hundreds of tutorials, but even so, compare that to the "select from table turn to json" equivalent.

The SQL can be more than a bit tricky, but aside from that, JSON is extremely well defined and specified, even without a library you can just read the specs and do it. Wrapping it in a HTTP response and returning it and so on is likewise very well specified and if you can read, you can follow the instructions on how to do it.

Creating a UI that works the way a user wants to is the opposite of all that.

Of course, one of the major differences here is that at any point you can just stop improving the UI. Maybe you stop after wrapping it in the table html. The UI will certainly work, for a very specific definition of work. JSON is considerably more boolean. It either is a valid JSON document or it isn't. You can ask a computer to check for you. You can't ask a computer to check if your users enjoy using your table.

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

#444

Earlier quoted context omitted.

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?

[deleted]

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

#445

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…

Most frontend development shouldn't be necessary as they're writing repetitive code that implements features that are missing from browsers. And it shouldn't be that hard to add those missing features to browsers. They're like half javascript at this point...

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

#446
post #347

Earlier quoted context omitted.

Ya this is nonsense. The web is what it is. You could maybe say "every framework is a hack to workaround protocols primarily designed in the 90's before we really understood the full application of the web"

The internet isn't the web, and there are plenty of applications who use those protocols just fine outside of the web browser. It's the html tech stack initially made for hypertext documents and resources that's been heavily upgraded to do web-based applications.

[deleted]

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

#447

Earlier quoted context omitted.

How did next win the React framework war? Is it not few years already that see exodus from next to remix/react router, and more recently to tanstack start etc. because of unnecessary complexity, difficulty to run next on anything but vercel, misguided API changes etc.? You mentioning facebook docs pointing to next, when they explicitly mention remix and other is quite misleading.

Well, you must know how to look at download stats, search metrics, GitHub activity, social media temperature, or job posts. I feel that seeing is believing with your own eyes is sufficient for anyone who wants to investigate the issue of whether there’s any winner in popularity. To not be misleading I wouldn’t have brought up the existence of remix lest people think Microsoft belongs in the same discussion as my soft…

By your logic PHP and Java won the programming language war.

And according to github stars, (which may be considered rough measure of overall usage, not of current trend) next.js has 4x more than remix. So if your sw consultancy is one fourth size of Microsoft, you are close to a trillion dollar business. Even if you exagerrated by few orders of magnitude, thats still very big achievement, so congrats.

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

#448

Earlier quoted context omitted.

Well, you must know how to look at download stats, search metrics, GitHub activity, social media temperature, or job posts. I feel that seeing is believing with your own eyes is sufficient for anyone who wants to investigate the issue of whether there’s any winner in popularity. To not be misleading I wouldn’t have brought up the existence of remix lest people think Microsoft belongs in the same discussion as my soft…

By your logic PHP and Java won the programming language war. And according to github stars, (which may be considered rough measure of overall usage, not of current trend) next.js has 4x more than remix. So if your sw consultancy is one fourth size of Microsoft, you are close to a trillion dollar business. Even if you exagerrated by few orders of magnitude, thats still very big achievement, so congrats.

https://npmtrends.com/next-vs-nuxt-vs-remix

Also look at trajectory. Oh my, don't you think?

When I choose things like Tanstack Start, I am very clear that this is beta software and an early bet. When I'm talking about winners in the ecosystem, I am not going to bring up Tanstack and most definitely not Remix. I don't want to confuse people into thinking they belong on the same table of discussion for ecosystem winners.

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

#449

Earlier quoted context omitted.

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

I have no idea what backend developer means to this or that person. It seems to mean "not frontend", so like, directly interacting with a database and possibly using a compiled or even unmanaged language? But still often deploying through something that looks like:

Haswell ?

I'm talking about hackers. I remember being like 24 and and a colleague of mine (legend) had never worked in JavaScript or really the web before was on our pod that got tasked with writing a browser for J2ME and BREW that implemented real web pages.

He goes home that weekend, and he comes back on Monday with a stack machine written in JavaScript (ECMA-262, we ran it on Rhino back then because Spidermonkey was a whole thing) that executed a very cute subset of JavaScript, including lambda closure and therefore Church encoding / untyped System 1. I was like whoa, why in JS? "If I have to implement it in a month, I'm already two months late to start learning it."

Is that guy a frontend developer? Backend? Full Stack? He had worked on DSPs and audio before, and on video codecs and embedded.

My comment above about some of this stuff is harder isn't a diss to anyone, it doesn't make me a millimeter shorter that Carmack is so tall, walking around in some rarefied air of genius I can't even formulate a picture of: it inspires me to work harder, try more ambitious things, push every day a little past yesterday's limit, and it has for more than 30 years now.

There's nothing wrong with programming be a job, it's a perfectly reasonable life choice and a very sensible one in light of life's other demands and opportunities. But some of us fucking love it, think about it all the time, live to be good at it. That's a different set of outcomes. And it does grate a bit to have everyone pushing this "it's all the same, we're all the same, it's one equivalent thing", that's my passion you're talking about, I take great pride in my life's singular ambition and pursuit. We're equal but we're not the same.

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

#450

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…

A SPA also makes it much easier to package your site into an app that you can put on the stores.
Post reply on HN