
Inferno: A fast, React-like JavaScript library for building UIs - trueadm
https://github.com/trueadm/inferno
======
Renner1
At the risk of beating a dead horse, we are only fueling the flames of
javascript fatigue by churning out these "It's like X, but with more/less
cowbell" libraries. We need to stop fragmenting and start doubling down on
existing libraries.

~~~
sangnoir
> we are only fueling the flames of javascript fatigue

The majority of people I have seen complaining about Javascript fatigue do it
from the peanut gallery. If you are a Javascript developer: you shouldn't have
javascript fatigue unless you chase after the latest and greatest - which you
shouldn't do. If you do not experience have "cereal fatigue" at the
supermarket, you shouldn't get Javascript fatigue either.

It took me all of 30 seconds to skim the home page and to conclude "hmm, I
don't need this now", but I've filed it at the back of my mind should I
require it some day (I might not remember the name then, but I'll be able to
figure out the search keywords).

> We need to stop fragmenting and start doubling down on existing libraries.

I reject this sentiment. You can't force people to contribute to projects they
have no passion for. You also can't prevent people from scratching their own
itch and registering a domain for their _slightly different_ flavor-of-the-
week JS project. Best you can do is ignore them or support them. The
undeserving will wither eventually, you do not owe any project your attention.

~~~
coldtea
> _The majority of people I have seen complaining about Javascript fatigue do
> it from the peanut gallery._

You'd be surprised.

In any case, my anecdotal experience has been different: both me, and other
front-end developers I know, have been frustrated with the pace of change in
JS libraries and tooling.

> _If you are a Javascript developer: you shouldn 't have javascript fatigue
> unless you chase after the latest and greatest - which you shouldn't do._

You don't have to chase the "latest and greatest" to feel the fatigue. Merely
keeping up with what's considered "best practice" and avoiding what's
considered a dead-end and people abandon is enough.

Case in point, it's only 5 years since Backbone came out. Backbone! And if
feels like we've had 3-5 transitions already (Angular. No wait, Ember. No
React. Oh, and add Flux. Actually, go Redux.). In Python or Ruby I could still
use the Rails and Django I learned in 2006 -- not so much with JS.

> _If you do not experience have "cereal fatigue" at the supermarket, you
> shouldn't get Javascript fatigue either._

Only people have (cereal fatigue). Too much choice leads to fatigue and stress
in itself -- and this is backed by science...

~~~
sangnoir
> You don't have to chase the "latest and greatest" to feel the fatigue.
> Merely keeping up with what's considered "best practice" and avoiding what's
> considered a dead-end and people abandon is enough

Sounds like the same thing to me - you can deal with this in 2 easy steps: 1)
Ignore the hype 2) Ignore the hype. Best practices _for who?_ Facebook's "best
practices" might not work for you. You can't blame external circumstances for
_your_ technology churn, especially if the "dead-end" technologies are still
actively maintained. "Best practices" are just design by committee writ large.
I still use Grunt rather than Gulp, for me the 'improvemements' are marginal.
I still support a Dojo SPA even though it's considered ancient. These
technology decisions are not considered best practices, but they work for me.
The buck stops with _you_ (or whoever makes tech decisions at your org) - you
can't pass the blame to the larger JavaScript community.

My point is you can safely ignore the latest and greatest (or 'best practice'
as you call it). Apply common sense and only use what you need.

Speaking of hype: aren't containerized Flask-based microservices the current
'best practice' rather than monstrous Django apps? Looks like your 2006-era
technology won't cut it on the back end either - it's all about scalability
now ;)

Edit: added text below this line

> Too much choice leads to fatigue and stress in itself -- and this is backed
> by science

This is not inherently bad in any way: it's a trade-off. The paradox of Choice
states that choice decreases (present) happiness. If this is what you are
optimizing for, then less choice is good. Unfortunately, large and complex
systems are...complex and multifaceted. I'm willing to sacrifice a little
happiness in the present for ease of maintainability (when choosing a library
that better fits my needs). Nature itself seems to celebrate choice when it
comes to genetics in sexually reproducing organisms. Diversity has it's
benefits -- and this is also backed by science.

~~~
coldtea
> _Sounds like the same thing to me - you can deal with this in 2 easy steps:
> 1) Ignore the hype 2) Ignore the hype._

And then you end with abandoned npm dependencies and no new
development/books/blogs/tutorials after a short while.

~~~
RussianCow
How much does that actually matter if the libraries continue to work for you?

------
Havunen
We were previously using RiotJs in our company. We are building huge single
page application and recently moved to InfernoJS. Results have been amazing.
RiotJs used to BE lagging a lot (It simply could not handle 3000 components in
same way) It had really long (50ms) delays everywhere.

After moving to Inferno following things have improved:

-We are unit testing components -Performance!!! (No delays/lagging anymore) -es2015 syntax with JSX and inheritance -Intellisense support in IDEs (webstorm) no custom riot syntax \- Future proof syntax without worrying low level API changes

Negative things: -It took for a while to recode all our components in JSX

\--Havunen

~~~
Roritharr
What do you consider huge?

Maybe we're just slow, but we recently estimated that rewriting and launching
our whole frontend in another js Framework would take a dedicated 3 Person
Team atleast a year, how do you explain this cost to someone with financial
responsibility, I mean the benefits are probably great, but THAT great?

~~~
shados
The alternative, depending on your market segment, is your competitor do it
and you don't, they fall behind for a little bit, your sales grow.

Then their version comes out, faster and better, and their dev team iterates
faster, eventually catching up and leaves you in the dust. I've seen it
happen...very recently, in a situation that ended up in large layoffs.

It doesn't have to be all or nothing though. These libs are easy to keep
around side by side, so you can slowly rewrite stuff as you add new features
until the transition is complete.

------
ewittern
Shameless plug, I know, but I bet Inferno doesn't come close to my latest
framework when it comes to the notorious task of writing a TODO app:
[https://github.com/ErikWittern/TODOit](https://github.com/ErikWittern/TODOit)

~~~
leeoniya
i saw this come up yesterday on reddit and asked myself if this was joke. 70
lines of code is a lot of code? i don't get it :/

I'm asking this as the author of domvm [1] and a 60 LOC todo implementation
[2] that also exposes a usable API.

[1] [https://github.com/leeoniya/domvm](https://github.com/leeoniya/domvm)

[2] [https://leeoniya.github.io/domvm/demos/todo-
alt.html](https://leeoniya.github.io/domvm/demos/todo-alt.html)

~~~
ewittern
Everything is relative. Like 60 lines of code (especially as compared to a
single one). Or humor.

------
Ghostium
"Non-performant features have been removed or replaced where an alternative
solution is easy to adopt without too many changes." Sound for me like preact
([https://github.com/developit/preact](https://github.com/developit/preact))

~~~
k__
Same API as react? sounds nice.

What did they left out?

~~~
thiswasprobably
"but only the modern (ES6 Classes and stateless functional components)
interfaces"

~~~
k__
Seems nice. Cut down my JS size by 50%

------
psibi
What does isomorphic library mean in the context of Javascript ecosystem ?

~~~
ghh
Being able to run the same code both on the server side (nodejs) and the
client side (browsers).

------
CognitiveLens
Events + callbacks are great for keeping with the conventions of the existing
(ancient) DOM APIs, but I was hoping that a new, 'modern' framework would be a
little more ambitious by making everything promise-based.

------
z3t4
I'm trying hard to figure out why someone want to use something like this or
React, when vanilla HTML, CSS and JavaScript seems much easier and more
performant. The only thing I can think of is that appendChild is a bit
tedious, but createClass seems even more boilerplate.

~~~
dangoor
The vanilla way tends to result in state spread out throughout your JS and
DOM. React UIs act like predictable functions: you describe the UI you want
with your current state as the input and React makes the visible UI match
that.

~~~
z3t4
I think this is a JQuery problem, as it makes complexing state the path of
least resistance. i.e. modifying the DOM directly instead of via functions.
Resulting in code that is hard to test or debug. React seems to fix this,
witch makes it a good argument on why to use it. My counterargument for
"vanilla" JS/HTML is that you can refactor the bad parts. But you can't get
rid of React, or you would have to rewrite your whole app! Like when the next
JS fashion/framework comes. _grin_

~~~
dangoor
React itself is just the view. You can replace your template language without
redoing everything if you want. Khan Academy, for example, still has some
Backbone views that render with React. We also have some Handlebars templates
that we haven't converted over yet. That's all peacefully coexisting, though
we'd love it if all of our views were React and more of our data handling was
just pure functions.

------
tacone
Quite honestly my problem with react is the gzipped size, not the performance.
What's the size of the browser bundle of this library?

~~~
xaduha
Look into preact + buble ES2015 compiler then, should be small enough

[https://github.com/developit/preact](https://github.com/developit/preact)

[https://gitlab.com/Rich-Harris/buble](https://gitlab.com/Rich-Harris/buble)

my app.min.js.gz is 6.2K for some basic stuff including preact-router

[https://github.com/developit/preact-
router](https://github.com/developit/preact-router)

------
ausjke
What is the difference comparing to vuejs?

~~~
JSQuagmire
One major difference being that Vue.js doesn't really quite support TypeScript
even with d.ts files provided. It will work only to a point until things fail
to typecheck due to generative aspects of Vue's API.[1]

I think a useful comparison is taking a look at t7[2], trueadm's template
library. Last I knew, it wasn't ready for use with Inferno yet, but that is a
peek at the direction it is heading. It's rather similar to Vue's templates
minus the v-directives magic in favor of leveraging JS for things like control
flow.

I'm not 100% sure I'm sold on it, myself, as I rather like beating out Vue
templates in Jade rather than doing everything in JavaScript with template
strings. That being said, I haven't directly tried to implement anything with
Inferno or t7 yet to turn in an informed opinion on working with it.

Inferno is one of the few other library than Vue I'd even bother looking at,
however, at this point in time. They both aren't horribly bloated, are rather
quick and have a mostly sane model to work with. Cito.js[3] is also
interesting and works with t7, if you're looking for even less frills.

It is also worth noting that if you care about licenses, Vue is MIT and
Cito.js and Inferno are using a much more heavily restrictive license, MPL
2.0, which will matter if you're a commercial developer doing standalone apps.
For this reason alone I have to throw Inferno and Cito.js into the trash at
work.

[1]:
[https://github.com/vuejs/vue/issues/478](https://github.com/vuejs/vue/issues/478)

[2]: [https://github.com/trueadm/t7](https://github.com/trueadm/t7)

[3]: [https://github.com/joelrich/citojs](https://github.com/joelrich/citojs)

~~~
rpwverheij
ah thank you for the summary of the licences. that moves inferno off the table
for me too. sadly though, cause I was really getting interested with it being
written in typescript.

~~~
skrebbel
I dont understand. Afaict, MPL only requires you to publish the _changes_ you
make to MPL'ed libraries, not all source that uses it. Why does that stop you
from using Inferno?

~~~
JSQuagmire
It is the difference between amending documentation (MIT) and producing
infrastructure (MPL/LGPL) to ensure that whatever is currently in-tree and
covered by the license is exactly what is available for download in the event
anyone ever patches it... else you are out of compliance. It isn't just
changes, either, it's the files in their entirety.[1]

In a perfect world, no company would balk at having a GitHub account and
having a public fork available, but many companies out there right now are
still rather conservative about these things. Some barely use source control.
MIT is simply one of the easiest licenses for these places to comply with. In
my personal experience working at unglamorous places like these, they're fine
returning patches as long as they never have to think about the legal
implications or feel like there's a burden for using the code in the first
place.

The MPL is a poor choice for this sort of code because it makes the assumption
that distribution is a given and will happen automatically, but if you're
doing application development rather than web development that simply is not
true that the code will always be a 'View Source' away. There are certainly
applications where this license would be more appropriate, but I do not think
an isomorphic vDOM library would be one of them, since this is rather
foundational glue.

It would be rather nice if trueadm would reconsider, if possible.

[1]: [https://www.mozilla.org/en-US/MPL/2.0/](https://www.mozilla.org/en-
US/MPL/2.0/)

[1a]: [https://tldrlegal.com/license/mozilla-public-
license-2.0-%28...](https://tldrlegal.com/license/mozilla-public-
license-2.0-%28mpl-2%29)

~~~
trueadm
Thanks for filling me in on the details of MIT vs MPL. I'll switch over to MIT
now that I know this.

~~~
JSQuagmire
Fantastic, thank you so much for the hard work!

------
amelius
But does it have something similar to React Native?

~~~
formula1
This was a problem I was trying to solve as well and theres a pretty elegent
solution that this project has implemented partly already. The "render to
string" is also a proof of concept that the indicates "unknown" types can be
fullfilled by a "renderer". So long as he allows generic "renderers". Within a
more free form environment like nativescript[ 1], this library can be one of
any that can be used. I was planning to implement blessed and nativescript uis
but these can often be very painstaking tasks. If the developers on this
project are committed, the sky is the limit!

[1] [https://www.nativescript.org](https://www.nativescript.org)

~~~
Drdrdrq
I didn't know about nativescript before, thanks for bringing it to my
attention! That said, it looks like nativescript promotes single code for
multiple platform, which means the app won't look awesome in any of them
(examples from history: phonegap, java awt). I would be much more comfortable
with it if I could just use JS to access native controls and style them using
the established (platform specific) methods. I am guessing css will never
support each and every widget property... Is this approach possible with
nativescript?

~~~
formula1
Tbh, Im very early in my nativescript experiences (though I do believe in the
project). But I believe these are some examples you are looking for

[http://docs.nativescript.org/ui/placeholder](http://docs.nativescript.org/ui/placeholder)

[http://docs.nativescript.org/core-concepts/accessing-
native-...](http://docs.nativescript.org/core-concepts/accessing-native-apis-
with-javascript)

[http://docs.nativescript.org/runtimes/ios/marshalling/Marsha...](http://docs.nativescript.org/runtimes/ios/marshalling/Marshalling-
Overview.html)

[http://docs.nativescript.org/runtimes/android/marshalling/ov...](http://docs.nativescript.org/runtimes/android/marshalling/overview.html)

[http://docs.nativescript.org/plugins/plugins](http://docs.nativescript.org/plugins/plugins)

------
elliotec
What is this solving?

~~~
trueadm
It's solving performance issues that React and other virtual DOM libraries
currently suffer. This is massively important for low power mobile devices.
It's not an ego driven project, all research is going back into the open-
source community to make better libraries and implementations inclusion React.

~~~
spriggan3
> It's solving performance issues that React and other virtual DOM libraries
> currently suffer.

But isn't "performances" the point of React? As I understand things, people
were moving from AngularJS to React because the virtual DOM was supposed to be
the most performant technique to handle UI mutation and rendering.

So what is the reality behind the supposed speed of React ?

~~~
shados
Performance was never the point of React.

The point is to be able to (from a developer's point of view) re-render
"everything", with every change, top down, without having to worry about the
details. Doing that normally would be horribly slow, so React makes it
adequately fast.

So it's not "super mega high speed lib". It's "Gives you the ability to have a
function which, given argument, renders an entire app, and can be called over
and over and over" at pragmatic speed, allowing for easier code to reason
about.

If your primary goal is performance above all else, it's actually not that
great a library.

~~~
zghst
That whole goal was performance driven...

~~~
mercurial
What makes you say that?

------
edoceo
Would like to see comparison to RiotJS

------
FLGMwt
As a curiosity, how do we feel about changing the names of the lifecycle
methods from "lifeCycleEvent" to "onLifecycleEvent"? Looks like a lot of stuff
is pretty transparently portable from React code, I think it's curious this
got changed.

------
aeosynth
> Inferno uses intelligent techniques to separate static and dynamic content.
> This allows Inferno to only "diff" renders that have dynamic values.

Can this be expanded? If/when the intelligent diffing fails, I'd like to know
how to fix it.

------
formula1
[https://github.com/formula1/tEmbO?files=1](https://github.com/formula1/tEmbO?files=1)

Was doing something similar for a while. Very cool stuff! Excited to see where
you take it!

------
Keats
It's still in progress but it gets better on each release. Even better that
the new version is using TypeScript!

~~~
trueadm
TypeScript not only helped improve Inferno's with quality and read-ability of
code. It can potentially help produce highly optimal output (bundles) with
Google's Closure Compiler. In the future it may even help created optimised
WebAssembly output. It's an exciting time :)

~~~
nippur72
I've just opened the GitHub repo and I see no trace of TypeScript, no .ts
files anywhere

~~~
timdorr
Wrong branch. Check 0.8-dev:
[https://github.com/trueadm/inferno/tree/0.8-dev/src](https://github.com/trueadm/inferno/tree/0.8-dev/src)

~~~
nippur72
fine, thanks. TypeScript makes it even more interesting. I am going to make
some tests to see if Inferno can replace React when working with react-
templates.

------
jyriand
Any specific reason it is called Inferno? Somehow I can't stop thinking that
after Inferno comes Purgatorio and Paradiso.

~~~
ajro
And the name is already taken:
[https://en.wikipedia.org/wiki/Inferno_(operating_system)](https://en.wikipedia.org/wiki/Inferno_\(operating_system\))

~~~
trueadm
React was also taken before Facebook used it. It's not an issue in my eyes.
Inferno was used to emphasise performance and power.

------
ben_jones
React, so great people are already re-writing it.

------
hackim
Interesting...

------
dyscrete
I like how javascripters use `const` everywhere they can except actual
constants!

[https://github.com/trueadm/inferno/blob/master/src/DOM/mount...](https://github.com/trueadm/inferno/blob/master/src/DOM/mounting.js#L65)

