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

91–100 of 164 posts

Re: Your single-page app is now a polyfill

#91

Post by scsilver »

playpause wrote: post #61
divbzero wrote: post #22

This is seriously nifty but you really don’t need SPAs or client-side request interception for page loads to feel “instant”. All you need is server-side rendering without a zillion third-party scripts. Clicking around Hacker News provides case in point.

We have different definitions for “feeling instant”. Most clicks on HN take well over 2s for me on a 4g connection, and often about half a second even on fast broadband. Sure that feels snappy compared to most websites, but it is still a completely different experience to using an app, or indeed a website that has been designed to eliminate perceptible delays as opposed to making them shorter. These are separate (and…

Yeah it took over a second to get to this comment page. A lightweight js app could have popped up a modal, I put in my comment, click send, and hide the modal and show a spinner on the bottom right changing to a checkmark when the comment goes through. That's feeling instant, not waiting for the back and forth to a server. The other stories could be lazy loaded in the background as I scroll.

Re: Your single-page app is now a polyfill

#92

Post by debaserab2 »

WillPostForFood wrote: post #80
Justsignedup wrote: post #55

My reasons for SPAs has always been complex behaviors on the app and state persistence is a PITA if you don't end up with a nice MVVC on the front-end. Not saying not possible to make complex pages without SPAs, but there are some things that are harder, and some that are easier. Personally I love writing SPAs, I find that I end up making less complex code which ends up being easier to maintain. Not counting by the n…

These are good reasons, but notice they are all about improving the experience for the developer, not the user.

If you have a messy codebase with logic mimicked on both the back and front end its not just the developer experience that suffers - the user experience will eventually suffer too.

Re: Your single-page app is now a polyfill

#93

Post by scsilver »

onli wrote: post #89
playpause wrote: post #61

Earlier quoted context omitted.

We have different definitions for “feeling instant”. Most clicks on HN take well over 2s for me on a 4g connection, and often about half a second even on fast broadband. Sure that feels snappy compared to most websites, but it is still a completely different experience to using an app, or indeed a website that has been designed to eliminate perceptible delays as opposed to making them shorter. These are separate (and…

If the delay you are experiencing is caused by your connection, having the data served via a JS worker will not be faster. The additional overhead compared to a pure HTML page will hurt even more.

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

Re: Your single-page app is now a polyfill

#94

Post by mrlala »

imtringued wrote: post #43
shusson wrote: post #33

Earlier quoted context omitted.

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.

For sure. I have a complicated SPA app that is as complex as any desktop application; but with the flexibility of it being a simple web app.

I never, ever, ever could have managed to pull this off before SPA. Especially as a non-primary web developer, angular basically does all the grunt work for me and allows me to keep a very structured application.

Looking forward to attempting a blazor experiment as some point; as I still hate having to define the same object on the front-end vs back-end and I use dynamic data little too much.. but the current state of being able to use an SPA blows the options before out of the water.

In my mind, you had to be a 100% javascript/web developer to create any type of usable complicated equivalent SPA.. but now I can do a structured (mostly) typed front-end.

Re: Your single-page app is now a polyfill

#95

Post by auggierose »

rob74 wrote: post #87
nexuist wrote: post #81

Earlier quoted context omitted.

I think the question is whether developers actually care if users with cheap devices can't use their SPAs. If you're trying to sell them something, you probably want customers with deep enough pockets to afford a somewhat modern phone. If you don't want to sell them something and you just want to provide information (e.g. restaurant website, digital flyer, event RSVP, etc) you could serve a simple static page, or for…

> forego the website entirely and post your information on social media which can then be consumed by optimized native apps ...and force the user to install the "optimized native app" for the social media site du jour ? Or simply let them put up with Facebook's "yes-this-is-a-public-page-but-I'm-still-going-to-ask-you-to-log-in-or-sign-up-just-because-I-can" shenanigans? Great UX, that!

Cheap phone, cheap UX?

Re: Your single-page app is now a polyfill

#96

Post by robertlagrant »

shusson wrote: post #26

> Why do we build single-page apps?... > We want our web apps to feel “instant”... > Blank screens make for a bad user-experience... In my experience if you really need fast page loads, SPAs are off the table. So the premise of the article makes no sense to me. In fact, what do people on HN think the main reason to choose an SPA is these days?

SPAs also can scale better - CSS, JS and HTML all just static files, not rendered by a server.

Re: Your single-page app is now a polyfill

#97

Post by onli »

scsilver wrote: post #93
onli wrote: post #89

Earlier quoted context omitted.

If the delay you are experiencing is caused by your connection, having the data served via a JS worker will not be faster. The additional overhead compared to a pure HTML page will hurt even more.

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.

Re: Your single-page app is now a polyfill

#98

Post by pgcj_poster »

"In conversations with web performance advocates, I sometimes feel like a hippie talking to SUV owners about fuel economy.

They have all kinds of weirdly specific tricks to improve mileage. Deflate the front left tire a little bit. Put a magnet on the gas cap. Fold in the side mirrors.

Most of the talk about web performance is similarly technical, involving compression, asynchronous loading, sequencing assets, batching HTTP requests, pipelining, and minification.

All of it obscures a simpler solution.

If you're only going to the corner store, ride a bicycle.

If you're only displaying five sentences of text, use vanilla HTML. Hell, serve a textfile! Then you won't need compression hacks, integral signs, or elaborate Gantt charts of what assets load in what order.

Browsers are really, really good at rendering vanilla HTML.

We have the technology."

https://idlewords.com/talks/website_obesity.htm

Re: Your single-page app is now a polyfill

#99

Post by nexuist »

rob74 wrote: post #87
nexuist wrote: post #81

Earlier quoted context omitted.

I think the question is whether developers actually care if users with cheap devices can't use their SPAs. If you're trying to sell them something, you probably want customers with deep enough pockets to afford a somewhat modern phone. If you don't want to sell them something and you just want to provide information (e.g. restaurant website, digital flyer, event RSVP, etc) you could serve a simple static page, or for…

> forego the website entirely and post your information on social media which can then be consumed by optimized native apps ...and force the user to install the "optimized native app" for the social media site du jour ? Or simply let them put up with Facebook's "yes-this-is-a-public-page-but-I'm-still-going-to-ask-you-to-log-in-or-sign-up-just-because-I-can" shenanigans? Great UX, that!

Are we really going to assume that your average user doesn't already have FB installed and already signed in? They have over one billion users, you know. It's not exactly rare to find Facebook on any arbitrary person's device.

Re: Your single-page app is now a polyfill

#100

Post by jupp0r »

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.

Have you used the internet lately? Service Workers are ubiquitous. Google.com is using them. Amazon.com is using them. Your uncles blog is probably using them too.

Sure they can be tricky, but don't dismiss their success.

Post reply on HN