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

51–60 of 164 posts

Re: Your single-page app is now a polyfill

#51

Post by redwall_hp »

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

If the majority of users only view the one page they land on, throwing a load of JS at them to make subsequent page loads faster is only slowing down their experience.

It's also pointless for users who aren't the lowest common denominator, since opening links in new tabs also defeats the whole premise. That's how I'm browsing HN right now: middle-clicking several links on the front page, so I don't lose my place, opening the links and then comment pages in new tabs.

Re: Your single-page app is now a polyfill

#52

Post by redwall_hp »

obilgic wrote: post #2

off-topic: how/why is medium still around with their very aggressive techniques? They started as a minimalist blogging platform, and once they acquired the content, they started putting paywalls in front of their users' content.

Because it pays out well for popular posts and doesn't involve ads. I made a few hundred dollars off one that I published there over the summer.

Re: Your single-page app is now a polyfill

#53

Post by jakelazaroff »

fxtentacle wrote: post #18
inglor wrote: post #16

Earlier quoted context omitted.

There are many use cases for service workers you probably haven't heard of. For example at my last job (at a YC startup) we built a service worker that used P2P to serve mp4 video over WebRTC. It was the correct place to interop with the download - it was explicit and it would have been impossible without it. ---- I think the common use case (of much control over caching) is also quite reasonable. I agree the API and…

"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" is subjective. Web apps sacrifice performance, but you get an app that you don't have to install, that can't do anything malicious to your system without your consent, that's (at least in theory) easily shareable and deep linkable. Maybe that tradeoff isn't worth it for you, but it is for a lot of people!

Re: Your single-page app is now a polyfill

#55

Post by Justsignedup »

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 number of lines of code, but counting by how easy developers find it to change the logic without breaking everything in a complex codebase.

So idk, maybe I'm doing it wrong.

Re: Your single-page app is now a polyfill

#56

Post by FpUser »

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.

Re: Your single-page app is now a polyfill

#57

Post by Scarbutt »

sambeau wrote: post #9

This is impressive and would work really well in a lot of sites, especially ones with static content. However it misses two important reasons to use a single-page app: 1. SPAs allow for highly interactive interfaces with custom components, drag & drop, audio etc. 2. SPAs can cache UI state in the client. The alternative is to store it in a server side session specific to each client. This is possible, of course, but…

2. SPAs can cache UI state in the client. The alternative is to store it in a server side session specific to each client.

Non-SPA doesn't mean 0% JS.

Re: Your single-page app is now a polyfill

#58

Post by pier25 »

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.

Also probably because you're close to the server. I doubt someone in say New Zealand would have instant page loads on HN.

The solution of course is having distributed data and logic which is becoming much easier and cheaper these days.

Re: Your single-page app is now a polyfill

#60

Post by pier25 »

sambeau wrote: post #9

This is impressive and would work really well in a lot of sites, especially ones with static content. However it misses two important reasons to use a single-page app: 1. SPAs allow for highly interactive interfaces with custom components, drag & drop, audio etc. 2. SPAs can cache UI state in the client. The alternative is to store it in a server side session specific to each client. This is possible, of course, but…

> SPAs allow for highly interactive interfaces with custom components, drag & drop, audio etc.

None of the features you listed require an SPA. Other than page transitions you can have any UI sophistication on an MPA.

> This is possible, of course, but it will either be lost every time the server is restarted, or it will need to stored in the database.

Which is why there are caching databases like Redis to solve this.

Post reply on HN