Comment by addicted44 | Hacker News Reader

Comment by addicted44 | Hacker News Reader

Parent Full thread

The average user, by Google's own studies, wants a faster experience.

By far.

Is there any evidence that web apps of today are faster in achieving what equivalent non appy web pages of the past managed? Despite the fact that those older "apps" were running on computers which were orders of magnitude slower than our cell phones today.

I've worked with 2 companies now where their users (and both these companies have users who pay 4 digit annual fees per user) have refused to migrate to the new Web 2.0 apps these companies have tried to foist on them.

The difference in these cases is that the users, by virtue of paying, actually have a say and so have required the companies to provide parity with the older and newer applications, and usage continues to not just be higher, but grow faster on the older versions (despite having a larger base).

Regular users have no such option. Google changes GMail, but its users still insist on using the older versions of the app, which is why they provide HTML mode, etc. However, it's users do not pay Google, and are forced to go with whatever Google wants to do, which is constantly hiding the older version and making it progressively worse to use.

It's not evident to me at all that regular users "want" to use these new web 2.0 apps, as much as they don't have a choice.

I find it interesting by default I switch back to classic if possible. All newer interfaces seem to remove features and slow things down.

Yes and no: Ajax allows interactive (snappier/faster) behavior in most cases, especially for complex interaction flows. Using the minimal html Gmail interface vs the modern one, the modern one is quicker for complex interactions because I end up loading fewer pages,even if the average load is more expensive.

It doesn't feel faster to me. And that's the case with Ajax in general - in principle, it can allow for snappier, faster experience. In practice, it rarely does.

I just measured it: switching between "drafts" and "inbox" on the new gmail takes ~15 ms, while on the simple HTML view, it takes 3-500ms per load.

Its literally 20 times faster, and importantly, cuts across the human visual perception boundary, which is at ~200ms. So the old HTML version is human perceptible, while the new version renders in ~1 frame.

Fair enough. On a fast enough machine. This is off-topic, but while on my beefy dev desktop I get similar times to you, this was absolutely not the case on a much weaker laptop I used sometimes during travel - and the latter is more representative of how regular people experience things.

(Also, FWIW, loading delay of HTML pages on said beefy desktop, as tested right now, are consistently about 750-1500ms for me.)

More on-topic, these times apply only when the pages are hot in the browser cache. On my desktop, the first-time switch between "drafts", "sent" and "inbox" takes around 3 seconds each, and only then it is instantaneous. So regular users are likely to experience these long Ajax delays more often than not.

It depends on the application though. Mapping apps (e.g google maps) without ajax are awful.

Even basic UIs like filtering can be bad if you want to change multiple filters, and you have to wait for a whole page load in between each change (page load times for pages with filters are often slow as they're performing complex queries).

It's a case of different things being appropriate for different use cases I think. There definitely are still times when plain HTML is best, but it's also not always faster.

I've built a React app that's under 300kb (cached with a service worker for subsequent page loads) that loads almost instantly and works offline. On the other hand, plenty of plain HTML sites include heavy CSS frameworks, or 5mb images, gifs, etc and load pretty slowly, especially on poor connections.

TBH, that's a side effect of "EVERYthing is a webpage, because that's the way it is!" Of course a map application is SLOOOOOOW when forced to go through all the intermediate steps to resemble a web page. Mapping apps that forgo this convention are snappy; but no: a chat client is a web browser, a map client is a web browser, the "show me two lines of text" notification bar is a God-damned webbrowser.

Snappier! You mean "with more spinners, now with added lag". (Get off my lawn.)

Reply on news.ycombinator.com