Live data from Hacker News

Your single-page app is now a polyfill

itnext.io

71–80 of 164 posts

Re: Your single-page app is now a polyfill

#71
post #54

Is there any evidence that users really prefer SPAs? There are plenty of examples of super successful websites that are not SPAs (Amazon, Github, StackOverflow, Wikipedia, etc).

Those websites may not be SPAs but they still contain big JS payloads. Not sure about the others, but my guess is that if Github were created today, most of it would probably be an SPA.

> Those websites may not be SPAs but they still contain big JS payloads.

Probably, although my question was not about the bloat but the claim on the article that users prefers the UX of SPAs.

> my guess is that if Github were created today, most of it would probably be an SPA

Why is that?

Re: Your single-page app is now a polyfill

#72

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…

> Ship your users an app including a copy of the data ahead of time I did exactly that with a hobby project ( https://www.acceleratul.ro/ ). The funny thing is that I had to add a short (~50ms) artificial delay with a spinner before showing search results, because people completely missed the fact that the page had refreshed

Nice helpful project, I think I may have used it once while in Romania. Yeah, for small static data it absolutely makes sense to embed it in the app itself. But imagine your app was world wide or it needed to account for dynamic data, not sure it would make sense to ship a few dozen MBs all at once.

Re: Your single-page app is now a polyfill

#73

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…

The sort of garbage we ended up doing prior to SPAs justify SPAs.

Writing a server to dynamically create a HTML page that also includes first pass content as well as potentially dynamic javascript to make the page interactive in "later passes" is just an ugly mix of client side execution and server side execution in one spot.

The application just feels a lot more consistent when the client is just pulling data instead of being thrown away and recreated in the middle of a request made by a browser for a particular URL that is just one of a very long series of requests.

Re: Your single-page app is now a polyfill

#74
post #71

Earlier quoted context omitted.

Those websites may not be SPAs but they still contain big JS payloads. Not sure about the others, but my guess is that if Github were created today, most of it would probably be an SPA.

> Those websites may not be SPAs but they still contain big JS payloads. Probably, although my question was not about the bloat but the claim on the article that users prefers the UX of SPAs. > my guess is that if Github were created today, most of it would probably be an SPA Why is that?

Probably, although my question was not about the bloat but the claim on the article that users prefers the UX of SPAs.

Should rephrase that, they have big JS payloads to make the website feel close to an SPA as possible.

> my guess is that if Github were created today, most of it would probably be an SPA

Github.com today has many components that are pure JS(most new features), writing it today from scratch my guess would be they would have go almost all client-side JS.

Re: Your single-page app is now a polyfill

#75
post #71

Earlier quoted context omitted.

> Those websites may not be SPAs but they still contain big JS payloads. Probably, although my question was not about the bloat but the claim on the article that users prefers the UX of SPAs. > my guess is that if Github were created today, most of it would probably be an SPA Why is that?

Probably, although my question was not about the bloat but the claim on the article that users prefers the UX of SPAs. Should rephrase that, they have big JS payloads to make the website feel close to an SPA as possible. > my guess is that if Github were created today, most of it would probably be an SPA Github.com today has many components that are pure JS(most new features), writing it today from scratch my guess w…

> they have big JS payloads to make the website feel close to an SPA as possible

Can you give an example?

I know Github uses Turbolinks, but that doesn't really contribute much to its bloat.

> Github.com today has many components that are pure JS(most new features)

What you're saying is that because some of their features on some of their pages are JS heavy then it would make more sense to make an SPA?

Re: Your single-page app is now a polyfill

#76

Earlier quoted context omitted.

"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!

Yeah this is the point right here that seems to be so easily forgotten. You lost every non-programmer at “okay download this binary and run it from the terminal with these flags”

Not really. Non-programmers have also been using computers ever since the PC revolution and are quite used to downloading, installing and running programs, provided it has a usable GUI. After all, web apps are very recent. Even now, most programs are installed, and the rest are websites.

Re: Your single-page app is now a polyfill

#77

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…

> Ship your users an app including a copy of the data ahead of time I did exactly that with a hobby project ( https://www.acceleratul.ro/ ). The funny thing is that I had to add a short (~50ms) artificial delay with a spinner before showing search results, because people completely missed the fact that the page had refreshed

This is cool. What techniques did you use to include a copy of the data?

Re: Your single-page app is now a polyfill

#78
post #66

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.

Hook up your iPhone to your Mac via lightning cable. Open Twitter on your iPhone and then on your Mac open Safari, enable develop mode, and then go to Develop > Your iPhone > Twitter tab. This will open up inspector on your Mac allowing you access to the local Twitter data on your iPhone. I think that should work.

I have a pixel and a thinkpad, but yea I've considered that.

But I also realized that now I'm wasting a little bit less time on my phone :)

I also am intrigued if there is a way for twitter to fix this on their end, somehow, sometime.

Re: Your single-page app is now a polyfill

#80

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.
Post reply on HN