4 ms·

The other terrible side effect of web components is that it gives the standards group an excuse to never update HTML anymore. "Why do we need HTML6 when you ca

The other terrible side effect of web components is that it gives the standards group an excuse to never update HTML anymore. "Why do we need HTML6 when you can make anything you want with big, heavy Javascript-based web component that takes expert programmers to make?" Indeed. Just say no to web components. Say yes to upgrading HTML specs directly.

nostrademons 11y ago
That's the exact opposite of the reason why browser vendors are implementing web components. It's so that they can get direct, real-world feedback from actual users of a feature before baking it into standards and making it impossible to remove from the web. The intent has always been that the most frequently used webcomponents will end up getting baked into the browser, and then into the HTML spec. We used to write web specs speculatively, without having feedback from real-world use, and it was a disaster. Take a look at the list of W3C standards: https://en.wikipedia.org/wiki/World_Wide_Web_Consortium#Standards https://en.wikipedia.org/wiki/World_Wide_Web_Consortium#Stan... How many of them do you actually use? Remember when everything was XML, XPATH, XSLT, the semantic web, and we were going to replace HTML with XHTML?
- mozumder 11y ago
  The intent has always been that the most frequently used webcomponents will end up getting baked into the browser, and then into the HTML spec. That's nice in theory, but what's happening in reality is that no component is going to be standardized, and HTML remains stagnant for another 15 years.
  - nostrademons 11y ago
    It's a little hard to make that argument when web components themselves aren't standardized yet, and are fully supported natively in only one of the major browsers. There's pretty ample evidence that common webdeveloper behavior does make it into the spec, eg. JQuery => querySelectorAll, Javascript animations => CSS transitions & animations, long-polling => websockets, common layouts => <header>/<footer>/<main>/<nav> elements, dropdowns => <details>/<summary> elements, the addition of date/datetime/color/number/range/tel input types, etc. If you're still coding HTML like you did in 2000, you are now very obsolete.
deleted 11y ago
[deleted]
hugozap 11y ago
This is completely inaccurate.
spankalee 11y ago
Sorry, what? The browser has sorely needed extension and componentization capabilities for many years. Why should the W3C be the gate-keepers of what's allowed in HTML? That only leads to the invention of heavy-weight and balkanized UI frameworks. We can do much better than that.
- mozumder 11y ago
  Ask yourself why the generic UI elements in Polymer, like Menu, Dialog Boxes, etc.., isn't part of HTML itself? If you want to see balkanized UI frameworks, there it is.
  - spankalee 11y ago
    > why the generic UI elements in Polymer, like Menu, Dialog Boxes, etc.., isn't part of HTML itself? Because they shouldn't be. HTML should not be responsible for providing every possible UI element. In fact, I would argue that provides _far_ too many UI elements, and should instead provide low level user input APIs that can be used to build interactive elements.
    - mozumder 11y ago
      And so web developers have to write basic UI widgets just to get basic UI elements. Or, to use a heavyweight component library that needs needs to be downloaded. Thanks but no thanks. HTML should provide a rich, declarative UI API by default. We shouldn't have to hunt down separate components to get that. If you have to load Javascript, you have already lost.
      - spankalee 11y ago
        A well regarded standard UI library, say jointly developed by browser vendors, could be CDN served and cached or even bundled with browsers eliminating the download cost with the massive advantage that it can be versioned independently of HTML and browsers and is optional in case a better library comes along.

nostrademons 11y ago

That's the exact opposite of the reason why browser vendors are implementing web components. It's so that they can get direct, real-world feedback from actual users of a feature before baking it into standards and making it impossible to remove from the web. The intent has always been that the most frequently used webcomponents will end up getting baked into the browser, and then into the HTML spec. We used to write web specs speculatively, without having feedback from real-world use, and it was a disaster. Take a look at the list of W3C standards: https://en.wikipedia.org/wiki/World_Wide_Web_Consortium#Standards https://en.wikipedia.org/wiki/World_Wide_Web_Consortium#Stan... How many of them do you actually use? Remember when everything was XML, XPATH, XSLT, the semantic web, and we were going to replace HTML with XHTML?

mozumder 11y ago
The intent has always been that the most frequently used webcomponents will end up getting baked into the browser, and then into the HTML spec. That's nice in theory, but what's happening in reality is that no component is going to be standardized, and HTML remains stagnant for another 15 years.
- nostrademons 11y ago
  It's a little hard to make that argument when web components themselves aren't standardized yet, and are fully supported natively in only one of the major browsers. There's pretty ample evidence that common webdeveloper behavior does make it into the spec, eg. JQuery => querySelectorAll, Javascript animations => CSS transitions & animations, long-polling => websockets, common layouts => <header>/<footer>/<main>/<nav> elements, dropdowns => <details>/<summary> elements, the addition of date/datetime/color/number/range/tel input types, etc. If you're still coding HTML like you did in 2000, you are now very obsolete.

deleted 11y ago

[deleted]

hugozap 11y ago

This is completely inaccurate.

spankalee 11y ago

Sorry, what? The browser has sorely needed extension and componentization capabilities for many years. Why should the W3C be the gate-keepers of what's allowed in HTML? That only leads to the invention of heavy-weight and balkanized UI frameworks. We can do much better than that.

mozumder 11y ago
Ask yourself why the generic UI elements in Polymer, like Menu, Dialog Boxes, etc.., isn't part of HTML itself? If you want to see balkanized UI frameworks, there it is.
- spankalee 11y ago
  > why the generic UI elements in Polymer, like Menu, Dialog Boxes, etc.., isn't part of HTML itself? Because they shouldn't be. HTML should not be responsible for providing every possible UI element. In fact, I would argue that provides _far_ too many UI elements, and should instead provide low level user input APIs that can be used to build interactive elements.
  - mozumder 11y ago
    And so web developers have to write basic UI widgets just to get basic UI elements. Or, to use a heavyweight component library that needs needs to be downloaded. Thanks but no thanks. HTML should provide a rich, declarative UI API by default. We shouldn't have to hunt down separate components to get that. If you have to load Javascript, you have already lost.
    - spankalee 11y ago
      A well regarded standard UI library, say jointly developed by browser vendors, could be CDN served and cached or even bundled with browsers eliminating the download cost with the massive advantage that it can be versioned independently of HTML and browsers and is optional in case a better library comes along.