[webcomponents]: Blocking custom elements on ES6, was: Platonic form of custom elements declarative syntax
Hello, TC39 peeps! I am happy to have you and your expertise here. On Wed, Apr 10, 2013 at 11:14 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: This can all be expresses, but less clearly and concisely using ES3/5 syntax. But since we are talking about a new HTML feature, I'd recommend being the first major HTMLfeature to embrace ES6 class syntax. The class extension in ES6 are quite stable and quite easy to implement. I'm pretty sure they will begin appearing in browsers sometime in the next 6 months. If webcomponents takes a dependency upon them, it would probably further speed up their implementation. We simply can't do this :-\ I see the advantages, but the drawbacks of tangled timelines and just plain not being able to polyfill custom elements are overwhelming. Right now, there are at least two thriving polyfills for custom elements (https://github.com/toolkitchen/CustomElements and https://github.com/mozilla/web-components), and they contribute greatly by both informing the spec development and evangelizing the concepts with web developers. To state simply: We must have support both ES3/5 and ES6 for custom elements. :DG
Re: [webcomponents]: Blocking custom elements on ES6, was: Platonic form of custom elements declarative syntax
On Apr 11, 2013, at 10:59 AM, Dimitri Glazkov wrote:
Hello, TC39 peeps! I am happy to have you and your expertise here.
On Wed, Apr 10, 2013 at 11:14 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
This can all be expresses, but less clearly and concisely using ES3/5
syntax. But since we are talking about a new HTML feature, I'd recommend
being the first major HTMLfeature to embrace ES6 class syntax. The class
extension in ES6 are quite stable and quite easy to implement. I'm pretty
sure they will begin appearing in browsers sometime in the next 6 months. If
webcomponents takes a dependency upon them, it would probably further speed
up their implementation.
We simply can't do this :-\ I see the advantages, but the drawbacks of
tangled timelines and just plain not being able to polyfill custom
elements are overwhelming. Right now, there are at least two thriving
polyfills for custom elements
(https://github.com/toolkitchen/CustomElements and
https://github.com/mozilla/web-components), and they contribute
greatly by both informing the spec development and evangelizing the
concepts with web developers.
To state simply: We must have support both ES3/5 and ES6 for custom elements.
:DG
ES6 classes can be pollyfilled:
class Sub extends Super {
constructor() {/*constructor body */ }
method1 () {}
static method2 {}
}
is:
function Sub() {/*constructor body */ }
Sub.__proto__ = Super;
Sub.prototype = Object.create(Super.prototype);
Sub.prototype.method1 = function method1() {};
Sub.method2 = function method2 () {};
Allen
Re: [webcomponents]: Blocking custom elements on ES6, was: Platonic form of custom elements declarative syntax
Err...polyfill doesn't mean you can do something via a different route that
produces a similar outcome, it means you back fill the API so that you can
use 1:1 syntax that never needs to know if the evn supports the native
underlying API or not.
I don't mean to disparage ES6 - as a former developer of the MooTools
framework (the most well recognized Class-y JS lib), I have a special
affinity for seeing a great Class abstraction land in JS. However, there's
no reason to hitch our wagon to ES6 and a pseudo-not-quite-fill. If people
want to use ES6 for defining Custom Elements, they can start doing so when
it is available in their target environment.
Daniel J. Buchner
Product Manager, Developer Ecosystem
Mozilla Corporation
On Thu, Apr 11, 2013 at 11:10 AM, Allen Wirfs-Brock
al...@wirfs-brock.comwrote:
On Apr 11, 2013, at 10:59 AM, Dimitri Glazkov wrote:
Hello, TC39 peeps! I am happy to have you and your expertise here.
On Wed, Apr 10, 2013 at 11:14 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
This can all be expresses, but less clearly and concisely using ES3/5
syntax. But since we are talking about a new HTML feature, I'd recommend
being the first major HTMLfeature to embrace ES6 class syntax. The class
extension in ES6 are quite stable and quite easy to implement. I'm pretty
sure they will begin appearing in browsers sometime in the next 6 months.
If webcomponents takes a dependency upon them, it would probably further
speed up their implementation.
We simply can't do this :-\ I see the advantages, but the drawbacks of
tangled timelines and just plain not being able to polyfill custom
elements are overwhelming. Right now, there are at least two thriving
polyfills for custom elements
(https://github.com/toolkitchen/CustomElements and
https://github.com/mozilla/web-components), and they contribute
greatly by both informing the spec development and evangelizing the
concepts with web developers.
To state simply: We must have support both ES3/5 and ES6 for custom
elements.
:DG
ES6 classes can be pollyfilled:
class Sub extends Super {
constructor() {/*constructor body */ }
method1 () {}
static method2 {}
}
is:
function Sub() {/*constructor body */ }
Sub.__proto__ = Super;
Sub.prototype = Object.create(Super.prototype);
Sub.prototype.method1 = function method1() {};
Sub.method2 = function method2 () {};
Allen
