Re: [w3c/webcomponents] Non-class based example of customElement.define() (#587)

@AndyOGo I agree, things are not ideal how they are now. It's possible for implementors to make Custom Elements work with ES5 classes (anything is possible, it is just a collection of bits), but they choose to push the problem to user space. It is opposite of what should be: hard stuff solved at a lower level so everyone at the high level (users who know ES5, not just ES6+) can benefit.

Honestly, I use Web Components not because I like how the component system is implemented, but because I want the end result to be components that can be used everywhere, so I just put up with it. 😕

To make matters worse, I made myself a tool, [lowclass](https://github.com/trusktr/lowclass), which let's me have "protected" and "private" members in my classes, and it is implemented with ES5 classes. This means I can't use it with Custom Elements v1 without going through **_great lengths_**. 😢 

I know there's this or that problem in the CE implementation that is solved by limiting what language features users can use, but I feel that instead the problem needs to be solved at a deeper level, so that JavaScript can be used in a free way. We should avoid coupling APIs to specific language features as much as possible.

Telling people to use `Reflect.construct` is _practically_ the same as telling them to use `class`, both limiting and degrading developer experience.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/587#issuecomment-375128010