
InfernoJS – A JavaScript library for building powerful user interfaces - expression100
http://infernojs.org/
======
cheapsteak
Previous discussion:
[https://news.ycombinator.com/item?id=11837082](https://news.ycombinator.com/item?id=11837082)

------
tzaman
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 more (while remembering I haven't even
given a try to redux-saga), and maybe I should try another stack with
Inferno/Cerebral?

Why are you doing this to me, JavaScript?

~~~
wwalser
Can you build something that'll make your customers happy?

Then your stack is good enough.

~~~
kennysmoothx
I like this a lot.

Your customers have no idea what a stack is, they, as well as the rest of the
internet, just see the finished product.

Thats what matters most.

~~~
wwalser
I'm a software engineer turned self-funded founder. The amount of stuff that's
critical to early success and has absolutely nothing to do with technology
really puts decisions like what stack to use into perspective.

Rewriting using another stack is N weeks/months that I'm not spending on
writing, distribution, iterating on paid marketing, cold emails, calls with
customers etc. I used tech that I knew I could scale into 1k users, likely
more around 50k but we'll see. I've had zero technology based regrets aside
for attempting to use Firebase for something that it wasn't suited for early
on.

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

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

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

------
trueadm
Just a note to people expecting an actual website – we are in the process of
building one and you can see what it will look like here:
[https://twitter.com/trueadm/status/802675565421625344](https://twitter.com/trueadm/status/802675565421625344)

Furthermore, if anyone has any questions feel free to ask away (I'm the author
of Inferno). :)

~~~
odbol_
Why is a blank under-construction website on the frontpage of Hacker News?
This site sometimes...

~~~
trueadm
I never posted the Inferno website URL to Hacker News, someone else did. We
should be going live with the new website in the coming week, I was hoping to
post it once that had been done!

------
bsilvereagle
Might as well link to the GH page (which is available by clicking the icon on
the linked page):
[https://github.com/trueadm/inferno](https://github.com/trueadm/inferno)

~~~
walid
Frankly I think this posting of github pages instead of the authorative source
is inappropriate. I see it a lot on HN and find myself having to check that
this is the official repo by going to the original website. If you know it you
don't need to be told about it but if it's being posted to get it to people's
attention then the canonical source is the right link even if it only has a
link to github.

~~~
chipgap98
You realize the site just links to the github repo, right?

~~~
detaro
> _then the canonical source is the right link even if it only has a link to
> github_

I assume they realize, yes.

------
aargh_aargh
Considering the lifetime of JS frameworks nowadays, the website has been
"coming soon" for ages.

[http://web.archive.org/web/*/http://infernojs.org/](http://web.archive.org/web/*/http://infernojs.org/)

~~~
overcast
Doesn't mean much. I purchase domains for rainy day ideas all the time.

~~~
chrshawkes
Go back to the original check-in to this repository it was clear this project
wasn't planned out from jump street.

------
dirkg
I don't understand the negativity. This isn't buzzfeed or reddit, the target
audience is supposed to be people who are already devs and not need
handholding.

So there's no website. So what? The github page clearly explains what it is,
who its for and how it works. Focus on the product, talk about its pros/cons
without trying to distract from the core issues.

e.g. the size complaint - almost every article about React/Angular/Vue will
compare the lib sizes and impact on loading etc - Inferno is faster and
smaller. Why complain?

The focus of the library seems to be speed, a minimal implementation that is
still fully API compatible with React, which is no mean feat. And on top of
that it happens to be the fastest UI framework. Give some credit to the
author, FB has already said they might be incorporating ideas from it.

------
trueadm
If anyone has any further questions/queries/ideas/rants you can jump on the
Inferno Slack - [https://inferno-slack.herokuapp.com/](https://inferno-
slack.herokuapp.com/).

The team and I would love to hear from you. We want to make Inferno better and
we believe in doing so, we can start a shift in the community that starts to
realise that performance on mobile with the current state of libraries and
tools is not good enough. This was always the primary goal for why I began
Inferno – about 2 years ago.

------
quickben
Minor note: the linked url brings to a placeholder page.

~~~
walid
The graphic on the page links to the github repo.

~~~
rickyc091
Thanks! That definitely wasn't apparent to me. I think the problem is with the
UI in that it states "New Website Coming Soon." I quickly exited the tab and
did a search on google for the github repo.

------
mstijak
Cx widgets mostly work with inferno-compat. There are still some issues to
iron out, but hopefully that will be fixed with 1.0. Performance improvement
over React is clearly visible, especially on large unbuffered grids:

[http://cx.codaxy.com/v/inferno/docs/examples/grid/dynamic-
gr...](http://cx.codaxy.com/v/inferno/docs/examples/grid/dynamic-grouping)

[http://cx.codaxy.com/v/master/docs/examples/grid/dynamic-
gro...](http://cx.codaxy.com/v/master/docs/examples/grid/dynamic-grouping)

I think that inferno-compat parity with React should be Inferno's top priority
now. The performance is already great.

------
joobus
Inferno seems to be very comparable to Riot.js, only Riot is more mature, has
event delegation and a router, and is only 9.5k vs Inferno's 7k. And riot has
an actual web page.

[http://riotjs.com/](http://riotjs.com/)

~~~
shados
last I checked, Inferno was a React "near drop-in" replacement. So not the
same at all, unless you look at it in a vacuum.

~~~
joobus
Nowhere does the inferno docs say only people who already use react should use
it. As a library for creating "modern user interfaces", it is in direct
competition with riot.

------
wheelerwj
no one is going to comment on how a library for powerful UI's has an under
construction landing page that only links to github?

------
wje
Unfortunately unrelated to Inferno the operating system, which was warped into
running in a browser, many moons ago.

[http://www.vitanuova.com/inferno/](http://www.vitanuova.com/inferno/)

~~~
SixSigma
The Internet Explorer ActiveX plugin version of Inferno didn't get much
traction.

Although I did think "ooh, don't tell me someone has compiled Inferno OS to
Javascript, that would be awesome" nope.

~~~
cestith
I think porting Inferno to JS is Plan 11.

------
iamleppert
It's disingenuous for the authors to claim this is a near "drop-in"
replacement for React. Just because it works now for (likely) some limited
surface area test app doesn't mean it will work in all of React's weird nooks
and cranes, or its constantly changing APIs or huge stack of dependent
behaviors it has inherited from its ever-changing dependencies.

Clearly, the authors don't have much experience in this regard to make such
claims. Caveat emptor.

~~~
trueadm
That's why I claim near rather than perfect. It's a constant work in progress,
that's the challenge :)

------
coldcode
Man I can't keep up with all of these. Is there a list that anyone is keeping
track of for javascript UI frameworks? I suppose it would require daily
updating.

~~~
knicholes
I like to refer to [http://stateofjs.com/](http://stateofjs.com/) and
[http://todomvc.com](http://todomvc.com).

------
nkkollaw
Sorry, can someone do a ELI5?

What does it mean to be React-like? Is it a drop-in replacement? Are React
components compatible? Or it just looks like React (it does)?

I'm going absolutely crazy trying to keep up-to-date with all frameworks
coming out nowadays.

Yesterday it was Svelte, today it's Inferno.

What's good about using this instead of React? 3k of parsing instead of 40k is
a huge improvement, but can we still using stuff that was made for React?

I'm lost.

~~~
trueadm
You totally can use Inferno. You can use a package on NPM called "inferno-
compat" to alias out React to Inferno via Webpack/Babel/Browserify if you want
to. Alternatively, you can use Inferno as is and it has JSX Babel plugin, all
the same top-level APIs and has the same ES2015 components as React (although
we've put them in their own package called "inferno-component", as some people
don't use them).

I hope that helped – I'd recommend jumping on the Inferno Slack if you'd like
to know/understand more: [https://inferno-
slack.herokuapp.com/](https://inferno-slack.herokuapp.com/)

~~~
nkkollaw
Thanks.

------
findjashua
if you don't have the site ready, it'd make more sense to just link to the
repo

------
JustSomeNobody
Where is this being used?

------
SamBam
What's it like to re-write a React application into Inferno?

~~~
trueadm
You really don't need to do this to play with Inferno, try using `inferno-
compat`.

------
spankalee
There are many reasons why Web Components are important and framework
proliferation is just one of them.

~~~
magic_quotes
Don't forget there are many unpopular (wdsl) and dead (xhtml, e4x) standards
out there already. There is absolutely no reason to believe that web
components will have a better track record.

~~~
spankalee
Of course there're reasons to believe it: Web Components solve some critical
problems, All the browsers are in support of the standards and implementing
them, we've had very good uptake with Polymer, other Web Component frameworks
are popping up at places like Atlassian, and many large companies like ING,
IBM, GE, Bloomberg, Salesforce, and of course Google - with YouTube and more -
moving to Web Components.

Relevant to this discussion, Web Components will make it possible for less
mainstream frameworks to get a foothold in real applications by not being
locked out by proprietary silos.

~~~
magic_quotes
> browsers are in support of the standards

Well, realistically speaking, web components consist of a bunch of different
specs and each specification should really be considered on its own merits.
Shadow DOM and Custom Elements are mostly ok. HTML Imports spec looks like it
was created with the simple "include jQuery widget on the page" use case in
mind and doesn't consider anything else. Node.js/npm/CommonJS ecosystem, es6
modules — it's like nothing of this even exist. This is obviously not good
enough and that's why Mozilla decided to not support this thing.

> being locked out by proprietary silos

That's a really mean thing to say about an open-source javascript library.
Especially considering that Inferno is a _reimplementation_ of React API. I
actually think Fb should make React API into its own mini-spec (like JSX or
GraphQL) if only for trolling "muh web standards!" people.

------
HugoDaniel
Is there any place where the community usually hangs ? Some chat room or forum
? Thanks

------
kimshibal
Now, it's all about Svelte vs Inferno. I like Svelte more than Inferno.

~~~
epmatsw
It's all about a Svelte, a framework that came to light a week ago and isn't
in production anywhere that matters? Come on...

~~~
TheCoreh
A week is about 6 months in JS-years.

~~~
Klathmon
No it's not, I hate when people spread this shit.

Inferno JS is probably one of the newest "frameworks"/large-libraries that I
would even consider using, and it's over a year old already.

React has been around in some fashion since 2011, and was open sourced in
2013.

Angular 1 has been since around 2010 IIRC. Angular 2 since around mid-late
2015.

Ember since before mid 2014.

Yes, some terrible developers like to chase the "new cool thing" every few
weeks, but that doesn't mean that you need to, and it doesn't mean that there
aren't stable, powerful, good choices that have been around for years.

------
iLoch
Cool, so it's React but presumably they've stripped out many of the things
that make React enjoyable to use in order to satisfy some arbitrary file size
metric. Why isn't this library 1kb, like LatestHotFramework.js?

~~~
coltonv
"but presumably they've stripped out many of the things that make React
enjoyable to use in order to satisfy some arbitrary file size metric"

Why make this claim without looking yourself? You could validate that
"presumably" by just looking at the docs, but instead you get sassy about it.

If you look at the docs, you'll see that the API is almost exactly the same.
You really don't lose any features from switching to Inferno from React, what
you lose is the React community.

I say this as an avid React user. Don't discredit something until after you've
dove into it a bit.

~~~
iLoch
What do you think the extra 38kb of code is for? My point of view is, you've
got a company with thousands of employees who work with a library every day
and core teams dedicated to its improvement. Their requirements for speed and
bandwidth far exceed our own as they reach further into the nth percentile of
users, so you know things like speed and bloat are important for them to cut
out.

What, if anything, is actually gained from a business perspective by reducing
a single library by 38kb? My guess is exactly nothing. And the benefit of
sticking to React is not only the community, but the fact that they actually
own their virtual DOM implementation and actively work to improve it (the
forthcoming fiber rendering engine is a great example of that.)

I'm not hating on new technology, but this isn't actually new. It's a clone
that isn't really bringing anything new to the table, and just muddies the
water for developers. It's like if every few weeks there was a new take on Git
that did practically the same thing but wasn't Git.

We'd be much better off if these people were contributing to React core.
Because if it truly has the same capability as React, you should be able to
shave the 38k off right?

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

~~~
iLoch
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 into that
community. You lose all the benefit. I have no doubt Inferno is faster, but I
suspect you're being disingenuous when you say all the same features are
available.

The trouble I have is not specific to Inferno, but rather the idea that less
and new is better. Eventually, your users will want something that Inferno
doesn't offer, and eventually it will be implemented. And this will happen
more than once, probably to the point where your library, too, is 45kb. So is
all this work and fragmentation and confusion and comparing of benchmarks
really worth it? I think not, unless the technology stands to bring something
vastly different to the table.

The trouble with competing with React in its own space right now, stems from
the vast amount of resources many of companies are putting behind it. You just
can't make a Inferno Native, etc. I think we'd be much better off all working
together on new ideas, not rehashing innovation in order to win benchmark
tests.

All that said, I applaud the effort, as I'm sure this took a lot.

~~~
trueadm
You don't need to necessarily use Inferno in production all at all. If you're
happy with React, stick with it. Inferno can serve to help other authors and
the React team to further improve their tools. This is open source after all,
we can all learn and improve from one another and make even better software.

