4 ms·

> main proponents of WebComponents cannot build proper WebComponents (and no one can): I've a vested interest as I run the team that Rob is on, I feel like the

by kinlan 9y ago

> main proponents of WebComponents cannot build proper WebComponents (and no one can): I've a vested interest as I run the team that Rob is on, I feel like there is a lot being misconstrued here in this thread, x-tags is be on the list of supported resources on webcomponents.org. If there are only two elements on the list it's not because it's "polymer only" and run by the Chrome team. I've launched a couple of elements using plain JS and there are others on there too, it's just that many of the elements created use Polymer, and that is probably a good indicator of how popular the tooling is in the component ecosystem. Rob didn't say no one can build proper web components, he was saying that to build great web components there is a lot of work that you have to do especially to make them accessible and good actors in the life-cycle of a page and that many of the spec authors hadn't seen them being built as a canonical reference set. Of course people can build proper web components, but it is on us to explain it clearly now that the browser support is mostly there.

dmitriid 9y ago
> it's just that many of the elements created use Polymer, and that is probably a good indicator of how popular the tooling is in the component ecosystem. That's exactly what I'm saying. There are no WebComponents. There is no x-tags or whatever. There is only Polymer. For many reasons. Chief among them: WebComponents suck. Polymer at least gives nice-ish APIs on top of that. Rob did say something like "Polymer is the jQuery of WebComponents". And it's true. One could argue that you can write your stuff in pure DOM APIs. Yet hardly enyone ever did that, because there was jQuery. All the handlebars and mustaches and other things of this world were largely irrelevant because of jQuery. Now, jQuery solved a very pressing problem: it gave an easy, simple, extensible API that made working with the DOM a joy. It would be very nice if jQuery's approach was adopted by w3c, but that is really too much to ask for. In 11 years since jQuery's original release w3c managed — barely! — to standardize on querySelector/querySelectorAll (already a much more cumbersome combination of APIs than jQuery's $). Enter WebComponents. 6 years in development. Quite a few years of saying that they are the future. Let's do a reality check, shall we? The APIs are horrible. None of the original promises are fulfilled. As Polymer 3 approaches someone suddenly starts asking "erm, guys, what are the best ways of creating WebComponents without Polymer". - It turns out even people who implement the spec in the browser don't have reference components. - It turns out the API is so bad, you have to use pseudocode in your presentation to sell people the idea[1]. - It turns out WebComponents are so effing great and can really be used to reimplement stuff in the browser, ... that you can't even implement a checkbox without reimplementing the checkbox label [2] - It turns out people don't even know how WCs should work. Quote from [1]: "If we can generally agree on how Custom Elements should behave..." - It turns out that actually implementing WCs in anything but Polymer is a royal pain in basically everywhere because w3c's goal was never to create a sane API for anything. etc. etc. etc. Therefore, forget selling people the idea of WebComponents. For all intents and purposes they do not exist. Only Polymer exists. Masochists can go and check out the underlying DOM APIs, of course. [1] https://www.youtube.com/watch?v=sK1ODp0nDbM https://www.youtube.com/watch?v=sK1ODp0nDbM [2] https://github.com/GoogleChrome/howto-components/issues/112 https://github.com/GoogleChrome/howto-components/issues/112
- ergo14 9y ago
  I think web components are low level and non-opinionated to give you freedom of implementation for higher level things. Thats what Polymer, Stencil, Svelte, SkateJS are for. Indeed WC API is not the nicest to work with to say the least, but thats not the problem, I write in python instead of Assembly, just user higher level stuff.
  - dmitriid 9y ago
    > Indeed WC API is not the nicest to work with to say the least, but thats not the problem How is it not a problem? > I write in python instead of Assembly, just user higher level stuff. As with any analogies, it's a wrong one. You compare a low-level PL with a high level PL. WebComponents is not a programming language. It's a set of APIs for the most popular platform in the world I wonder how far along iOS would get if all it provided for its UI libraries was just the UIView, and never anything else (no collection views, no table views, no content views etc.) That's exactly what w3c does, times and again.
    - ergo14 9y ago
      It is low level API to be non-opinionated. Or at least it makes sense for me to make it like that. Same as web assembly, service worksers and others - that is a step in right direction IMO. Same as for example Python providing WSGI - you don't often use WSGI directly, you use a framework on top of it like Pyramid, Django or Flask.
      - dmitriid 9y ago
        > It is low level API to be non-opinionated. No API is non-opinionated. It's the opinion of its authors. And w3c's opinions invariably are to the detriment of developer experience. For example, quote from [1]: "The things like property initializers for instances that were so nice in [a previous example] aren't here. And they've been stuck in committee for reasons that, frankly, just make me grumpy" (around 22:30 mark) [1]: https://www.youtube.com/watch?v=y-8Lmg5Gobw https://www.youtube.com/watch?v=y-8Lmg5Gobw Around 12:50 mark: "What jumped out at us was how much infrastructure each library was bringing around to support creating widgets or components". Let's look at WCs: ooops, all the infrastructure is still there, nothing is done to make it easier.

by kinlan 9y ago

dmitriid 9y ago

> it's just that many of the elements created use Polymer, and that is probably a good indicator of how popular the tooling is in the component ecosystem. That's exactly what I'm saying. There are no WebComponents. There is no x-tags or whatever. There is only Polymer. For many reasons. Chief among them: WebComponents suck. Polymer at least gives nice-ish APIs on top of that. Rob did say something like "Polymer is the jQuery of WebComponents". And it's true. One could argue that you can write your stuff in pure DOM APIs. Yet hardly enyone ever did that, because there was jQuery. All the handlebars and mustaches and other things of this world were largely irrelevant because of jQuery. Now, jQuery solved a very pressing problem: it gave an easy, simple, extensible API that made working with the DOM a joy. It would be very nice if jQuery's approach was adopted by w3c, but that is really too much to ask for. In 11 years since jQuery's original release w3c managed — barely! — to standardize on querySelector/querySelectorAll (already a much more cumbersome combination of APIs than jQuery's $). Enter WebComponents. 6 years in development. Quite a few years of saying that they are the future. Let's do a reality check, shall we? The APIs are horrible. None of the original promises are fulfilled. As Polymer 3 approaches someone suddenly starts asking "erm, guys, what are the best ways of creating WebComponents without Polymer". - It turns out even people who implement the spec in the browser don't have reference components. - It turns out the API is so bad, you have to use pseudocode in your presentation to sell people the idea[1]. - It turns out WebComponents are so effing great and can really be used to reimplement stuff in the browser, ... that you can't even implement a checkbox without reimplementing the checkbox label [2] - It turns out people don't even know how WCs should work. Quote from [1]: "If we can generally agree on how Custom Elements should behave..." - It turns out that actually implementing WCs in anything but Polymer is a royal pain in basically everywhere because w3c's goal was never to create a sane API for anything. etc. etc. etc. Therefore, forget selling people the idea of WebComponents. For all intents and purposes they do not exist. Only Polymer exists. Masochists can go and check out the underlying DOM APIs, of course. [1] https://www.youtube.com/watch?v=sK1ODp0nDbM https://www.youtube.com/watch?v=sK1ODp0nDbM [2] https://github.com/GoogleChrome/howto-components/issues/112 https://github.com/GoogleChrome/howto-components/issues/112

ergo14 9y ago
I think web components are low level and non-opinionated to give you freedom of implementation for higher level things. Thats what Polymer, Stencil, Svelte, SkateJS are for. Indeed WC API is not the nicest to work with to say the least, but thats not the problem, I write in python instead of Assembly, just user higher level stuff.
- dmitriid 9y ago
  > Indeed WC API is not the nicest to work with to say the least, but thats not the problem How is it not a problem? > I write in python instead of Assembly, just user higher level stuff. As with any analogies, it's a wrong one. You compare a low-level PL with a high level PL. WebComponents is not a programming language. It's a set of APIs for the most popular platform in the world I wonder how far along iOS would get if all it provided for its UI libraries was just the UIView, and never anything else (no collection views, no table views, no content views etc.) That's exactly what w3c does, times and again.
  - ergo14 9y ago
    It is low level API to be non-opinionated. Or at least it makes sense for me to make it like that. Same as web assembly, service worksers and others - that is a step in right direction IMO. Same as for example Python providing WSGI - you don't often use WSGI directly, you use a framework on top of it like Pyramid, Django or Flask.
    - dmitriid 9y ago
      > It is low level API to be non-opinionated. No API is non-opinionated. It's the opinion of its authors. And w3c's opinions invariably are to the detriment of developer experience. For example, quote from [1]: "The things like property initializers for instances that were so nice in [a previous example] aren't here. And they've been stuck in committee for reasons that, frankly, just make me grumpy" (around 22:30 mark) [1]: https://www.youtube.com/watch?v=y-8Lmg5Gobw https://www.youtube.com/watch?v=y-8Lmg5Gobw Around 12:50 mark: "What jumped out at us was how much infrastructure each library was bringing around to support creating widgets or components". Let's look at WCs: ooops, all the infrastructure is still there, nothing is done to make it easier.