Add Inferno + MobX benchmark

[tkrotoff]

Ping @mweststrate @trueadm

[trueadm]

@tkrotoff could you possibly use Inferno 1.0.0-beta21? 0.7 is very old now and will soon be ancient :) ping me if you want some help using it.

npm install --save inferno@beta21 npm install --save inferno-mobx@beta21 npm install --save-dev babel-plugin-inferni@beta12

ping @nightwolfz

[tkrotoff]

@trueadm I've copy-pasted package.json from the Inferno benchmark => identical versions (^1.0.0-beta9)

[trueadm]

@tkrotoff ah sorry, I completely misread the version – just ignore me :) what results did you get out of curiosity?

[tkrotoff]

@trueadm results (runned inside a Ubuntu VM while working):

I guess the day MobX uses Proxy object (see #652) it will be faster/use less memory and provide a better API.

[tkrotoff]

Any news on this?

[nightwolfz]

@tkrotoff With the release of inferno v1, this benchmark should be updated again :)

[leeoniya]

@nightwolfz can you guys also submit a keyed implementation?

[tkrotoff]

this benchmark should be updated again

Won't update it if it's not going to be merged...

[krausest]

I'm hesitating to merge it (similar to #45, although impact of mobx was smaller then). There are already a very large number of frameworks. What unique benefit do you see by adding inferno + mobx?

[tkrotoff]

What unique benefit do you see by adding inferno + mobx?

I wanted to see if MobX could benefit from Inferno good performance claims (like Inferno+Redux benchmark).

Since MobX is very popular (221,096 downloads in the last month, first release in 2015), I guess I'm not the only one interested by this benchmark. Its NPM popularity is equivalent to Vue.js (236,387 downloads, ~2013) and Ember.js (232,811 downloads, ~2011).

=> so yes, IMHO MobX deserves to get benchmarks with the 2 most popular VDOM implementations compatible with it.

PS: MobX is more popular than Aurelia (18,432 downloads), Inferno (18,061 downloads), Preact (16,661 downloads), Riot (13,681 downloads), Ractive (11,317 downloads), Mithril (5,257 downloads), Bobril (1,502 downloads), domvm (261 downloads), Kivi (152 downloads) and all other experimental VDOM implementations included in this benchmark (that most probably no one will ever use except their authors - no offense here). If you are afraid there are too many frameworks in your benchmark, you should start here...

Redux is about 1,303,720 downloads last month.

Charts here: https://npm-stat.com/charts.html?package=mobx&package=vue&package=ember-cli&from=2016-01-01&to=2017-01-14

[leeoniya]

i'll put in my two cents. (i know, no one asked)

this benchmark is not a state management lib benchmark. nor is it a popularity contest. the rules of this bench allow you to bring your own datastore implementation, but it only matters insofar as it improves performance, not incurs overhead (as most of them do).

there are an innumerable quantity of permutations of ui libs + state management libs since many can be used with each other. i would instead argue for also removing the redux variants unless they improve perf of the base UI lib...it's likely that none actually will unless their immutability guarantees come super cheap.

there's certainly room for a separate and useful benchmark that shows perf of popular combos of state libs and ui libs, but they don't belong in the same table as the rest, only adding clutter, IMHO.

scope creep is a thing.

[tkrotoff]

@leeoniya To sum up: as a VDOM dev you're interested in VDOM implementations benchmarks.

Most of the time end users use a state management lib above a VDOM. So you want your VDOM implementation to perform well with popular state management libs.

[leeoniya]

@tkrotoff certainly, i'm not unbiased. however, if you were to use MobX with all of the existing libs (includijg vanilla) you would end up with exactly the same table. my point is that it's a fixed overhead which can easily be comminucated with a single statement for all libs: "add X% perf overhead and Y% mem overhead for MobX v2.6.3".

Adding a state management lib adds yet another factor that, while useful to know, is unnecessary makes a straightforward benchmark more cluttered and harder to interpret. I'm not saying it shouldn't exist at all, just not in the same table.

at the end of the day, i'm just some dude with some stupid opinion. whatever @krausest says goes, and i'm 100% fine with that. i trust his judgement.

[localvoid]

@leeoniya

if you were to use MobX with all of the existing libs (includijg vanilla) you would end up with exactly the same table. my point is that it's a fixed overhead which can easily be comminucated with a single statement for all libs: "add X% perf overhead and Y% mem overhead for MobX v2.6.3".

It is actually slightly more complicated. When mobx or redux is added, it is way much harder to optimize code paths that specific to benchmarks and get impressive results. With some libraries, adding mobx can reveal something that their authors are trying to hide when they trying to convince everyone that they've implemented the fastest web ui library ;)

[leeoniya]

@localvoid

With some libraries, adding mobx can reveal something that their authors are trying to hide

can't tell if you actually have some specific impl in mind or just trolling, with your winkie faces ;) this bench is in much better shape now than it has been since the beginning.

EDIT nvm, i'm slow this evening. though i don't understand the desire to get these mobx impls in here if it does the opposite of prove anything

[krausest]

I'm closing this PR. I don't want to turn this more into a app state benchmark (it's already enough for react).