Use of 'extends' keyword in class definition - is it supported?

Uploaded defaultExtends20180926.jsf is generated w/ // @language_out ecmascript5 (ES5) option. Xyz-fillers - either provided as libraries or inline generated - makes it possible to use the ES6 features class, constructor, etc., that's where these $ methods come from. (Trying to compile w/o ES5 output option fails / complains about the get area(....)

JSC_CANNOT_CONVERT: This code cannot be converted from ES6. ES5 getters/setters (consider using --language_out=ES5) at line 14 character 6
  get area() {
      ^

Interesting are also the stats:

Original Size:	187 bytes gzipped (321 bytes uncompressed)
Compiled Size:	710 bytes gzipped (1.77KB uncompressed)

Instead of 'optimization' the opposite happens by a fatty -279.68% to -463.55% (g- and un-zipped).

Espruino has (some) ES6 native support... and the support is growing, so no need for using ES5 output generation - the ES6 native support for class and constructor saves a lot.

Espruiono works off of source code, so there is no bytecode generation involved. Espruino though has an option to speed interpretation from source code up by tokenizing before uploading.

Even though closure-compiler is called blabla-compiler, it is - strictly looked at - more a transpilation... one form of javascript into another (less powerfull) one and - most often - using some poly-filler js library/libraries.

Initially, Espruino was completely dependent on google's closure compiler, but it had it's issues on different levels:

• too many uploads of modules (from the sandbox or elsewhere) - and code in the IDE w/ minimizer (closure compiler) w/ optimization on rendered too many calls to the free service - happened to me when doing intense development on multiple modules and application using those. So I started to use the compiler service once and store then the minified code in my local sandbox.

• needs to follow absolutely the language definition - either es3, 5 or 6. Since Espruino is not fully ES6 it does not guarantee that compiled code does work, even though non-ES6 constructs are used, but compiler know to compile them into more modern, efficient ES6 code or to mix it with ES6 code to make it better.

For this reasons - and to support Espruino independent and very concisely - @Gordon established the Espruino services in addition to the module services.

Your experience using the google closure compiler service and ending up w/ code not running on Espruino makes me a bit jittery, because I have an extended set of very small, but tightly dependent modules that I developed this way. I may have to go thru a re-minify to get them all working for current and future Espruino versions. May be I got lucky because they were built with an 8-grader English - I mean JS 1.3 mind, even predating ES5, and would not be that susceptive to that issue.