4 ms·

the problem is the web today is not what a proper application plateform should be. Developpers have waited long enough, we need more features and it takes way t

by camus2 13y ago

the problem is the web today is not what a proper application plateform should be. Developpers have waited long enough, we need more features and it takes way to long for the W3C to deliver. At the same time, HTML5 was a coup orchestrated by the Whatwg on the future XHTML spec, It was a mistake in my opinion because the original W3C spec was way better as we would not have the discussion we are having today about web components and the shadow dom if the W3C spec had been chosen. So I dont know. Is google way of doing things short-sided? or does it really solves some issues? Time will tell. but maybe the lean approach the Whatwg took wasnt that "future proof" after all.

macspoofing 13y ago
>we need more features and it takes way to long for the W3C to deliver We also need features that work across all major browsers.
- johnward 13y ago
  It's kind of a catch22. We do need features to work across all browsers but the standards body moves to slowly. So vendors push out features they think are good. Others implement them. This is how we end up with multiple vendor prefixes. Then eventually the standards group gets around to accepting it and the vendors update to use the standard. Waiting for w3c might be the "right" way to develop standards but it also slows progress. I'm not sure which is worse. Even using the vendor prefix process things work in more browsers now than they did in the past.
- munificent 13y ago
  I don't know about the CSS stuff that spawned this thread, but the rest of the shadow DOM stuff is polyfilled to work in other browsers: https://github.com/Polymer/ShadowDOM https://github.com/Polymer/ShadowDOM
  - potch 13y ago
    This is speculation: The reason Google is moving forward quickly with Shadow DOM implementation is that this polyfill is dog slow. Think about what it takes to make DOM invisible in the browser in a polyfill- overriding every DOM method to filter out shadowed nodes. I've heard reports of 10x slowdowns on DOM operations with this polyfill in place. The kicker? Web Components (specifically Custom Elements) lose almost all their encapsulation without Shadow DOM. Those of us who are betting heavy on Web Components as The Future™ are pretty anxious about this.
    - munificent 13y ago
      > The reason Google is moving forward quickly with Shadow DOM implementation is that this polyfill is dog slow. I'm not sure what you mean by "moving forward quickly". They've been hammering on this in the public eye for over three years. How many more years of salary should they pay before they get it out the door? At some point, you just have to ship.
potch 13y ago
When the features don't work the same way in every browser, it hurts the platform. Poorly designed features are impossible to take back. (see also AppCache). Web Components is moving quickly, but there has to be an element of care. Shipping features before they're ready is driven by marketing and PR, not engineering maturity.
gress 13y ago
If you want a proprietary platform controlled by a single vendor, code for iOS or Android.

by camus2 13y ago

macspoofing 13y ago

>we need more features and it takes way to long for the W3C to deliver We also need features that work across all major browsers.

johnward 13y ago
It's kind of a catch22. We do need features to work across all browsers but the standards body moves to slowly. So vendors push out features they think are good. Others implement them. This is how we end up with multiple vendor prefixes. Then eventually the standards group gets around to accepting it and the vendors update to use the standard. Waiting for w3c might be the "right" way to develop standards but it also slows progress. I'm not sure which is worse. Even using the vendor prefix process things work in more browsers now than they did in the past.
munificent 13y ago
I don't know about the CSS stuff that spawned this thread, but the rest of the shadow DOM stuff is polyfilled to work in other browsers: https://github.com/Polymer/ShadowDOM https://github.com/Polymer/ShadowDOM
- potch 13y ago
  This is speculation: The reason Google is moving forward quickly with Shadow DOM implementation is that this polyfill is dog slow. Think about what it takes to make DOM invisible in the browser in a polyfill- overriding every DOM method to filter out shadowed nodes. I've heard reports of 10x slowdowns on DOM operations with this polyfill in place. The kicker? Web Components (specifically Custom Elements) lose almost all their encapsulation without Shadow DOM. Those of us who are betting heavy on Web Components as The Future™ are pretty anxious about this.
  - munificent 13y ago
    > The reason Google is moving forward quickly with Shadow DOM implementation is that this polyfill is dog slow. I'm not sure what you mean by "moving forward quickly". They've been hammering on this in the public eye for over three years. How many more years of salary should they pay before they get it out the door? At some point, you just have to ship.

potch 13y ago

When the features don't work the same way in every browser, it hurts the platform. Poorly designed features are impossible to take back. (see also AppCache). Web Components is moving quickly, but there has to be an element of care. Shipping features before they're ready is driven by marketing and PR, not engineering maturity.

gress 13y ago

If you want a proprietary platform controlled by a single vendor, code for iOS or Android.