[chickenfries]

From the README

> Inferno is much smaller in size, 7kb vs 45kb gzip.

Given that you're building the kind of app that is complicated enough to require a state management library, a virtual dom implementation, etc... does this 38kb really matter? Is anyone really shipping commercial apps where 38kb on page load would be that meaningful of a performance gain? Especially if you're doing serverside rendering and requiring react asynchronously?

[untog]

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

[wwweston]

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

[amelius]

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

[untog]

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.

[grayrest]

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.

[amelius]

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

[enraged_camel]

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

[_uhtu]

I use React currently and yes, this is an important argument.

Faster load times are better. And if Inferno accomplishes better rendering speed while also being smaller, it is basically universally more performant than React.

I evaluated both thoroughly and chose React over Inferno because of the massive community around React, but numbers like this are intriguing.

[tracker1]

There's also preact + preact-compat which provides a compatibility shim... Works as pretty much a drop-in replacement for React for your prod builds.

However, that "extra" isn't all just junk, it's a LOT of REALLY nice error reporting that I've not seen in ANY other framework. Dealing with errors in React applications is far, far, far easier than some other frameworks have been (ahem, ng1/ng2).

[jazoom]

But that is stripped out in production builds, so is not contributing to the size everyone is talking about.

[tracker1]

Not all of it... there are still extras that come in the production builds of react compared to other frameworks... I'm not talking about the property checking, etc.

[jazoom]

What do they leave in?

[epmatsw]

I assume the argument is going to be that on mobile the parsing time for 7kb of JS vs 45kb of JS is going to be significant.

[mhd]

And you might be able to avoid simultaneous client- and server-side rendering and all the horrors this brings with it in the first place.

[tracker1]

Frankly, everyone I know insisting on isomorphic rendering is doing it for SEO not for improved first display on mobile. Not that it isn't worth it... what WalmartLabs has done is incredibly impressive in this space.

[redindian75]

It is not the 38KB size, but that much lines of code will take browser x amount of time more to decipher, keep track of...etc.