Bug 170513

I've been coordinating with rniwa@ (and other vendors) as I've been working on updating Speedometer to use the latest version of all frameworks in the benchmark while expanding the workloads it tests. This issue is to track upstreaming this work into Webkit. At present, this work is hosted in a private GitHub repo but we would love to land in trunk so everyone is working off the same canonical version. Given the number of changes involved, rniwa@ suggested trying to land each framework implementation piecemeal. We're happy to do this. I'm also more than happy to welcome help from anyone interested in helping upstream this work as I'm still new to the Webkit contribution process :) More information about the updates to the benchmark can be found below: Speedometer 2.0 is an incremental rewrite of the 1.0 benchmark to both update and expand it’s workloads to better reflect modern patterns, libraries & bundling used in the JS ecosystem. What’s new? --------------------- All Speedometer 1.0 framework apps rewritten for their latest versions. S1 was released in 2014 and included six popular JS frameworks & libraries at the time: Ember, Angular, React, Backbone, jQuery and Flight. Although there have been some large shifts in these libraries over the last two years the benchmark versions have remained stale until now. S2 includes a full rewrite of these apps to use the latest patterns and dependencies for these frameworks. For example, the Ember app was updated using Ember CLI, the now the prescribed way to create new Ember apps in that community. The React app was rewritten with newer best practices and also no longer uses a runtime based JSX transformer (now deprecated). Instead just uses Babel + a build-time Babel-plugin for accomplishing the same. New frameworks and libraries added, including work reflecting modern bundler output The popularity of React has spawned a whole suite of libraries that iterated on it, focusing on different characteristics of performance and lower parse/eval costs and overall developer experience. Two such frameworks are Preact and VueJS (used by and supported by Alibaba). The S2 versions of these apps use Webpack + RollUp (as prescribed by their respective tooling). Vue is predicted to gain significant traction in 2017/18 and is worth tracking. S2 also now tracks state management patterns, via a React + Redux implementation. TypeScript now supported --------------------------------- S2 includes an Angular.js 2.0 implementation transpiled from TypeScript to JS. We believe this to be a common workflow Angular developers will use for new projects in 2017 and transpiled TS code to become more widely used as framework authors warm to it. TypeScript (TS) is a typed superset of JS from Microsoft that required transpilation back to JS in order to be executed. It has been gaining traction in the ecosystem due to considering types as a first-class syntax, generally fast compilation and rich tooling for type-aware autocompletion and error highlighting during iteration. Framework rewrites, such as Angular 2.0 have gone all-in on TS as the default language for their developers and there may be value in engines tracking transpiled TS code. Better reflective of ES2015 code and workflows ---------------------------------------------------- S1 included a vanilla JS implementation. S2 builds on this, introducing an ES2015 implementation taking advantage of features like Classes, const/let, arrow functions and Template strings. Although tracking vanilla ES2015 support has value, the reality is transpilers like Babel have made it trivial to transpile all of your sources back to ES5 for maximum cross-browser compatibility. To reflect this increasingly common workload, S2 includes an ES2015 implementation that uses both ES Modules and has ES5 output generated by Babel. As V8 gains full support for module semantics, we can also include a non-Babelified version of this workload. Future facing ----------------------- We identified functional programming patterns as a set of concepts that aren’t well tracked or optimized for today. Consulting the FP JS community, two primary suggestions that arose were supporting Elm and PureScript, both of which transpile down to JS. S2 includes implementations for both of these. Other alternatives like Om and ClojureScript were considered, but have patterns sufficiently close to the other two that we should be covered.