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

491–500 of 516 posts

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

#491

Post by cosmotic »

scott_w wrote: post #222
cosmotic wrote: post #191

Earlier quoted context omitted.

Google maps is a mess these days. Its glitchy, slow, has broken navigation, and is overloaded with unpredictable dynamic content. It's even worse in the native android app. Id totally go for the original version but with the more recent vector maps.

The reasons it sucks are nothing to do with it being an SPA, though.

Being an SPA is certainly the cause of the glitchyness and slowness as complex content dynamically loads and shifts around. It's also certainly the cause of the broken navigation, just like the original article explains.

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

#492

Post by gizzlon »

markbao wrote: post #57

The point of SPAs was never page transitions. I can’t name a single major SPA that does good page transitions, can you? They all just replace the content. And to take a popular SPA framework as an example, it’s almost impossible to do page transitions in Next.js because of the way routes are loaded. I know this because I added proper page transitions to Next.js and it has been an absolute nightmare. There are two goo…

> Basecamp has probably invested the most in making a fairly complex webapp without going full SPA, but click around for like 30 seconds and you’ll see it can’t hold a candle in performance to SPAs

Really? I just started using it, and it feels fast. Most SPA's are slow and/or buggy (in the "fails to mimic real browser behaviour" kind of way)

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

#493

Post by gizzlon »

nfw2 wrote: post #456
bob1029 wrote: post #374

Earlier quoted context omitted.

SSR can feel worse than SPA if you don't get the end-to-end latency under a certain threshold. If your SSR pages are taking upward of 100ms to render on average, it's going to start to feel like shit once you factor in the network latency. My design goal for modern SSR pages is 500 microseconds render time on the server. A modern CPU can crank through several gigabytes of UTF8 text per second . There really isn't any…

Every single action should have no perceivable latency between the action and the feedback that the action was received. You can implement that with SSR but it is clunky and also requires a lot of JS generally.

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

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

#494

Post by epolanski »

nfw2 wrote: post #464
epolanski wrote: post #289

Earlier quoted context omitted.

Can you link those? Because I mostly built backoffices, chats, forums, ecommerces, all things that would've worked better as websites.

Here are some of the things I've worked on: - payroll and other hr software - educational software - shared workspace for realtors and homebuyers I'm not going to doxx myself by naming all the companies, but here is an example of a page that has too many features to work as a website. https://www.compass.com/listing/7310-estrella-de-mar-road-un...

You've got to be kidding me, I think you're conflating SPAs with websites that provide advanced interactivity.

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

#495

Post by scott_w »

cosmotic wrote: post #491
scott_w wrote: post #222

Earlier quoted context omitted.

The reasons it sucks are nothing to do with it being an SPA, though.

Being an SPA is certainly the cause of the glitchyness and slowness as complex content dynamically loads and shifts around. It's also certainly the cause of the broken navigation, just like the original article explains.

> Being an SPA is certainly the cause of the glitchyness and slowness as complex content dynamically loads and shifts around.

Incorrect.

> It's also certainly the cause of the broken navigation, just like the original article explains.

Also incorrect.

The Google Maps app is also total garbage. It’s not an SPA, so that’s clearly not the cause.

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

#496

Post by 8n4vidtmkvmk »

hasanhaja wrote: post #469
8n4vidtmkvmk wrote: post #459

Earlier quoted context omitted.

For first load, yes. The idea is that you never have to send the template again after that. Cascading is a separate problem. You can bundle all the data into a single request if you want. You can even send JSON along with the HTML in the first request.

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?

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

#497

Post by [deleted] »

gizzlon wrote: post #493
nfw2 wrote: post #456

Earlier quoted context omitted.

Every single action should have no perceivable latency between the action and the feedback that the action was received. You can implement that with SSR but it is clunky and also requires a lot of JS generally.

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

[deleted]

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

#498

Post by nfw2 »

gizzlon wrote: post #493
nfw2 wrote: post #456

Earlier quoted context omitted.

Every single action should have no perceivable latency between the action and the feedback that the action was received. You can implement that with SSR but it is clunky and also requires a lot of JS generally.

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

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

#499

Post by nfw2 »

unchar1 wrote: post #267
donatj wrote: post #234

Earlier quoted context omitted.

I'm sorry but what!? Have you talked to your users? The ones that actually are forced to use your app day in and out? They want functional back buttons, they want to be able to open any action in a new tab. No one who actually uses your product would prefer an SPA once the flash wears off. Let me tell you as a developer who has been on both sides of things, developing server rendered pages and not having to worry abo…

We did an A/B test of an old SPA app, and a modern re-write using SSR and server-rendered pages. By every performance metric, the new app was faster. But we kept getting user feedback that the new site was "clunky" and "slow", even though we saw that the p90 was much lower on the new site. Most of our users asked us to enable a toggle to let them go back to the old "fast" site. I'm not sure if this is a universal exp…

I am curious to identify what your users are perceiving that isn't be being captured by your metric. If it is accurate and not just rhetoric that MOST of your users are asking for a rollback for purely performance reasons, that is a very extreme outcome.

Are your p90 metrics testing:

- navigation after first load?

- users who are going to the app after it is cached on their browser?

Are your actions going through server actions or rest apis? Do you have metrics on those?

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

#500

Post by jongjong »

dannye wrote: post #262
jongjong wrote: post #126

Earlier quoted context omitted.

SPAs are nice when your app requires complex state; multiple rows of nested tabs, modals, multiple interlinked select inputs which load data dynamically, charts or graphs which can lazy-load data and update on the fly in response to user actions. There is a certain level of complexity beyond which you need to load data on the fly (instead of all up front on page load) and you literally cannot avoid an SPA. Choosing t…

> there are no weird rendering glitches or timing issues or weird gotchas that you have to dig into to. Ehm... define the Web Component render blocking in the head, because you want to prevent FOUCs. Then try to access the .innerHTML of your Web Component in the connectedCallback https://dev.to/dannyengelman/web-component-developers-do-not...

Interesting but I wouldn't call that a gotcha. Trying to read the DOM outside of the component is kind of an anti-pattern and I think this kind of behavior should be expected. You'd generally want the web component to be a black box and it works pretty well once you understand the rendering order and focus only on internal or slotted elements. I think the only real 'gotcha' I came across was the order of when the attribute changed callback gets called versus the connect callback but it's easy to adjust the logic internally to take this into account. I can make do with a custom render() method and sometimes additional methods to perform specific granular updates to the component's own DOM...

With React, the component either gets rendered or it doesn't get rendered; all or nothing and React fully controls this. With web components you can also just nit-pick a single element within the component's DOM and only update that one. It gives you more opportunities in terms of performance optimization and how you split up your components... But you can also achieve a similar result as React by just re-rendering the whole component if necessary.

The one difficulty which is actually an advantage IMO is that you cannot pass JavaScript object or function references to Web Components via HTML attributes; you have to pass primitive values... But IMO this a BENEFIT because it forces separation of concerns and it makes the DOM way easier to debug in the dev console. For advanced use cases you can still pass JS refs to a child component by calling methods on it but I try to avoid this because it makes it harder to understand the state of a component.

I like it when I can understand the state of a component just by looking at its attributes and I like those values to be as simple and human-readable as possible. I love opening up my dev console and just tweaking the HTML attributes directly and see the change happening. Makes debugging a breeze. Kind of tricky to do with React and you get into all sorts of weird situations where a render may not trigger when you expect when you change properties of an object without changing the reference itself. React adds a lot of unnecessary complexity there.

Post reply on HN