Hacker News Reader

Comment by robotnoises | Hacker News Reader

Before everyone jumps onto the JQuery/Bootstrap/etc sucks bandwagon, just a reminder that the minified jquery from cdnjs is 84.1kb. Bootstrap is 43.1kb.

If you want your page to load fast, the overall "size" of the page shouldn't be at the top of your list of concerns. Try reducing the # of requests, first. Combine and minify your javascript, use image sprites, etc.

View on HN

That's still 84 KB of highly compressed javascript code to parse and execute. Even on a 4.4 GHz CPU core and a cached request, jquery takes upwards of 22ms to parse - that's just parsing - not even executing anything! Now add a bunch of other frameworks and utility scripts and your 100ms budget for feeling "fast" is gone before you even reach the HTML content.

How long does it take you to start Word versus loading Google docs?

Has everyone gone insane? The web is absolutely incredible and JavaScript is absolutely killing it as a portable application language. Remember the dark days of flash? Stop complaining.

This is disingenuous - he's obviously referring to image and text articles, not complicated web apps. Obviously such a website is going to take longer to load, just as complex native applications take a while to load. But to claim that because Word takes a while that it's okay that A WEBSITE WITH LITERALLY JUST TEXT AND IMAGES is 18 megs big and takes 6000 ms to load is fucking stupid.

Also, Word takes a while to load, but then works fast and is responsive - as well-written native apps are by default - and doesn't suck up your system resources. Something which can't be said about many websites "with literally just text and images".

You're comparing a well-written native app with a poorly written website. I'm currently working on a web-app that requires an about 600kb (minified, yes I know) app.js file.

It takes a while to load (not really, 100ms + download), but after that it is silky smooth due to client side rendering (faster than downloading more html) and caching.

On the most demanding page, heap usage is a little more than 20mb.

Sure, there are a lot of websites which are slow and huge memory hogs. But that goes for many native apps as well.

Come on, you know that's the exception and not the rule. No one should use a revenue generating site as a basis for how the web works. Unless they want to compare it to a similar native product.

Yes, I remember flash, when it was trivial to save things I found with a couple of clicks. The typical webapp is ephemeral -- no way to save it, no way to run it a few years from now after the site it was hosted on goes bye-bye. The typical webapp is terrible at interoperability -- getting it to work with native libraries is pretty much impossible unless you've written your native code in one of the few languages that have transpilers available. The typical webapp is terrible at multithreading -- webworkers are a horrible hack, with no way to send/receive objects between worker threads other than routing everything via the main thread. When you start wanting to do anything interesting, the web's a set of blinders and shackles, keeping you from using resources.

Um, Word has pretty much always started in a second or two even on computers from the year 2000. You're picking on the wrong app there: Microsoft was notorious for caring about startup time of their Office suite and going to tremendous lengths to improve it.

Meanwhile, how fast Google Docs loads depends entirely on the speed of my internet connection at the time. Good luck even opening it at all if your connection is crappy, flaky, if any of the ISPs between you and Google have congestion issues, or if there's a transient latency problem in one of the dozens of server pools that makes up an app like Docs.

Vim/LaTeX is way faster though. And there's no way to make that in any clean way with the web.

That's a fair point, though my threshold for fast is probably a bit higher than 100ms. That might be a conditioned thing, though.

It's not much higher than 100ms

https://www.nngroup.com/articles/response-times-3-important-...

I see lots of websites that don't even cache static resources and use > 10 scripts and stylesheets, from a lot of different domains. Terrible.

And link the non-minified versions.

(but the different domains actually helps speed up loading with http because it helps parallelise transfers.)

Domain sharding almost never makes any sense, especially on mobile, and with HTTP2 it's working against you.

http://www.mobify.com/blog/domain-sharding-bad-news-mobile-p...

or use HTTP2 which should make the number of requests largely irrelevant.

HTTP/2 helps with that but the total size still matters. This is particularly relevant for resources like CSS which block rendering – even with HTTP/2 making it less important whether that's one big resource or a dozen small ones, the page won't render until it's all been transferred.

https://github.com/filamentgroup/loadCSS#recommended-usage-p... has a rather nice way to load CSS asynchronously in browsers which support rel=preload.

Not to mention that using the latest stable jQuery/Bootstrap from CDN means it's likely to be cached before a user visits your site.

Reply on news.ycombinator.com