6 ms·

What I don't understand is why a very simple blog like this needs a ~56KB bundle of JavaScript at all.

Cthulhu_ 8y ago
^ exactly; blogs are mostly static. You can improve the responsiveness of e.g. a comments section with a bit of JS, but that's very low priority and doesn't need to be much.
oftenwrong 8y ago
This blog works fine without javascript.
- pc86 8y ago
  Which doesn't answer the question.
  - lucb1e 8y ago
    It shows that the answer is simply "nothing whatsoever".
mrspeaker 8y ago
Looking at the blog post, I'd say it was for drawer.init(), contentLoader.init(), breakpoints.init(), alerts.init(), and analytics.init(). The site works fine without javascript, so it doesn't need it - perhaps the author thinks the 50k is worth the drawer, content loading, breakpoint?, and alert features and also wants a bit of user analytics tracking.
- AstralStorm 8y ago
  Even so, you could backload the drawer etc. placing them at the end of the document and attaching to potentially already rendered page. Reorder so that your main content loads first. Author did part of it by deferring the analytics init. Not sure why they used setTimeout though for the initialization instead of requestIdleTimeout like everything else. The page is supposed to work without JS after all. "I mentioned above that requestIdleCallback() doesn’t come with any guarantees that the callback will ever run." Not true - there's a timeout argument. It guarantees that the callback will by ran by then.
mjdease 8y ago
Regardless of the demonstrated use case, these principles can be applied to improve the performance of web pages that use JavaScript
- CydeWeys 8y ago
  Thank you. That'd be like someone criticizing a coding example for a new language saying "What's the point of using OOP for implementing Tic-Tac-Toe? It's too simple to necessitate it."
  - thegeomaster 8y ago
    I'm not criticizing the technique from the article. It's useful. I'm just expressing my confusion that the blog, simple as it looks, needs this JavaScript (and analytics are in a separate file from the one I'm referencing, it appears).
    - philipwalton 8y ago
      That 56K number isn't gzipped, gzipped it's only 18K (plus there's also some inline JS, some webpack boilerplate, and then analytics.js). The reason for its size is my site is my playground. It's where I get to experiment with all the things I want to experiment with. I also work on quite a few open source projects, which I usually test on my site before releasing them publicly just to make sure they work in production without errors.
ummonk 8y ago
You make that sound like a lot. It's only equivalent to like 20 pages of raw plain text in size.
neetdavid 8y ago
I poked around a little and it seemed like the majority of it is related to analytics events (googleanalytics/autotrack) I suppose the author just wants to know a little about how their blog and writing is performing in the wild Sort of off topic, but it would be interesting if the browser handled these common cases instead and gave the user a way to opt-in/out. I suppose it sort of does by broadcasting those events to the js listeners in the first place.

^ exactly; blogs are mostly static. You can improve the responsiveness of e.g. a comments section with a bit of JS, but that's very low priority and doesn't need to be much.

oftenwrong 8y ago

This blog works fine without javascript.

pc86 8y ago
Which doesn't answer the question.
- lucb1e 8y ago
  It shows that the answer is simply "nothing whatsoever".

mrspeaker 8y ago

Looking at the blog post, I'd say it was for drawer.init(), contentLoader.init(), breakpoints.init(), alerts.init(), and analytics.init(). The site works fine without javascript, so it doesn't need it - perhaps the author thinks the 50k is worth the drawer, content loading, breakpoint?, and alert features and also wants a bit of user analytics tracking.

AstralStorm 8y ago
Even so, you could backload the drawer etc. placing them at the end of the document and attaching to potentially already rendered page. Reorder so that your main content loads first. Author did part of it by deferring the analytics init. Not sure why they used setTimeout though for the initialization instead of requestIdleTimeout like everything else. The page is supposed to work without JS after all. "I mentioned above that requestIdleCallback() doesn’t come with any guarantees that the callback will ever run." Not true - there's a timeout argument. It guarantees that the callback will by ran by then.

mjdease 8y ago

Regardless of the demonstrated use case, these principles can be applied to improve the performance of web pages that use JavaScript

CydeWeys 8y ago
Thank you. That'd be like someone criticizing a coding example for a new language saying "What's the point of using OOP for implementing Tic-Tac-Toe? It's too simple to necessitate it."
- thegeomaster 8y ago
  I'm not criticizing the technique from the article. It's useful. I'm just expressing my confusion that the blog, simple as it looks, needs this JavaScript (and analytics are in a separate file from the one I'm referencing, it appears).
  - philipwalton 8y ago
    That 56K number isn't gzipped, gzipped it's only 18K (plus there's also some inline JS, some webpack boilerplate, and then analytics.js). The reason for its size is my site is my playground. It's where I get to experiment with all the things I want to experiment with. I also work on quite a few open source projects, which I usually test on my site before releasing them publicly just to make sure they work in production without errors.

ummonk 8y ago

You make that sound like a lot. It's only equivalent to like 20 pages of raw plain text in size.

neetdavid 8y ago

I poked around a little and it seemed like the majority of it is related to analytics events (googleanalytics/autotrack) I suppose the author just wants to know a little about how their blog and writing is performing in the wild Sort of off topic, but it would be interesting if the browser handled these common cases instead and gave the user a way to opt-in/out. I suppose it sort of does by broadcasting those events to the js listeners in the first place.