Your single-page app is now a polyfill • Hacker News Board

Re: Your single-page app is now a polyfill

#41

Post by nyanpasu64 » Thu, Oct 08, 2020, 8:51 AM UTC

fxtentacle wrote: post #17

I feel like the whole article misses the point. Yes, the rendering delay caused by a non-streaming HTML parser exists, but unless you screw things up elsewhere, that's going to be less than 1ms of delay. Yes, bloated frameworks are annoying, but not due to their computational overhead per se, but because they increase download size and because Javascript is slower then native code in general. I find it very telling t…

In single-page apps, navigating between pages is hard to get right. https://vector-of-bool.github.io/ implements its own JavaScript-powered page turning. However if you press End on a long page, then navigate to a short page and back to the long page, the browser's scroll position gets truncated.

In the "Instant Multi-Page App", navigating between pages "just works".

Re: Your single-page app is now a polyfill

#42

Post by kreetx » Thu, Oct 08, 2020, 9:06 AM UTC

mdoms wrote: post #11

Please. Please don't do this. Service workers cause so many problems, I have never seen an implementation that didn't completely explode at some time or another, and as far as I can tell the only fix is to open the dev tools and delete service workers. They're a bad solution to a non-problem.

The problem might be that it's just not well understood yet, it definitely has it's use cases.

That said, I recently tried Twitter's PWA and it went into an infinite page refresh loop right after login. So yeah, not easy to get it right.

Re: Your single-page app is now a polyfill

#43

Post by imtringued » Thu, Oct 08, 2020, 9:43 AM UTC

shusson wrote: post #33

milankragujevic wrote: post #28

Earlier quoted context omitted.

For me, SPA is either chosen due to "fancy factor" or because the app is too complex to easily implement as a traditional (SSR) web page. That could be a complex search+filter with autocomplete, or a social network-like UI with infinite scroll and dynamic widgets.

Yes in practice this is what I see as well. I would also add, "developer likes framework x tooling". The other use case that SPA frameworks sell, is develop for all platforms For web, mobile and desktop. It sounds nice on paper, but I have no experience with it.

That sounds about it. People use SPAs to make webapps that are as complicated as regular desktop or phone apps.

Re: Your single-page app is now a polyfill

#44

Post by imtringued » Thu, Oct 08, 2020, 9:46 AM UTC

cblconfederate wrote: post #34

the idea that the DOM based browser can be used as a GUI toolkit was wrong to begin with. It has been stretched to absurd proportions over the years. Maybe we need to go back to java applets?

I disagree. The only problem is that people insist to use it for desktop apps. Webapps are their own thing. They should stay in the browser instead of leaking and spilling everywhere.

Re: Your single-page app is now a polyfill

#45

Post by imtringued » Thu, Oct 08, 2020, 9:52 AM UTC

Udik wrote: post #14

> it all started with the desire to eliminate blank screens in between pages and reduce payload sizes Hell, no. The "two main reasons" for single page app given at the beginning (faster app, reduced network traffic) are actually not the main one. The main one is that the browser loses its state at each page reload, and that the state on the server, if any, needs to be reconciled every time with that on the browser. I…

>The main one is that the browser loses its state at each page reload, and that the state on the server, if any, needs to be reconciled every time with that on the browser.

Yes, I also noticed this flaw. There is no good way of dealing with this other than saving state into localStorage which is less than ideal.

Re: Your single-page app is now a polyfill

#46

Post by k4roshi » Thu, Oct 08, 2020, 10:21 AM UTC

Isn't this what turbolinks already does?

Re: Your single-page app is now a polyfill

#47

Post by blueblisters » Thu, Oct 08, 2020, 10:34 AM UTC

f311a wrote: post #35

> Blank screens make for a bad user-experience. Users don’t want to wait for content to arrive from a server when they click a link or a button. They expect websites to be fast like native apps. Why would users expect that? Most of websites use multiple pages and users are used to that. We change pages when reading paper books too. It’s not instant. In fact, some SPAs are much harder to navigate because they are over…

> Why would users expect that? Most of websites use multiple pages and users are used to that.

I concur with this sentiment. Most SPAs I have interacted with end up being a bad experience because when a page change action does not result in a page refresh, I expect the content to be delivered with native-like performance. Obviously, mobile and desktop browsers don't deliver that just yet. I doubt they ever will until mobile platforms figure out a way to charge a cut of any transactions happening on these apps.

Re: Your single-page app is now a polyfill

#48

Post by fxtentacle » Thu, Oct 08, 2020, 11:56 AM UTC

SirHound wrote: post #27

fxtentacle wrote: post #18

Earlier quoted context omitted.

"it would have been impossible without it" C++ desktop app It'll even have 2x the throughput at the same CPU level. Plus users can choose when they want to run your app, as opposed to you accidentally draining their battery because they left an old tab open. Boom, possible and better :p

Better = higher barrier to entry?

Less behavior that users are surprised by in a negative way.

Re: Your single-page app is now a polyfill

#49

Post by recursivedoubts » Thu, Oct 08, 2020, 1:06 PM UTC

jiofih wrote: post #13

You know what also uses the streaming parser? Standard server-rendered pages. The idea that SPAs are faster because “they just download the content” is rarely true, HTML compresses well and the content will take the same space in either. The real bottlenecks are in re-executing huge amounts of JS per page (don’t have huge amounts of JS?) and page transitions (being worked on).

Absolutely.

The initial motivation for building intercooler.js (and then htmx) was because I found that slamming a large html table rendered on the server into the DOM directly was orders of magnitude faster than running the JSON equivalent through a local template engine.

Re: Your single-page app is now a polyfill

#50

Post by chrismorgan » Thu, Oct 08, 2020, 2:02 PM UTC

the_gipsy wrote: post #30

chrismorgan wrote: post #12

Earlier quoted context omitted.

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…

This is just one bug you found. There are more edge cases for sure, serviceworkers intercepting requests and caching is a nightmare.

I think it’s better characterised in this way: service workers are dangerous because you can break things; so it’s very important that the foundations of your service worker are sound. If the foundations are sound (which takes effort), there’s nothing wrong with them. But ad hoc service workers, like this, are extremely dangerous.