5 ms·

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

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?

epmatsw 10y ago
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 10y ago
  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 10y ago
    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.
untog 10y ago
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/ https://nolanlawson.com/2016/08/15/the-cost-of-small-modules...
- amelius 10y ago
  Still does 38kB really matter if the rest of your app requires parsing of several hundreds of kB of JS?
  - untog 10y ago
    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 10y ago
    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 10y ago
      If you're going that route, then server side rendering may be a better option.
  - enraged_camel 10y ago
    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).
- wwweston 10y ago
  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").
coltonv 10y ago
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 10y ago
  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 10y ago
    But that is stripped out in production builds, so is not contributing to the size everyone is talking about.
    - tracker1 10y ago
      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 10y ago
        What do they leave in?
redindian75 10y ago
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.

epmatsw 10y ago

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 10y ago
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 10y ago
  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.

untog 10y ago

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/ https://nolanlawson.com/2016/08/15/the-cost-of-small-modules...

amelius 10y ago
Still does 38kB really matter if the rest of your app requires parsing of several hundreds of kB of JS?
- untog 10y ago
  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 10y ago
  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 10y ago
    If you're going that route, then server side rendering may be a better option.
- enraged_camel 10y ago
  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).
wwweston 10y ago
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").

coltonv 10y ago

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 10y ago
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 10y ago
  But that is stripped out in production builds, so is not contributing to the size everyone is talking about.
  - tracker1 10y ago
    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 10y ago
      What do they leave in?

redindian75 10y ago

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.