I'm cautiously optimistic about Web Components. It's good to add well-defined interfaces to browser Javascript, and there's a certain logic to using the DOM. The DOM is central, it's queryable, and it itself can gain from expressiveness.<p>Like Addy points out ("not a silver bullet") performance, security, and accessibility are not a given, and those are why I'm cautious. Security-wise, the document is already hard to lock down, and so it makes me a little worried to increase the surface area with application-level extensions. Cautiously optimistic.<p>What really remains to be seen is whether this reduces or increases complexity. This really depends on how well it works to declare data in the document and then interact with that data via the JS. For instance, one of Polymer's example components was an Ajax call, which I suppose you can fire from the script. Is that really better than putting the ajax parameters in the code? Does it encourage "globals"-like behavior, where hidden dependencies crop up? Are there life-cycle behaviors to the Ajax component that might trigger the request at surprising or frustrating times?<p>If you're a Web Components advocate and you're feeling agitated, knock me down here. Fence-sitters are the worst when you're trying to get market-share for an idea, so sorry about that. It looks like Web Components are happening, though, so I'm sure I'll get to wait and see.
I'm worried about the direction the web is going in right now. I think a lot of the "progress" is being pushed by people whose agenda is building browsers and possibly certain very large and high profile web apps, and not so much by the people whose agenda is simply building good web sites. I also think a lot of the agenda is being pushed by people who want to move fast and break things.<p>The trouble is, the web <i>sucks</i> as a platform for developing serious applications, because that's never what the technologies were intended to support. It offers only one major programming language, and that language is horrible. It offers one DSL that was designed to mark up content in simple ways and has been abused to fill some sort of ill-fitting UI description role. It offers another DSL that was designed for basic presentation functions, based on underlying models so bad that almost everyone ignores or overrides them even to the extent of building preprocessing tools to paper over the gaps. It offers limited separation of concerns in terms of content, presentation and behaviour, yet the promotion of web components seems determined to erode that separation even further. It offers almost no tools for modularity or composition in any of the three fundamental pillars everything is built with, and with a small number of exceptions even the various proposals to improve this don't look that promising so far.<p>We've seen this before, and we know how the story ends, if you just stop pretending the Web is somehow a special thing and look at general software development. The modern web being pushed by the likes of Google and Mozilla looks increasingly like the unintended result of one-night stand between modern C++ and VB6. It's all about papering over the cracks and shoe-horning existing tools into roles for which they are completely unsuited. This approach will get you so far, and then it will fail, as it always does.<p>We would do much better if we redirected all the recent enthusiasm for improving the Web. We can still recognise what has made the Web successful: essentially, it offers a ubiquitous, readily understood, cross-platform, client-server model for letting normal people interact with services running on someone else's system. But then we can also recognise the forces that are limiting web development today: lack of a real "portable assembly language" and run-time environment that a diverse range of programming languages can use as a stable, secure, reliable foundation; and the lack of a clean, flexible model for presentation and interaction.<p>You can't fix the latter using any combination of JavaScript, HTML and CSS, no matter how big a number you put after them. Their fundamental models are broken and cannot be repaired. The only way we will really make a big jump in what we can do is to build more suitable replacements that are designed to be fit for purpose from day one. And unfortunately, the organisations best placed to do that today seem determined to ignore all the warning signs from the history of software development and pursue a futile alternative anyway.
A solid example of such a custom element would be a <code-block> element: <a href="https://twitter.com/simevidas/status/450272769948016642" rel="nofollow">https://twitter.com/simevidas/status/450272769948016642</a>
I quite like the concept of Web Components - operate with elements rather than blobs of JS. Browsers have been doing it for ages defining built-in elements. Now front-end devs have the tools to do the same. I'm excited to see what will come out of it.<p>If you want to get the gist of Web Components, there's a good 30 min talk by Eric Bidelman: <a href="https://developers.google.com/events/io/sessions/318907648" rel="nofollow">https://developers.google.com/events/io/sessions/318907648</a>