What browser versions should be supported?

[mixonic]

Howdy! Similar to https://github.com/krausest/js-framework-benchmark/issues/230, I want to try and make sure the additions I make here are as equitable as possible.

With that in mind, what kind of browser support should we be compiling for? Just latest Chrome, or IE9+, etc?

[krausest]

Good question! I’m not sure if the results can be generalized to other browsers, currently only chrome is in the focus (the other would be firefox but I haven‘t found a way to extract performance data from it). Thus I’d say we require chrome only. If we decide otherwise I‘d say a test to verify that a benchmark implementation runs on all target browsers would be needed. Other opinions?

[gheoan]

Some framework focus on Chrome performance, so it would be interesting to see results from other browsers.

[krausest]

@gheoan: That would certainly be interesting, but I haven't found a good way to do so. Do you have good pointers how to achieve this with firefox?

Until then the only requirement for this benchmark is that the latest stable chrome browser must be supported. Reason: I can neither enforce nor check other requirements and the question what browsers an application should and thus a framework must support isn't in the scope of this benchmark.

[trotyl]

I guess the original question is about what browser should the application support:

With that in mind, what kind of browser support should we be compiling for? Just latest Chrome, or IE9+, etc?

Instead of what browser should be tested for benchmark. So all the apps could have a generalized compiling target (es2017/es2016/es2015/es5).

Currently some of the testing apps are using babel-presets-env resulting in a potentially different compilation level:

"presets": [
  [
    "env",
    {
      "targets": {
        "browsers": [
          "last 2 versions",
          "not ie <= 10"
        ]
      },
      "loose": true,
      "modules": false
    }
  ]
]

I think it's better to require all apps compiling to valid es5 (including es5.1) so the browser optimization could be at same level, this should be easy to achieve, just run an extra e2e on PhantomJS and make sure it's running successfully.

For the performance result on different browsers, it's also an interesting topic, but could be decided later.

[krausest]

@trotyl I'd allow them to support the es feature level of the latest stable chrome version. If for some reason transpiling to es5 yields better results for a benchmark implementation or it's just the way the framework is supposed to be used it should also be allowed to choose an older target. Let's just not hamper using modern es versions.

[trotyl]

@krausest Current output levels are:

Framework	Language Level	Transpiler
AngularJS	es5	By Babel
Angular	es5	By Closure
Aurelia	not fixed but possibily es5	By Babel
Binding.scala	es5	By Scala.js
Bobril	es5	By TypeScript
Choo	es5	By Browserify plugin es2020
CycleJS	es5	By Babel
Datum	es5	By Babel
Dio	es5	By Babel
Dojo	es5	By TypeScript
DomVM	es5	By Buble
Elm	es5	By Elm
Ember	es5	By Babel via Ember CLI
Etch	es5	By Babel
Glimmer	es5	By TypeScript via Ember CLI
Gruu	es5	By Babel
Halogen	es5	By PureScript
HyperApp	es5	By Babel
Inferno	es5	By Babel
Ivi	es5	By Closure
Knockout	es5	By Babel
Marionette	es5	By Babel
Marko	es5	By Buble
Mithril	es5	By Babel
Moon	not fixed but currently es5	By Hand
NX	es2015	By Hand
Petit	es5	By Babel
Pico	not fixed but currently es5	By Hand
Plastiq	es5	By Babel
Polymer	es5	By Babel via Polymer-CLI
Preact	es5	By Babel
Pux	es5	By PureScript
Ractive	es5	By Babel
React-lite	es5	By Babel
React	es5	By Babel
Re-DOM	es5	By Buble
Reflex-DOM	es5	By GHCJS
Riot	es5	By Babel
Rx-DOMH	es5	By Babel
Simulacra	es5	By Babel
SlimJS	es5	By Babel
Stem	es5	By Babel
Surplus	es5	By TypeScript
Svelte	es5	By Buble
Thermite	es5	By PureScript
Tsur	es5	By Babel
VanillaJS	es5	By Babel
Vidom	es5	By Babel
Vue	es5	By Babel

So looks like es5 is currently a defacto standard for all testing apps.

If es5 is not required, we could change the compiling target to highest supported version (es2016 or es2017) and let Chrome optimize them at will.

Otherwise, we should change the level of NX and fix the level of some others to make it fair.

---

I suggest to add a suggestion to README for either:

• A framework should transpile to es5 when possible; or
• A framework should transpile to (or untouched) highest level supported by Chrome.

[trotyl]

For information:

• Babel, TypeScript support targeting es2015 code;
• UglifyJS(UglifyES), Babel Minify, Closure Compiler support minifying es2015 code;
• Webpack, Rollup, Closure Compiler support bundling es2015 code;

It would likely just be a user decision for using es2015 or not (in many of these apps), so I think that should be guided/documented in this project.

[krausest]

@trotyl Thanks for your research! I tend to add the second suggestion to the README.

[krausest]

@trotyl Thought about it again - why "should" and not just "may" it use the highest language level available? Isn't using es6+ attractive regarding the file size? If so the startup benchmark might be enough motivation such that people choose the highest possible level. Maybe I should measure whether the language level has any significant impact on the performance first. Would you think it does?

[trotyl]

Now I think the consistency is possibly too big to go. Some frameworks (like Angular, Glimmer, ivi, Petit-DOM, ...) has es5 and es2015 (or plus) builds released while others have es5 only.

So there will also be composition problem:

• lib es5 + app es5
• lib es5 + app es2015
• lib es2015 + app es2015
• ...

I'd like to not care about them anymore...

[solkimicreb]

Hi, I am the author of NX (which seems like the only non transpiled framework)

I a chose not to transpile it, as it would make a false impression of actually supporting ES5. Most of my libraries use ES2015 Proxies, which can not be transpiled or polyfilled. Transpiling the code won't make it work in older browsers. FYI, this will likely happen with some other popular libraries too. Vue and MobX already plan to migrate to Proxies (with probably a maintained legacy version). If you want to stay future proof, I think it would be nicer to add a badge/disclaimer or separate section for ES2015 frameworks.

Also I had to take some break from NX and I can't continue its development for the next few months too. It is still in beta and I am okay if you just exclude it (delete it) until you decide how to deal with this.

EDIT: I am also authoring React-Easy-State, which is also ES2015 Proxy based. I am only transpiling it to support old tooling (Webpack and Create React App can't minify ES2015 code yet). Once Webpack switches to a newer version of UglifyJS I plan to remove the transpilation from that library too (as it would add literally zero value).

[gheoan]

@krausest here is a benchmark that tests es2015 vs es5 speed.

[krausest]

Resolution: Frameworks can choose any language level or features that works with the following babel-preset-env setting:

"presets": [
        ["env", {
          "targets": {
            "browsers": ["last 1 chrome versions"]
          }
        }]
...
]