- From: HE Shi-Jun <notifications@github.com>
- Date: Fri, 06 Jul 2018 05:04:41 -0700
- To: w3c/webcomponents <webcomponents@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/webcomponents/issues/509/403014314@github.com>
@oleersoy Repeat again, default export is simply a "syntax sugar", so I don't think it will need "ton of education" in this simple case. And default export definitely has the benefit -- follow the convention of node.js. Note, there is NO default export in the early ES6 draft, it is added because the node.js community gave the feedbacks. It may "zero upside" to you (and I admit I myself can live without it because I prefer AMD than CommonJS before ES module is standardized), but you can't deny node.js is a very important part of the js community so that default export have the benefit for the whole ecosystem. Last, compare `is` attribute to default export is not suitable. Because `is` attribute is not a "syntax sugar". Without `is`, you have no way to utilize webcomponents on many builtin elements. On the other side, if I need to ban a feature in a large engineer team, I would choose to ban the normal custom element, and only use `is` to extend. Because most average developers do not have enough knowledge and experiences on components design, which means they are very likely to produce a leaky abstraction, or do something wrong (for example, raise a11y issue). And `is` way is much safer for them. 😂 -- 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/509#issuecomment-403014314
Received on Friday, 6 July 2018 12:05:03 UTC