ES6, ES7, and beyond

The V8 team places great importance on the evolution of JavaScript into an increasingly expressive and well-defined language that makes writing fast, safe, and correct web applications easy. In June 2015, the ES6 specification was ratified by the TC39 standards committee, making it the largest single update to the JavaScript language. New features include classes, arrow functions, promises, iterators / generators, proxies, well-known symbols, and additional syntactic sugar. TC39 has also increased the cadence of new specifications and released the candidate draft for ES7 in February 2016, to be ratified this summer. While not as expansive as the ES6 update due to the shorter release cycle, ES7 notably introduces the exponentiation operator and Array.prototype.includes().

Today we’ve reached an important milestone: V8 supports ES6 and ES7. You can use the new language features today in Chrome Canary, and they will ship by default in the M52 release of Chromium.

Given the nature of an evolving spec, the differences between various types of conformance tests, and the complexity of maintaining web compatibility, it can be difficult to determine when a certain version of ECMAScript is considered fully supported by a JavaScript engine. Read on for why spec support is more nuanced than version numbers, why proper tail calls are still under discussion, and what caveats remain at play.

An evolving spec

When TC39 decided to publish more frequent updates to the JavaScript specification, the most up-to-date version of the language became the master, draft version. Although versions of the ECMAScript spec are still produced yearly and ratified, V8 implements a combination of the most recently ratified version (e.g. ES6), certain features which are close enough to standardization that they are safe to implement (e.g. the exponentiation operator and Array.prototype.includes() from the ES7 candidate draft), and a collection of bug fixes and web compatibility amendments from more recent drafts. Part of the rationale for such an approach is that language implementations in browsers should match the specification, even if the it’s the specification that needs to be updated. In fact, the process of implementing a ratified version of the spec often uncovers many of the fixes and clarifications that comprise the next version of the spec.

Currently shipping parts of the evolving ECMAScript specification

For example, when implementing the ES6 RegExp sticky flag, the V8 team discovered that the semantics of the ES6 spec broke many existing sites (including all sites using versions 2.x.x of the the popular XRegExp library on npm). Since compatibility is a cornerstone of the web, engineers from the V8 and Safari JavaScriptCore teams proposed an amendment to the RegExp specification to fix the breakage, which was agreed upon by TC39. The amendment won't appear in a ratified version until ES8, but it's still a part of the ECMAScript language and we've implemented it in order to ship the RegExp sticky flag.

The continual refinement of the language specification and the fact that each version (including the yet-to-be-ratified draft) replaces, amends, and clarifies previous versions makes it tricky to understand the complexities behind ES6 and ES7 support. While it's impossible to state succinctly, it's perhaps most accurate to say that V8 supports compliance with the “continually maintained draft future ECMAScript standard”!

Measuring conformance

In an attempt to make sense of this specification complexity, there are a variety of ways to measure JavaScript engine compatibility with the ECMAScript standard. The V8 team, as well as other browser vendors, use the test262 test suite as the gold standard of conformance to the continually maintained draft future ECMAScript standard. This test suite is continually updated to match the spec and it provides 16,000 discrete functional tests for all the features and edge cases which make up a compatible, compliant implementation of JavaScript. Currently V8 passes approximately 98% of test262, and the remaining 2% are a handful of edge cases and future ES features not yet ready to be shipped.

Since it’s difficult to skim the enormous number of test262 tests, other conformance tests exist, such as the Kangax compatibility table. Kangax makes it easy to skim to see whether a particular feature (like arrow functions) has been implemented in a given engine, but doesn’t test all the conformance edge cases that test262 does. Currently, Chrome Canary scores a 98% on the Kangax table for ES6 and 100% on the sections of Kangax corresponding to ES7 (e.g. the sections labelled “2016 features” and “2016 misc” under the ESnext tab).

The remaining 2% of the Kangax ES6 table tests proper tail calls, a feature which has been implemented in V8, but deliberately turned off in Chrome Canary due to outstanding developer experience concerns detailed below. With the “Experimental JavaScript features” flag enabled, which forces this feature on, Canary scores 100% on the entirety of the Kangax table for ES6.

Proper Tail Calls

Proper tail calls have been implemented but not yet shipped given that a change to the feature is currently under discussion at TC39. ES6 specifies that strict mode function calls in tail position should never cause a stack overflow. While this is a useful guarantee for certain programming patterns, the current semantics have two problems. First, since the tail call elimination is implicit, it can be difficult for programmers to identify which functions are actually in tail call position. This means that developers may not discover misplaced attempted tail calls in their programs until they overflow the stack. Second, implementing proper tail calls requires eliding tail call stack frames from the stack, which loses information about execution flow. This in turn has two consequences:

1. It makes it more difficult to understand during debugging how execution arrived at a certain point since the stack contains discontinuities and
2. Error.prototype.stack contains less information about execution flow which may break telemetry software that collects and analyzes client-side errors.

Implementing a shadow stack can improve the readability of call stacks, but the V8 and DevTools teams believe that debugging is easiest, most reliable, and most accurate when the stack displayed during debugging is completely deterministic and always matches the true state of the actual virtual machine stack. Moreover, a shadow stack is too expensive performance-wise to turn on all the time.

For these reasons, the V8 team strongly support denoting proper tail calls by special syntax. There is a pending TC39 proposal called syntactic tail calls to specify this behavior, co-championed by committee members from Mozilla and Microsoft. We have implemented and staged proper tail calls as specified in ES6 and started implementing syntactic tail calls as specified in the new proposal. The V8 team plans to resolve the issue at the next TC39 meeting before shipping implicit proper tail calls or syntactic tail calls by default. You can test out each version in the meantime by using the V8 flags --harmony-tailcalls and --harmony-explicit-tailcalls.

Modules

One of the most exciting promises of ES6 is support for JavaScript modules to organize and separate different parts of an application into namespaces. ES6 specifies import and export declarations for modules, but not how modules are loaded into a JavaScript program. In the browser, loading behavior was recently specified by the new <script type="module"> tag. Although additional standardization work is needed to specify advanced dynamic module-loading APIs, Chromium support for module script tags is already in development. You can track implementation work on the launch bug and read more about experimental loader API ideas in the whatwg/loader repository.

ESnext and beyond

In the future, developers can expect ECMAScript updates to come in smaller, more frequent updates with shorter implementation cycles. The V8 team is already working to bring upcoming features such as async / await keywords, Object.values() / Object.entries(), String.prototype.padStart() / String.prototype.padEnd() and RegExp lookbehind to the runtime. Check back for more updates on our ESnext implementation progress and performance optimizations for existing ES6 and ES7 features.

We strive to continue evolving JavaScript and strike the right balance of implementing new features early, ensuring compatibility and stability of the existing web, and providing TC39 implementation feedback around design concerns. We look forward to seeing the incredible experiences developers will build with these new features.

-- Posted by the V8 team, ECMAScript Enthusiasts

Read More

EV Business Case - Tesla and BYD

Tesla and BYD - Forever Production Constrained?

I - Tesla

A lot has been said about Tesla, the american brand in the recent past has helped to change people's minds over electric cars, from slow-mobiles, a bit dorkey & nerdy, to become the ultimate cool, a bit like "Tesla might not be the most popular kid in the Automotive High school, but it is coolest".

Most recently it was in the mainstream media with its Model 3 and the disruptive force it promises to be (Could it be the first EV to beat the c*** out of mainstream ICE cars?), but with it came a Million Dollar Question: "Can Tesla handle it?"

There weren't that many launches from Tesla to evaluate future behaviors, but looking at the Model S (The Roadster doesn't count here, as it was at whole different scale and the Model X is still reaching cruise speed), the Model S went like this:   

2012 - 2.700 units, available only in North America;

2013 - 22.200 units, expanded to Europe (2nd Semester);

2014 - 31.200 units, expanded to China and RHD markets (2nd Semester);

2015 - 50.400 units.

We can see a limited number of units in the initial year, with the numbers jumping in the first full production year to 22.200 units, then increasing 40% in the second full year and 60% into the third year, with the market expansion taking place over the years, with the peculiar fact that production seems to be always behind demand levels...Something made on purpose?

In the Model 3, Tesla will have the advantage of having already an oiled production and delivery system, with numbers probably reaching 150k units Model S/X in 2017, but by that time the reservations will be so huge  (600k? 700k?), that the ramp up has to be steep in order to satisfy such high level of demand, so my take on the Model 3 Production levels are:

2017 - 7.500 units, available only in North America;

2018 - 100.000 units, expanding to Europe (2nd Semester);

2019 - 250.000 units, expanding to China (New factory?) and RHD markets (2nd Semester);

2020 - 500.000 units.

Assuming that only half of the reservations transform into actual deliveries (I think it will be higher than that), someone that makes a reservation today, April 29th, will receive its Model 3 around...The second semester of 2019. It will be a looong wait...

II - BYD

Something of a Unsung Hero in the EV Scene, the progression of the chinese brand has been nothing short of spectacular in the last years:

2013 - 2.900 units;

2014 - 18.400 units;

2015 - 61.700 units.

And the sales targets set for the next years are also worthy of awe: 

2016: 150.000 units;

2017: 300.000 units;

2018: 600.000 units.

As we can see, far more aggressive targets than Tesla, which must be at around 300k in 2018...

One would think that these growth rates would be impossible to achieve only with the chinese market and BYD would finally start to export in significant numbers, but in the end, i believe the EV market in China will grow so fast that it will absorb all of the BYD plug-in production and frustrate their own export plans, let's look at the last numbers of the chinese EV Market: 

2013 - 14.000 units;

2014 - 60.000 units;

2015 - 190.000 units.

Extraordinary growth rates, right? Now considering that the market only doubles in the next few years...

2016 - 400.000 (Projected);.

2017 - 800.000 (Projected);

2018 - 1.600.000 (Projected).

Considering that BYD has had historically at least 30% of the Chinese EV market all to itself, it won't be difficult for the chinese brand to see its production almost all absorbed by its domestic market, leaving little for export plans.

That is unless BYD decides to go all Tesla and make their customers wait several months for their car...

Read More