Here we go again. I click the link. Get to an under construction page. Click the link, get to Github, think "this is interesting" to myself. Read on. Find there's a project called Cerebral, which is a state management library for React/Inferno/Whatever. Start thinking there's something wrong with my app, that's "just" about to launch, and is "just" using plain old Redux. And now I'm thinking it's not good enough any…
Every OS project README needs 2 sections: Purpose, where it explains what it is and why, and Prior Art, where it explains what came before, and how the project improves on / differs from them.
With time at such a premium, that is by far the most valuable information you could possibly communicate. I wouldn't even be bothered by having to read comments/unit tests to figure out how the thing works if you just tell me why I should care in the first place.
Inferno is basically React, so instead of contributing to react to make it better they made a new project instead. Hipster hype is a PROBLEM in the JS community.
Inferno is very similar to React, but with enough differences in implementation that the contributors decided to make it its own project. Competition is good . Cars weren't invented by everyone focusing their effort on building the same car. Instead, many teams built many cars with similar, overlapping functionality, and over time, the good parts stuck around, and the bad parts came out in the wash. JS UI libraries a…
Think of a professional vehicle driving. Be it race cars, trucks, etc... Sure, maybe in the early days those cars and trucks looked and worked way different from each other but over time the available ones largely overlap, work similarly, and work well in almost all situations. If every time a new car came out you had to spend several days/weeks trying to figure out how to drive it that would be incredibly annoying. Now just think if you needed to purchase a vehicle and stake your business on it. You look at the options and some come without wheels, some without seats, some had designers that said brakes aren't neccessary, oh and there is an upcoming one that is getting a lot of attention the can also fly... some take gas, others run off vegetable oil. Experimentation is good but there are way too many options parading around as serious contenders.
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…
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.
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).
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.
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.
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.
There's far more to Inferno than just file size. The internal implementation is completely different. Furthermore, React Fiber and Inferno are very different in terms of internal approach.
Thanks for your reply Dominic. As an end user, what should compel me to use Inferno for any production purposes? Bearing in mind React has the support of multiple billion dollar companies, several targets (web, native mobile/desktop, console) and a community of what is sure to be tens if not hundreds of thousands of developers. I just don't see the benefit of incremental improvements when they're not being integrated…
Personally, I was actually looking for an alternative to react some time ago, on the grounds of that "BSD License" + "Patents" that facebook has got on it. From what I know no, nothing has happened yet, but for peace of mind, having an alternative would help.
FYI, What I found was preactjs which is a 3kb with most new es6 features of react which I've started using in my project. Unfortunately, I haven't found an alternative to react-native yet.
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.
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).
But that is stripped out in production builds, so is not contributing to the size everyone is talking about.
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).
But that is stripped out in production builds, so is not contributing to the size everyone is talking about.
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.
With respect, friend, you do it to yourself... If a mention of a new library on HN is enough to shake your confidence and make you think your entire app stack is wrong - that's not a Javascript problem. I understand feeling overwhelmed with all the new libraries, but get confident with a JS stack that you like, and stop worrying about all the hype.
Inferno is basically React, so instead of contributing to react to make it better they made a new project instead. Hipster hype is a PROBLEM in the JS community.
That is so far from the truth that it's unbelievable. Inferno has the same surface API as React – the public endpoints. Everything under the hood is different though and it's different for many good reasons which I'll cover in a blog post in the coming weeks for the official 1.0 release of Inferno (and its website).
If there's nothing wrong with your app and you're using React – keep using it. If you are experiencing performance issues on mobile, maybe Inferno is an option with its compatibility layer until future versions of React can fix your issues.
Here we go again. I click the link. Get to an under construction page. Click the link, get to Github, think "this is interesting" to myself. Read on. Find there's a project called Cerebral, which is a state management library for React/Inferno/Whatever. Start thinking there's something wrong with my app, that's "just" about to launch, and is "just" using plain old Redux. And now I'm thinking it's not good enough any…
Focus on the product, not the technology used to build it. If your tech decisions (vanilla Redux) makes you productive, then use that. Otherwise, you'll be stuck in a never-ending loop of upgrading your stack all the time.
I just downgraded my stack because state of the art kept breaking too much and slowing me down big time. Comfortably a step behind the cutting edge now and it feels great. Credit to Dan Abramov (creator of Redux) for writing "You Might Not Need Redux" and showing me the light... I needed just about nothing on his list of why Redux can be a critical help.