Live data from Hacker News

It's time for modern CSS to kill the SPA

jonoalderson.com

501–510 of 516 posts

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

#501
post #498

Earlier quoted context omitted.

> should have no perceivable latency between the action and the feedback that the action was received. Huh, according to who? I think a small delay is totally fine. Often better than the SPA's that tried to fix this non-problem and introduced much worse problems. Edit: For example HN: I press update and there's a small delay.. So what? Most sites and SPA's have a much worse user experience than this.

Because past delays of about 100ms, users lose the sensation of directly manipulating the page. The feel of a page is part of it's aesthetic. Also, immediate feedback reduces anxiety and mistakes (for example duplicate submissions). https://www.researchgate.net/publication/391230228_Cognitive... https://www.nngroup.com/articles/response-times-3-important-...

Looked at the first one, and that's in a game setting? And they test 600 ms??

edit: The second one is more useful IMO. It's hard to get under 100 ms with a roundtrip, but < 300 ms should be doable, right? So you do lose the sense that you are directly manipulating data. In most cases I think that's a good trade-off. Exceptions would be things like Google docs, but that's also because it's a well made app I trust to actually sync my data without loss. Unlike most SPAs..

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

#502

Earlier quoted context omitted.

Why does this have to be the baseline architecture when you can render the HTML on the server with the template and data? Why send the data and the JavaScript to parse that data and transform it into HTML in a users browser when you can do it on the server? For requests after the first, you can still continue to send the rendered HTML to be placed into the document. Here's an example using HTMX: https://htmx.org/exam…

If your app is simple enough, go ahead and do that. In nearly every app I've worked on, I eventually need some dynamic piece of content. Like even a date picker, so you really want to call the server every time the use wants to go to the next month?

Why on earth would you drive a date picker from the server? No one is saying to do that. JS is absolutely fine to build custom UI controls. The form the date picker renders in doesn't need to be 100% JS though.

Use JS to patch over things the browser doesn't implement and let it handle the rest.

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

#503

Earlier quoted context omitted.

If your app is simple enough, go ahead and do that. In nearly every app I've worked on, I eventually need some dynamic piece of content. Like even a date picker, so you really want to call the server every time the use wants to go to the next month?

Why on earth would you drive a date picker from the server? No one is saying to do that. JS is absolutely fine to build custom UI controls. The form the date picker renders in doesn't need to be 100% JS though. Use JS to patch over things the browser doesn't implement and let it handle the rest.

Ok, at least we agree on something. I think that's fine if your app is simple enough, but the more and more dynamic it gets, at a certain point, I think it makes sense to just render the whole darn thing in JS. At least for the DX.

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

#504
post #498

Earlier quoted context omitted.

Because past delays of about 100ms, users lose the sensation of directly manipulating the page. The feel of a page is part of it's aesthetic. Also, immediate feedback reduces anxiety and mistakes (for example duplicate submissions). https://www.researchgate.net/publication/391230228_Cognitive... https://www.nngroup.com/articles/response-times-3-important-...

Looked at the first one, and that's in a game setting? And they test 600 ms?? edit: The second one is more useful IMO. It's hard to get under 100 ms with a roundtrip, but < 300 ms should be doable, right? So you do lose the sense that you are directly manipulating data. In most cases I think that's a good trade-off. Exceptions would be things like Google docs, but that's also because it's a well made app I trust to a…

300ms for network latency both ways, with server potentially doing its own network calls for data to fulfill the request, interpolating the html, and then browser rerendering client seems like a stretch

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

#505

Earlier quoted context omitted.

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.

But even if you SSR them you still need to send at least 100KB (and probably far more) of JS down to the browser to hydrate state and handle any interactivity.

You need JS to handle interactivity no matter what. And 100KB is nothing, a single image is larger.

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

#506

Earlier quoted context omitted.

> When it is worth the pain to load a large bundle in exchange for having really small network requests after the load ...and yet, i keep running into web (and even mobile apps) that load the bundle, and subsequent navigation is just as slow, or _even slower_. Many banking websites, checking T-Mobile balance... you wait for the bundle to load on their super-slow website, ok, React, Angular, hundreds of megs, whatever…

Yeah, I see a lot of poorly written back-end APIs too.

backend has many traps but no one totally dominating "load the slow bundle once, near-native subsequent page loads" narrative which is (for whatever the reason!!) a non-existent illusion on most average daily websites.

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

#507
post #261

Earlier quoted context omitted.

This. The mental model of an API with a frontend deployed as static resources just happens to be very attractive. Even more so when the SPA isn't the only frontend, or when you don't know that the SPA will remain the only frontend forever. When you have an SPA sitting on top of an API, introducing new clients for feature subsets (e.g. something running on a Garmin watch) becomes trivial. If you have a huge org workin…

> introducing new clients for feature subsets (e.g. something running on a Garmin watch) becomes trivial. This never happens, for some values of never. When a SPA app is initially developed, the "client" and the "API" are moulded to each other, like a bespoke piece of couture tailored to an individual's figure. Hand-in-glove. A puddle in a depression. There is absolutely no way that some other category of platform ca…

That's absolutely not my experience from any of the SPAs I've worked on. If the API used by the SPA is so "specialised, single-purpose", then that isn't something inherent to SPAs, only inherent to developers (or architects) who are inexperienced or bad at their job.

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

#508

Earlier quoted context omitted.

Kinda is a war unless you're working solo, cause you're gonna get forced to use something or another. When I tried a few solo web projects instead of just being a backend guy, I picked up React on my own because it was the only thing that makes sense. The page does what the code says. And that was after trying other things. Now I gotta occasionally use Angular, and it's boilerplate hell. Adding one button involves ed…

in the world of frameworks it's obvious that html in your JS > JS in your html. angular is a mess. it's the java of web frameworks. if you want up be enterprise(tm) go for it. I’m convinced it's only a thing because it gives people job security since nobody else chooses to touch it.

I don't know what you guys are doing with your Angular buttons, or if you haven't looked at it since AngularJS (which I never used, so I don't know what it took there).

Adding a button to Angular is just adding a to your template. If you want to use Angular Material, that's one additional import in your component's code file, and one additional attribute for that template's element.

  import {MatButtonModule} from '@angular/material/button';

  Click me!
That's it. If your instructor got confused trying to achieve that, maybe that's why you were left with this weird impression of how verbose and complicated Angular is.

Just at least have a look at the documentation or tutorial before spreading fibs like that.

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

#509

I wonder if my slop radar is oversensitive to em dashes and the construction: “it’s not just about foo, it’s about bar ” because this post seems human written but the indicators are flashing

There are also many non sequiturs. The sentences only read fine if you don't think about what the author might be trying to say. I also think that this reads like the "author" was an LLM and, therefore, isn't trying to say anything.

À propos of nothing – I'm human and I like using special characters, including en dashes. ;)

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

#510

SPAs are not about view transitions. TFA implies that fancy transition is important between pages (wrong!) and blames a "CMO" or "brand manager" rather than challenging their own preconceptions and exploring the value an SPA does add: - excellent frameworks for client side logic (interactivity) - separation of concerns (presentation logic vs. backend) - improved DevEx => inc. speed of development => happiness for all…

What does TFA stand for?

Among others (e.g.: "trans fatty acid"), in this particular case either "today's featured article" or "the f**ing article". I guess the latter.
Post reply on HN