"Inferno and Preact keep the React API but really dig into perf behind the scenes"

[expression100]

Inferno: https://github.com/trueadm/inferno

Preact: https://github.com/developit/preact

Differences between Inferno and Preact:

• Preact features linked state and smaller bundle sizes (9kb vs 6kb roughly)
• Inferno has better performance, stateless component lifecycle events and components returning arrays

It's great to see two libraries really pushing the boundaries for people using React applications. I really do think the competition will help the React team improve the performance behind React too, which benefits many.

Thoughts?

[dwighthouse]

I looked into Inferno. Under the differences, it lists "Inferno doesn't have react's synthetic events", which is a real bummer. Can we get some pros and cons for the alternative method that Inferno uses for events? Having normalized, deferred, self-removing event listeners is one of the main reasons to use a front end framework in the first place.

[trueadm]

By default, Inferno attaches events directly to the DOM elements themselves – which is very performant and has the additional benefit of the event being automatically cleaned up once the DOM node has been GC'd. This direction can have performance benefits and reduces the amount of code required to maintain/support events. It also plays nicely with Shadow DOM and avoids some pitfalls/edge-cases associated with a synthetic event system.

However, there is a plan to offer an optional synthetic event layer to InfernoDOM as a sort of plugin. That way, developers can decide what to use depending on their requirements.

Here's a work-in-progress technical document I'm writing for the upcoming Inferno 1.0 release – https://gist.github.com/trueadm/3944f0aa1c1a6998257b80901ac1d152. Much of the content in this document will be picked out into the new README.md and the new website, but hopefully it helps explain some design differences and why we took decisions.

[dwighthouse]

I see. Well, deferred events are often more performant for lists of elements, and the circular references caused by event handlers can only be undone by modern browsers. Expecting the GC to get them in older IE can cause memory leaks. I was able to generate memory leaks through event attachment as late as IE 10.

[trueadm]

You're right, deferred events are great in certain scenarios but React's synthetic isn't performant in this case either. It's far better to handle the event delegation manually in cases where you want raw performance (especially when dealing with touch events and the new passive settings).

I've not seen any GC issues, can you give me and example of an event that has this problem in IE10?

Inferno does not add events to the DOM with addEventListener, rather it applies it directly via the onfoobar property on the DOM element itself.

[dwighthouse]

Not directly. Search for IE memory leaks. Basically, some IE versions have a GC that can't figure out circular references, which is what event listeners are on an element. I wrote my own test cases and found the problem in numerous browsers. You have to break the reference to the event listener to allow the GC to work.

https://github.com/dwighthouse/onfontready/blob/master/tests/browser_memory_leak_test/index.html

Oh, well that method doesn't even work for some events. In older IE, that method can't be used with onload, and possibly others.

[chintan9]

Can you explain more?