Hacker News Reader

Comment by untog | Hacker News Reader

These days, JS parse time on mobile devices is more important than file size. And that isn't even necessarily file size specific - Nolan Lawson did a comparison of the different methods used to bundle JS to show how they can have a huge impact:

https://nolanlawson.com/2016/08/15/the-cost-of-small-modules...

View on HN

That's one of the most solid articles I've seen on front-end development in a while -- not a think piece, tons of practical information, relies on examining information, but also does get around to a deep-seated problem with JS right now ("I hope that our community will eventually realize the pickle we’re in – advocating for a “small modules” philosophy that’s good for developers but bad for users").

Still does 38kB really matter if the rest of your app requires parsing of several hundreds of kB of JS?

I think that if you're focused enough on performance to be looking at InfernoJS, the rest of your JS isn't hundreds of KB big.

If you're bundling it into one payload it does not. If you're code splitting, it's 38k of download time and ~120k of parse time you're not paying on time to first meaningful paint. It's a couple dozen ms on desktops but can be several hundred on mobile.

If you're going that route, then server side rendering may be a better option.

Probably not. The rest of your app aside, in the vast majority of cases, if you care about the file size you're optimizing the wrong thing (barring certain extremes of course).

Reply on news.ycombinator.com