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).