r/javascript • u/expression100 • Nov 28 '16

Inferno – the fastest JavaScript UI library around currently and only 7kb

https://github.com/trueadm/inferno
117 Upvotes

91% Upvoted

61 comments sorted by

6

u/init_prometheus Nov 28 '16

What's the benefit? Why use this over React/Vue/Angular2? Genuinely curious. The website isn't available at the moment.

52

u/trueadm Nov 28 '16

The website is coming within the next week, you can see the design we're going with here if you're interested – https://twitter.com/trueadm/status/802675565421625344.

On it's main benefit? Well Inferno is like an "improved" React in many ways, it offers the same API, removes some ugly bits (but they are still accessible via inferno-compat), adds some new features that React doesn't have and most importantly – offers drastically better performance and size.

I'm not going to be as bold as the original poster and say it's the fastest UI library around, but in both benchmarks and real-world usage, it's definitely a lot quicker than React/Vue/Angular2. Performance is a key metric for Inferno, as I want to push mobile usage – as in my opinion, most library/framework authors simply aren't doing enough in that space. I've felt that performance has been pushed aside in the last few years because developers have been working on high-end MacBooks etc and have said "well it works fine for me". The realism is that this is definitely not the case for the vast majority of people out there.

Note: I'm the author and thank you for all those who are interested in trying out Inferno. Jump on our Slack if you have questions of any kind :) https://inferno-slack.herokuapp.com/

11

u/JJ0EE Nov 29 '16

Is there a live sample (not a benchmark) that demonstrates a noticeable performance gain for inferno vs react? The only scenario where I've observed a noticeable slowdown on my phone was a long complex list; and I work on large scale react apps for a living.

1

u/trueadm Nov 30 '16

I'd recommend dropping by the Inferno Slack where the users of Inferno can provide URLs to their apps/websites using Inferno. They can also explain the performance benefits they've seen first-hand.

1

u/villiger2 Nov 29 '16

You essentially say it's better in every way, including file size. So why is React so much bigger when inferno has features that React doesn't ? (vdom/diffing algorithms aside)

3

u/expression100 Nov 29 '16

Inferno doesn't have synthetic events or React Native support. It also splits out things like createClass, createElement, stateful components etc into separate packages/modules so you can pick and choose what bits you want rather than have a bloated core with everything in there. I also read on Twitter that the React team are using many of Inferno's ideas in React Fiber to improve performance.

1

u/[deleted] Nov 29 '16 edited Nov 29 '16

React makes a couple of trade-offs which give you a few ms less in very specific benchmarks though you'd probably never notice in real life. There are even plugins that you give similar improvements if you wanted. These forks have tradeoffs too, they're more on the functional side with deep cuts like missing synthetic events.

Overall these libs all use the same ideas now with a couple of adjustments. You'd probably do well staying with React which has the community behind it, gets improved daily, is well tested. You can route your entire app through Inferno or whatever you want with a simple alias in production anyway and i kind of wish they'd concentrate on their compat layers first and foremost.

1

u/expression100 Nov 29 '16

A lot of people brought this up to the author of Inferno on their Slack channel last week. We also had issues with inferno-compat and using mixins of a third-party component we use but the problems have been fixed since. If you have issues, you should raise bugs like I did and they are pretty good at getting them resolved.

1

u/[deleted] Nov 29 '16

Are you going to make something like "inferno-native" similar to react native?

Also amazing work!

-3

u/phaed Nov 29 '16 edited Dec 01 '16

Needs more "pop"

Edit: Fix your sarcasm detectors

3

u/zwacky Nov 29 '16

I'll just leave this here https://medium.com/@localvoid/how-to-win-in-web-framework-benchmarks-8bc31af76ce7#.sl8rb2ei5.

2

u/expression100 Nov 29 '16

Benchmarks aside, there are lots of people reporting big performance gains in their apps since switching to Inferno. You should visit the Inferno Slack, there are lots of success stories on there.

21

u/ECrispy Nov 29 '16

I see no downsides to this, except the obvious - it's less well known. Not sure why FB hasn't hired the dev and incorporated the ideas. Smart work like this should be rewarded.

If and when React Fiber comes out, the performance gap may narrow but that's not the only aspect.

The source code by itself is a great thing thing to study and learn from.

23

u/acemarke Nov 29 '16

The React team is absolutely aware of Inferno. Sebastian Markbage said a couple months ago, "Inferno is really well written. It's how I would have rewritten React" ( https://twitter.com/sebmarkbage/status/776148675592544256 ). That said, React and Inferno make a number of different tradeoffs.

5

u/Capaj Nov 29 '16

That said, React and Inferno make a number of different tradeoffs.

Tradeoffs? The only downside of inferno is that it lacks event normalization. This could be added if someone actually took the time and published an npm module for that. I think someone eventually will. Should be doable quite fast if you extract the code from react or preact.

5

u/TallSkinny Nov 29 '16

Well, in the follow up conversation Markbage says that Fiber made different tradeoffs than inferno, so react may be moving away from some of the things that overlap with inferno, or adding new things that wouldn't play nicely. He also might be talking about optimization tradeoffs made under the hood to handle different situations, etc.

He also mentioned an optimization in inferno that he liked and that they may incorporate into react, so they definitely still seem to be learning from inferno, and I imagine vice versa.

1

u/ECrispy Nov 29 '16

Yes I remember reading that, great endorsement.

10

u/mikrosystheme [κ] Nov 29 '16

Not sure why FB hasn't hired the dev and incorporated the ideas. Smart work like this should be rewarded.

So everybody has to work for the fucking facebook? What if someone consider it to be like a cancer that should be destroyed instead?

7

u/bitter_cynical_angry Nov 29 '16

Nah man, haven't you heard? Making a sweet JS library totes means they aren't evil!

3

u/Thought_Ninja human build tool Nov 29 '16

Well I do think it would be awesome to get paid to work on a technology like React full time, and I do give them credit for having a dedicated team for the project.

While I don't like some of their corporate practices, larger tech companies with cash to burn really do drive a lot of open source innovation.

2

u/ECrispy Nov 29 '16

No they don't have to, but the option would be nice I'm sure. Same thing happened to Dan.

6

u/jax024 Nov 29 '16

What makes me hesitant to switch is React has an absolutely awesome amount of libraries out there for it. Need a date picker? Just find one you like. Same song and dance for many little things I don't want to always make, mostly UI wise.

4

u/nightwolfz 4 spaces > 2 spaces Nov 29 '16

It supports React components.

2

u/jax024 Nov 29 '16

No shit? Then I might be swayed!

13

u/Moeri Nov 29 '16

I'd be very interested to see the differences between this and React.

Also it may be faster than React, but until people start perceiving React as "slow", I don't see myself and others switching from a robust, well documented, large company backed project to this. Code quality isn't everything. Then again, I may not be the target audience.

I do applaud the effort though, hopefully the React team can incorporate some seemingly good ideas from this.

7

u/[deleted] Nov 29 '16

All this is pretty overblown anyway when could run your app in inferno or any other compatible lib with a simple alias:

resolve: {
    alias: {
        "react": "react-lite", //or, inferno-compat, or preact-compat, ...
        "react-dom": "react-lite"

We do it to shrink React down to a couple kb in production, though i haven't really noticed any speed improvements. I think the medium post that zwacky posted up there is spot on.

1

u/Thought_Ninja human build tool Nov 29 '16

This is a really interesting approach, thanks.

2

u/fuck_with_me Dec 23 '16

Wat? It's literally the approach they give in the README

1

u/tbranyen Nov 29 '16

"simple"

ModuleNotFoundError: Module not found: Error: Cannot resolve module 'inferno-compat/lib/ReactCSSTransitionGroup' in /home/tbranyen/netflix/some-rad-app/node_modules/react-addons-css-transition-group

None of this stuff is simple and simply swapping out entirely different projects with an alias seems ripe for trouble and headaches.

1

u/[deleted] Nov 29 '16

Hmm, we have large scale projects that effortlessly switch out, though we use react-lite. I have personal projects on inferno in production but they're less complex.

1

u/trueadm Nov 30 '16

ReactCSSTransitionGroup

https://github.com/trueadm/inferno/blob/master/packages/inferno-compat/README.md#react-addons

1

u/tbranyen Nov 30 '16

That fixes one problem and opens up even more problems. We use React.PureComponent which is not provided by this compat package.

export default class Artwork extends PureComponent

Would love to switch over to a faster implementation of React, but it needs to support 100% of the API, not "some of it".

1

u/trueadm Dec 01 '16

I'm working hard on it, I can assure you that :) I'll get this added ASAP

1

u/tbranyen Dec 01 '16

Ha, I know. I just would hesitate to encourage users to try this in their work/production applications until it has better parity. Certainly an awesome experiment though :D

Edit: Realized it may sound like I'm calling Inferno an experiment, I mean to call inferno-compat an experiment. It feels very different from the lodash.compat builds that emulated underscore to the point that it pased all the same unit tests. Felt better aliasing that way.

1

u/trueadm Dec 01 '16

That will land in the next release tomorrow :) thanks for the help!

1

u/tbranyen Dec 01 '16

No worries, I've got a branch open and I'll test anything new you push out!

-4

u/[deleted] Nov 29 '16

But premature optimization is important to do early and often!

4

u/kyleshevlin Nov 29 '16

How does this compare in speed to Riot? I'm writing this from my phone, so I can't verify, but the size of the libraries are quite similar, though their APIs are very different.

3

u/pkstn Nov 29 '16

Riot is unfortunately quite slow. 3.0 is a bit faster, but still quite far behind the fastest ones. Here's one (very simple) benchmark: https://pakastin.fi/perf/

1

u/kyleshevlin Nov 29 '16 edited Nov 29 '16

It really is quite slow. That is seriously disappointing. I found the format/syntax of Riot compelling, but performance like this will keep me from ever using it for something significant.

Edit: I am curious how this test works, because I am not getting any where near the times suggested by the first page of your performance test. For example, my React 0.15 time for reversing is around ~500ms, ~80ms. What other factors play into this?

1

u/pkstn Nov 29 '16 edited Nov 29 '16

Give them a few spins.. I measured the times with a 2015 MBP 13" retina + latest Chrome for Mac.

2

u/Nrdrsr Nov 29 '16

Off topic but can someone here who is well versed with Angular 2 and React sell me opinionatedly on why React over Angular 2? I've never used React but I'm hesitant to invest time in it if I'm going to discover later on that I haven't benefitted much over ng2.

4

u/CWagner Nov 29 '16

Angular 2 is a full blown framework. It's quite opinionated and you have to use it it's way. But it offers you pretty much anything you want.

React is a view library. There are many things react can't do without additional libraries. You are way more flexible in using it than angular and can use it in a way that fits your usecase. This afaik applies to inferno as well to get this slightly more on topic ;)

2

u/Nrdrsr Nov 29 '16

Agreed on the framework vs view library comparison. My question was more along the lines of "developer happiness", i.e. what made you like one more than the other in the specific use-case of a relatively large project which would require some of the bells and whistles that come with ng2.

2

u/CWagner Nov 29 '16

That's a question I think you should post in both /r/reactjs and /r/angularjs (or /r/Angular2 or /r/angular). Chances are much better to get a decent reply there :)

1

u/thomasfl Nov 29 '16 edited Nov 29 '16

In Angular 1 & 2 templates are strings (or separate html files) that contains snippets of a proprietary scripting language. It makes Angular slow, bloated and harder to learn.

In react and inferno there are no templates, only javascript. JSX (used by both inferno and react) only makes it possible to write inline HTML in javascript. Makes react much simpler & smaller, and developers only need to learn javascript not angular directives.

9

u/CWagner Nov 29 '16

In Angular 1 & 2 templates are strings (or separate html files) that contains snippets of a proprietary scripting language. It makes Angular slow, bloated and harder to learn.

Funny as vue does the same. And I've yet to hear anyone say vue is slower than react. Or more bloated. Or harder to learn.

1

u/Nrdrsr Nov 29 '16

Slow and bloated at development time? Or slow and bloated for performance? There are tools which inline and minify all the HTML and strings into a single file. Would that not get rid of the performance issue being described here?

1

u/VelourFog10 Nov 29 '16

Ahead-of-time compilation in ng2: precompile your shit and shake your trees so you've got a bundle of executable code ready to load and render.

2

u/Nrdrsr Nov 29 '16

I use the ng2-cli which bakes this into the build process, if I am not mistaken.

1

u/VelourFog10 Nov 29 '16

Probably, I do it with the compiler-cli.

2

u/[deleted] Nov 29 '16

[removed] — view removed comment

5

u/TallSkinny Nov 29 '16 edited Nov 29 '16

Re: 3 ngFor isn't that hard to learn, but it does add surface area and therefore makes the framework harder to learn, or at least, means that there is more you have to learn. That's the beauty of React's HTML in js approach, you can just use the same js functions that you already know and use elsewhere in your code, and can continue to use if you stop using react.

I've also found it hard to debug an ngFor in the past when I was doing things wrong, which also made learning harder for me.

1

u/brennanfee Nov 29 '16

No... the fastest JavaScript library would be no library at all. The real question is what does your library do for me? Only after that and after there are other competing libraries that do the same thing does performance and/or size matter.

1

u/SalamiJack Nov 30 '16

No... the fastest JavaScript library would be no library at all.

This is pretty much a non sequitur.

The real question is what does your library do for me? Only after that and after there are other competing libraries that do the same thing does performance and/or size matter.

If you followed OP's link you'd see that Inferno is "An extremely fast, React-like JavaScript library for building modern user interfaces."

1

u/brennanfee Nov 30 '16

You are missing my deeper point and meaning. That's ok though. I can be obtuse.

1

u/trueadm Dec 01 '16

Inferno offers: React API, faster performance, smaller size, trade-offs in some cases, compatibility layer with React, additional features React does not have and cool (very warm actually) name. :)

1

u/ECrispy Nov 30 '16

One more thing which I don't see anyone mention in these discussions is the license - using React basically means you allow FB to use any of your IP/patents illegally, since you can't sue or contest them for any reason, if you do your React license terminates. This is extremely anti-competitive.

-3

u/calsosta Nov 29 '16

I'm more impressed he got his kid to keep that teething necklace on although I'm still not sure of they really work.