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

101–110 of 164 posts

Re: Your single-page app is now a polyfill

#101

Post by tziki »

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.

First, I think service workers are essential if we don't want all future apps to live and die by arbitrary app store restrictions. Service workers provide a lot of functionality that make web pages competitive (feature-wise) with apps. Second, I'm sure you've seen plenty of implementations that were just fine, you just didn't notice. Angular comes with a default implementation that does caching and plenty of sites use it.

Re: Your single-page app is now a polyfill

#103

Post by cjstadler »

the_gipsy wrote: post #29
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.

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

Re: Your single-page app is now a polyfill

#104

Post by dougmany »

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…

I am curious what tools you are using. I am trying to upgrade Angular 1.4 to 1.7 and it is a nightmare. Has your method had any sort of time test for upgradability?

Re: Your single-page app is now a polyfill

#105

Post by haywirez »

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.

You can send a Clear-Site-Data header[1] for forcing a full refresh.

[1] https://w3c.github.io/webappsec-clear-site-data/#header

Re: Your single-page app is now a polyfill

#106

Post by lhorie »

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…

> that's going to be less than 1ms of delay

That doesn't jive with my experience. If you are using something like React to do client-only rendering, you're gonna be waiting a lot for blocking critical path JS to run, as well as the actual paint time (which alone can easily be in the hundreds of milliseconds).

> Ship your users an app including a copy of the data ahead of time

That's not really feasible though, is it? Most SPAs in the wild fetch data on demand, so you still get the network latency no matter what (on top of the delay due to no streaming each time). This is why you get those skeleton placeholders on sites like Facebook.

Re: Your single-page app is now a polyfill

#108

Post by ilaksh »

I thought this article was going to be about HTTP 2 Server Push which allows the server to deliver pages ahead of time before you click them and thus allows for the instant transition between preloaded pages.

It's strange to me that people do not appreciate that technology or discuss it more. I think it's just something that hasn't caught on.

Re: Your single-page app is now a polyfill

#109

Post by orthecreedence »

pier25 wrote: post #64
FpUser wrote: post #56

Frankly I do not experience any problems mentioned by the author in my single page apps. Maybe because I avoid giant frameworks and my app does not drag down megatons of dependencies. Instead they feel nice and respond instantly. Customers love it.

I agree. I wrote an SPA with Mithril a couple of months ago and the entire app fit in 38kB gzip. For me the biggest drawback of an SPA is that it's a lot more work.

I've found SPAs to be less work. Instead of having two templating systems (server-side and client-side) there's just one on the client side. Now I don't have to share code between client and server, but more than that, the two are logically separated. The client can just be a client, rather than a strange half-extension, half-app of the server. Secondly, if you also want to expose an API, do you put it in the server that does the rendering, or do you have a third component that the server talks to? With an SPA, there's only the app and only the API and the two are separated out by their respective duties quite cleanly.

Once I started building out SPAs for data-driven applications, I never looked back to the old model of generating HTML server-side. It seems barbaric to me. The only hesitation I would have is if the SPA needs to be SEO optimized, in which case you can go either isomorphic (again, not a fan) or scrape pages via a headless browser as .html into a directory that your webserver serves up.

Re: Your single-page app is now a polyfill

#110

Post by nawgz »

lhorie wrote: post #106
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…

> that's going to be less than 1ms of delay That doesn't jive with my experience. If you are using something like React to do client-only rendering, you're gonna be waiting a lot for blocking critical path JS to run, as well as the actual paint time (which alone can easily be in the hundreds of milliseconds). > Ship your users an app including a copy of the data ahead of time That's not really feasible though, is it?…

>which alone can easily be in the hundreds of milliseconds

This actual paint time is surely not any different than if you rendered the exact same application from pre-hydrated HTML though.

Plus, if your application is so complex that paints are on the order of magnitude of network latency, it's probably very important to have a framework to handle interactivity, else everything will end up as some kind of a mess if you try to re-load the whole HTML page to change some small DOM subtree.

Overall, I don't really see the situation where an SPA is performing worse than a server-rendered application, given that some in-browser interactivity is required.

Post reply on HN