I agree with some of the points here about WC implementation but I don’t agree with the presentation.
3) is irrelevant. Spec is and should be a living document so naturally we’ll have to change as spec changes. We should be critical of spec. There is an opportunity to change because it is a living document.
4) I haven’t used a tool in the past decade that didn’t require a polyfill at one time or another. It’s true browsers should implement custom elements uniformly and they don’t, including custom elements v1. Browser vendors could definitely get better at this. I don’t think this argument holds weight if literally any level of sophistication in web development requires a polyfill.
10) Yes, but the nasty side effect is multiple component models leads to division in the greater web community. That’s a problem we don’t talk about enough. We have an opportunity to learn and grow together but can’t when everyday a new library comes out. So instead of Platform fatigue we end up with JavaScript fatigue. I’m not talking about Svelte necessarily, I actually think Svelte is a novel reaction to other JS libraries. The other side effect is no one bothers to learn DOM or vanilla JS because at an early stage in their education they become reliant on the popular JS library. That’s not good for anyone. We end up with a ton of engineers who don’t know how things work under the hood.
8) is so reductive I don’t know where to start. If DOM is bad, then why go into web development? We should just stop everything. Everyone go home. DOM is bad.
Web Components IMHO should have a framework wrapper to make problems like you talk about go away. That doesn’t make them bad, that is the function of every JS library. Make DOM easier to work with. No news there.
Rich, instead of bashing technologies like this perhaps it’s better for everyone if you extol the virtues of Svelte in a context that does address the limitations of DOM, but please frame it in a way that is less divisive.
The other side effect is no one bothers to learn DOM or vanilla JS because at an early stage in their education they become reliant on the popular JS library.
I know this is an old comment, but i would like to thank you for recognizing this issue.
I hope more people start thinking about this problem.
The moment you need tools to make anything work at all, it's the moment you are already far away from Web standards, and you are allowed to do whatever you want, like in Svelte, and other libraries, case.
Stencil One does not compete with standards anymore, rather with React/JSX, IMHO.
I'd give 🔥 heresy 🔥 a chance too, it works out of the box on client/SSR and since it needs zero real DOM to work, it might easily end up on NativeScript or similar too 🦄
almost nothing you see in that definition is standard:
decorators are not there yet
@Prop() first: string; makes literally no sense on JS
the JSX return in the render also makes no sense
Stencil One is basically the most hybrid thing of them all, and once it compiles to "standrd JS", it needs a global defineCustomElements to be useful at all.
One can't really ship portable components like this, or can they?
The good news, is that it might target also NativeScript or similar platforms (I'd imagine React native, due JSX in the render), but the bad one is that Stencil One is far away from being a standard based way to develop anything, 'cause it needs, for those parts, mandatory toolchain that is not part of standard Web development.
I hope I've clarified a bit more, happy to answer further, if necessary.
The props and decorators are removed during compilation, and the output is a Web Component. There's a lot of companies building design systems now with Stencil dev.to/ionic/apple-just-shipped-we...
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I agree with some of the points here about WC implementation but I don’t agree with the presentation.
3) is irrelevant. Spec is and should be a living document so naturally we’ll have to change as spec changes. We should be critical of spec. There is an opportunity to change because it is a living document.
4) I haven’t used a tool in the past decade that didn’t require a polyfill at one time or another. It’s true browsers should implement custom elements uniformly and they don’t, including custom elements v1. Browser vendors could definitely get better at this. I don’t think this argument holds weight if literally any level of sophistication in web development requires a polyfill.
10) Yes, but the nasty side effect is multiple component models leads to division in the greater web community. That’s a problem we don’t talk about enough. We have an opportunity to learn and grow together but can’t when everyday a new library comes out. So instead of Platform fatigue we end up with JavaScript fatigue. I’m not talking about Svelte necessarily, I actually think Svelte is a novel reaction to other JS libraries. The other side effect is no one bothers to learn DOM or vanilla JS because at an early stage in their education they become reliant on the popular JS library. That’s not good for anyone. We end up with a ton of engineers who don’t know how things work under the hood.
8) is so reductive I don’t know where to start. If DOM is bad, then why go into web development? We should just stop everything. Everyone go home. DOM is bad.
Web Components IMHO should have a framework wrapper to make problems like you talk about go away. That doesn’t make them bad, that is the function of every JS library. Make DOM easier to work with. No news there.
Rich, instead of bashing technologies like this perhaps it’s better for everyone if you extol the virtues of Svelte in a context that does address the limitations of DOM, but please frame it in a way that is less divisive.
I know this is an old comment, but i would like to thank you for recognizing this issue.
I hope more people start thinking about this problem.
I guess that's Polymer, but they kinda failed at selling WCs too.
My approach is still Custom Elements based (no umbrella, just the juicy bit), and tiny wrapper to simplify every task mentioned in here.
You can find more in this gist of mine 👋
I made a feeble attempt here too.
readymade-ui.github.io/readymade/
what about Stencil?
The moment you need tools to make anything work at all, it's the moment you are already far away from Web standards, and you are allowed to do whatever you want, like in Svelte, and other libraries, case.
Stencil One does not compete with standards anymore, rather with React/JSX, IMHO.
Isn't Stencil just a layer on WebComponents, like Polymer?
not at all infoq.com/news/2019/06/stencil-ion...
Stencil is the best option by far for design systems.
I'd give 🔥 heresy 🔥 a chance too, it works out of the box on client/SSR and since it needs zero real DOM to work, it might easily end up on NativeScript or similar too 🦄
The article keeps saying Stencil compiles to Web Components, that's what I meant 😅
Yeah it's more than that but the final product is WC.
Anyway, frontend has so many tools 😬😬😬😱
almost nothing you see in that definition is standard:
@Prop() first: string;makes literally no sense on JSStencil One is basically the most hybrid thing of them all, and once it compiles to "standrd JS", it needs a global
defineCustomElementsto be useful at all.One can't really ship portable components like this, or can they?
The good news, is that it might target also NativeScript or similar platforms (I'd imagine React native, due JSX in the render), but the bad one is that Stencil One is far away from being a standard based way to develop anything, 'cause it needs, for those parts, mandatory toolchain that is not part of standard Web development.
I hope I've clarified a bit more, happy to answer further, if necessary.
Ok got it, I thought that Stencil's output was just pure web components, that's it.
The props and decorators are removed during compilation, and the output is a Web Component. There's a lot of companies building design systems now with Stencil dev.to/ionic/apple-just-shipped-we...