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

Your single-page app is now a polyfill

itnext.io

Post reply on HN
Print view View original

141–150 of 164 posts

Re: Your single-page app is now a polyfill

#141

Post by manigandham »

PinguTS wrote: post #21

Maybe I am missing the point. When the problem is speed and the solutions seems single page app with bloated javascript or the thing the poster suggest. Why isn't the solution just simple classical HTML without any bloated Javascript, which also needs to be executed. The CSS is cached, so it doesn't need to be reloaded and the next possible pages are prefetched via the correct META tags.

That is the best solution, just not trendy. Ironic since that's what HN uses and why it's so fast, and why all the SPA HN clones are terrible.

Re: Your single-page app is now a polyfill

#142

Post by nawgz »

manigandham wrote: post #139
nawgz wrote: post #127

Earlier quoted context omitted.

So your proposition is that instead of downloading a client bundle that knows all of these actions, my server: * renders a Table for me * my thin client injects that into the page * my onClick handlers for the Table are going to do what? Make an API call to the server so it can render the focused Graph section of the page now? Or is it supposed to hook gracefully into some client state that is a part of the aforement…

Anything that actually changes the data requires a server roundtrip. The point is that it's faster and simpler to just have the server render the entire HTML and replace that rather than making an API call with client-side JS rendering.

>Anything that actually changes the data requires a server roundtrip

I mean, of course, but clearly I've outlined a situation where you can easily prefetch some objects to have an instant user experience. These are plentiful.

Additionally, you enable responsiveness in other ways server rendering can't accomplish with an SPA. You can display loading status of async resources, you can optimistically display changes so the user can begin editing another piece of data without waiting for latency-bound UI, etc..

Finally, "simpler" is a hard sell. Simpler for who? Someone who is writing a simple HTML data table page? Yes. For someone who is building a collaborative graph editor? Give me a break.

This is my point this whole comment thread - the anti-SPA crowd here sometimes hates JS and browsers so much they are willing to completely sacrifice user performance inside application use-cases because they find the idea of an SPA unappealing. It's pretty absurd, facile really, to claim "it's faster AND simpler".

Re: Your single-page app is now a polyfill

#143

Post by manigandham »

nawgz wrote: post #142
manigandham wrote: post #139

Earlier quoted context omitted.

Anything that actually changes the data requires a server roundtrip. The point is that it's faster and simpler to just have the server render the entire HTML and replace that rather than making an API call with client-side JS rendering.

>Anything that actually changes the data requires a server roundtrip I mean, of course, but clearly I've outlined a situation where you can easily prefetch some objects to have an instant user experience. These are plentiful. Additionally, you enable responsiveness in other ways server rendering can't accomplish with an SPA. You can display loading status of async resources, you can optimistically display changes so…

Where's the prefetching? The table loads with the page. Loading it after with JS will only go slower.

> "server rendering can't accomplish with an SPA"

Again, you don't need a SPA to have some interactive DOM manipulation. Nobody is saying everything requires fresh HTML from the server, but something like jQuery Datatables will give you 99.99% of instant client features while working with server-rendered tables. htmx.js is another great library that solves most use-cases.

> "For someone who is building a collaborative graph editor?"

Obviously not, because that's one of the few times where a SPA is needed.

> "the anti-SPA crowd here sometimes hates JS and browsers so much"

What's with the extremes? Nobody is against SPAs or JS or browsers. In fact we want browsers to be used for what they do best, which is rendering URLs into pages very quickly. SPAs make a tradeoff in trying to emulate most of the browser performance and reliability in return for complex interactivity. The issue is that most sites don't need that interactivity, and what little they do need can easily be done with much less.

Re: Your single-page app is now a polyfill

#144

Post by dannymoerkerke »

chrismorgan wrote: post #12
PudgePacket wrote: post #5

With service workers disabled on firefox the site just breaks, no graceful degradation/progressive enhancement. When clicking links in the header the url will change, but the page content doesn't.

The trouble is trailing slashes and inconsistent behaviour between the service worker and the web server. https://instantmultipageapp.com/images/ loads from the server, and not the service worker. Observe how it lacks the Blog link in the header, which is missing in what the server is rendering—see /images/index.html in the repository. https://instantmultipageapp.com/images loads from the service worker, and the serv…

Thanks for reporting. There were some problems on the backend but this has now all been solved.

Re: Your single-page app is now a polyfill

#145

Post by dannymoerkerke »

Deukhoofd wrote: post #32
PudgePacket wrote: post #5

With service workers disabled on firefox the site just breaks, no graceful degradation/progressive enhancement. When clicking links in the header the url will change, but the page content doesn't.

Which in turn means that sites using this technique will not work in private browsing mode.

That is not correct. There were some issues on the backend but these have now been solved.

Re: Your single-page app is now a polyfill

#146

Post by the_gipsy »

cjstadler wrote: post #103
the_gipsy wrote: post #29

Earlier quoted context omitted.

Twitter's implementation just exploded on me the other day on my phone. Since then I cannot open ANY links to twitter anymore. I just get a page from the browser that says "Cannot complete request". It's on my phone so I can't just clear a single site's data, and I cannot be bothered to clear everything and relog everywhere.

Are you on Firefox? This resolved it for me: https://support.mozilla.org/en-US/kb/twitter-isnt-working-fi...

Yes but mobile.

Re: Your single-page app is now a polyfill

#147

Post by jiofih »

nawgz wrote: post #136
recursivedoubts wrote: post #134

Earlier quoted context omitted.

The primary advantage of SPAs is the increased interactivity of the UI. Instant navigation is nice, but that's an implementation detail: an SPA could just as easily lazily load that data, and must chew up memory on the client and then deal with synchronization complexity with the back end if it doesn't. It's a trade off, of course. SPAs are a reversion to the classic client-server setup, and there are advantages and…

I think my biggest complaint about what you've written here is that you just shunt these "complexities" you wield against SPA to the back-end and then gloss over them. I strongly disagree that "formatting database data into a JSON string is not significantly less CPU intensive than formatting it into an HTML string" - business logic is always the most expensive code to inject. This means you're either, again, not rea…

Nothing stops you from loading all of those graphs in the initial HTML payload if you want to, and then displaying them without a round trip to the server. These things are not exclusive, you don’t need to go all-in with a client-side framework to achieve basic interactivity (like tabs).

Re: Your single-page app is now a polyfill

#148

Post by dspillett »

pier25 wrote: post #63
dspillett wrote: post #38

Earlier quoted context omitted.

> Why would users expect that? People are impatient and expect everything on three computer to be as fast as the faster things on it. Anything slow can feel like there is something wrong. They don't expect things to be instant, but your page turning example is relevant: if losing a new page take the time of a physical page turn or two then it is probably fine and feels smooth. More than a few hundred ms and things fe…

> People are impatient and expect everything on three computer to be as fast as the faster things on it. Anything slow can feel like there is something wrong. True, but an SPA doesn't really solve that either. You still have to make a request to the API and wait for it just like you have to wait for some HTML. The only difference is with an SPA you can show a spinner to the user. Also, on an SPA, the initial hit of J…

An SPA, if properly designed, can help interactive use significantly though, compared to full page reloads. You may pay for the reduction in interactive latency with an upfront loading cost, but when comparing to desktop applications that is often not too bad anyway (Excel doesn't load immediately on most PCs, games of any modern design generally don't either). People are more willing to wait a second or few initially than they are to wait half a second when getting more data from an app that they consider to already be loaded.

The problem is that many are not properly designed. In fact often the patten is often used when it is not really appropriate and a fairly static site would (again with that caveat: if properly designed) be much more efficient and just as user-friendly.

Re: Your single-page app is now a polyfill

#149

Post by dr-detroit »

asddubs wrote: post #138
nexuist wrote: post #131

Earlier quoted context omitted.

Well, the idea is that you render the first pass of the SPA and serve that HTML to the client. Rather than just injecting the data into the SPA source code, you inject the data and render the page, and then serve that page. Then whatever changes the user makes to the page after that initial load gets handled by the SPA. This way the user avoids having to wait for the SPA and all its dependencies to load before the pa…

that's pretty neat, I didn't know that react could do that. Shame no one ever seems to make use of it

Because neat doesn't pay the bills. Why would I pay to dedicate computing resources to something that anyone's computer or phone can do in under 3 seconds which has scientifically been proven to be an acceptable wait time between click(tap) and render?

Re: Your single-page app is now a polyfill

#150

Post by scsilver »

onli wrote: post #97
scsilver wrote: post #93

Earlier quoted context omitted.

It will feel faster because it will use the users time between actions to do the needed roundtrip calls.

Sure, if you preload all your sites' content, which I'm sure the users on slow mobile internet with limited volume and those on weak mobile devices will just love. But I don't see that happening in the linked article nor on the demo page.

Its 2020 not 2012. The small round trip calls on 4g are much more annoying than one call of a few a mb of data, in my opinion.
Post reply on HN