Comments on: Imminent bloat warning: JavaScript size up 48% in one year

By: Timothy A. Perez

Timothy A. Perez — Wed, 23 Dec 2015 15:05:31 +0000

The reason for the increase in JavaScript is simple. The line between applications and web sites has blurred. In order to interact and/or display data asynchronously, meaning without having a page reload, then you must have client side logic (aka: JavaScript). Otherwise you’ll have a very clunky static site. As far as the file weight, it’s trivial when you take into account the various aspects being mitigated for the single page application user experience (UX) which immediately translates to quicker site interaction. I’m a huge advocate of only loading onto the client (your browser) what ever libraries/images/etc are necessary (something called lazy-loading). If a developer knows what they are doing, say for instance if they were using a common library like AngularJS, then they should know how to lazy-load dependencies on the first instance of a directive’s usage. In non-developer terms, this means, load stuff only when it’s actually about to be used.

By: acdha

acdha — Fri, 01 Jun 2012 01:29:05 +0000

In reply to Matthew Schinckel.

@Matthew Schinckel This is only partially true: because JavaScript is inherently single-threaded the only delay you’re removing with an async loader is the portion of the delay caused by network latency. Any JS loading strategy still counts against the per-host network limit and will still cause some level of blocking while the JS is parsed and executed.

This is of concern on desktop browsers and more so on mobile: even with a cache hit something as simple as the memory increase from parsing something like jQuery UI can be noticeable.

By: Matthew Schinckel

Matthew Schinckel — Fri, 01 Jun 2012 00:07:55 +0000

In reply to acdha. @acdha It all depends what is being used to load the JS. There are a whole stack of JS loaders that do not block other stuff from loading.

By: acdha

acdha — Fri, 18 May 2012 15:45:29 +0000

In reply to elliottback.

@elliottback That JavaScript completely blocks the browser until it’s been loaded, parsed and executed. This isn’t negligible on any browser and it’s particularly of concern for mobile devices where memory is more of a premium.

That said, you are right to request a breakdown: a much bigger concern would the number of scripts and source domains as those will multiply all of the overhead even if the scripts aren’t that big.

By: elliottback

elliottback — Fri, 18 May 2012 04:10:09 +0000

This is a bit silly. An extra 50kB of JS year-over-year is trivial. On a 1 Mbps connection that means that the first time you load said script it takes a few hundred ms longer, and then sits in your cache.

You should do a breakdown of what the major components of JS load are–if they are commonly hosted jQuery/google ads/google analytics growing, those will be cached aggressively and really not a factor in page load times / performance even if they grow to MB each.

By: Jo Quinn

Jo Quinn — Thu, 17 May 2012 20:28:26 +0000

Javacript is your friend!!

By: ArtViper Designstudio

ArtViper Designstudio — Thu, 17 May 2012 20:28:24 +0000

So what? People demand more interactivity, thus more scripts. But at the same time, internet connections become faster, and parallel loading solutions and cdns are out there – so there’s no reason for crying “alarm”.