I don't have nearly enough time to keep up on all the latest developments with HTML5, but from what I've read Web Components will be a huge life saver for anyone who works on web front ends. I've been thinking this weekend about how I might take advantage of proper components at $work.
The best I can relate it, is that I can take all the widgets that are used throughout the website and wrap them up into their own CSS and JS. No need for rigorous CSS namespacing, JS modules, etc. It's all packaged up, ready to drop into an HTML page. The most interesting part are the polyfills for the various Web Components, erm components, that are currently being drafted. At the moment, the polyfills have to implement most everything but eventually won't be needed when the specs are finalised and the browsers caught up.
I'm also very much looking forward to this reusable, component-based approach using Javascript, because I'm currently enjoying using a similar paradigm on a project I'm working on with the Seaside framework in Smalltalk. I don't know if I can convince anyone to use Smalltalk for a web project, but if I can keep this same approach and stick to JS that will make my life much better! That being said, here's a little bit about Seaside in case you're interested in trying something different.
Seaside makes it extremely easy to embed multiple components within or alongside each other. It also has the ability to sequence the display of components in a modal fashion while synchronizing the client state (even when using the back button), which can be good for some types of wizard-style workflows.
In terms of using Smalltalk, the message-passing syntax is elegant and simple to comprehend. And the ability of Smalltalk to aid in debugging is fantastic: if you running web app experiences an error, you will get a debugger with a stack trace that includes the source code of everything in the stack. Simply make the changes necessary to fix the bug, and then resume the execution of your program. If you like REPL style coding, this is quite similar, albeit through a GUI. This has proven invaluable to iterative development.
HTML5 is a fixed standard - I assume you mean something else by that. the lines between OS/VM/browser are blurring more and more. I find what Rich Hickey is saying really interesting. to me the next great step is dynamic computing. so the stuff that Bret Victor is doing is going to be huge IMO. defining dynamic behavior and services is the future, not so much widgets and mouse actions.
You should read the article (and avoid being so dismissive). Functionality like Mutation Observers are exactly the kind of abstractions that will make "dynamic behavior and services" (as vague as that is) all the easier.
Also, maybe you have a weird definition for "widget", but go watch Bret's latest talk. It's all widgets. And it's certainly not dynamic magic; we can build interfaces like that, but more and better tools to make building them easier are a very good thing.
I'm personally really excited from what I've seen of Polymer, and even more excited about its mostly decoupled design (and the polyfill-until-standardized approach the GP comment mentions), allowing you to pick and choose what you want to use without committing to some huge (and "opinionated") framework.
You've hit the nail on the head. Every website these days has widgets, for lack of a better word, that are reused all over the place. Anything we can do to make it easier to package up those widgets so I can drop them in place on a new html page is A Good Thing IMHO.
Opinionated frameworks are great, until you need to do something they didn't anticipate. If you're lucky it's easy to work around, and if you're not then welcome to your latest nightmare.
The whole polyfill concept is exactly what the world needs to allow browsers to grow and mature at different rates.
Thanks for pointing that out. My understanding of standard was that it is something which is agreed upon and then used. But now this standard is some kind of irreversible pre-standard.
clojure.org and worrydream.com. Rich has talks on youtube and Bret on vimeo (accessible via his website). What I mean is that if one thinks in widgets and DOM this is already tied to a particular way of thinking about computing. For instance d3.js and others manipulate the DOM, so that you have more or less a scripting of static content. There is real power in combining user interaction and scripting making it a two-way channel. My instant reaction to this talk is they really took the whole to an extreme, where the absurdity should become obvious. The next big thing is not going to come from Google (obviously). Perhaps I'm just ignorant.
WebKit removed a lot of the ShadowDOM (upon which polymer rests, with a polyfill for non-native ShadowDOM) code after the Blink divorce because it was really complicated. So that's not super positive.
Less related to polymer, I feel like a lot of proposed standards get implemented in Blink/Moz when one could accomplish the same thing with a polyfill to see if it's a good design or not. ShadowDOM is an example of this as it exposes a huge new interface surface area. Mutation Observers are a good counter-example since it's a small API and is well defined.
I used to do .NET development. Polymer and other things like it such as AngularJS remind me of WPF/XAML. I also feel as though recent developments with C# and other languages have been influenced by JavaScript.
To me it seems like there is a little bit of convergence.
I know this is going to be controversial but -- I actually believe that eventually web, mobile and desktop platforms will be the same thing. Because they actually share so many goals, use-cases, and especially, technical challenges.
For example, new UI frameworks and application builders coming out, at least for the web, are definitely trying to provide a one-stop shop for web _and_ mobile devices. Or another example: Google Now voice search functionality appearing in Google desktop.
One reason for this is because a large portion of the problems that developers need to solve are actually the same on each device. I will even go so far as to say that desktop machines will start to become identified and have persistent payment systems the same way that mobile devices do. Because most desktop devices actually are used by only one person and there is a huge convenience win there.
You can already see people moving away from desktops and towards laptops. Or people using their mobile phone almost as if it were a laptop with a tiny screen and slow keyboard.
You see people working on the go from coffee shops more and more.
With more and more capabilities coming to browser applications, pretty soon people will start to realize that the only important thing that their browser can't do is break out of the confines of the browser tab and create notifications. Browsers already have convenient APIs for key devices.
So I believe that the remaining limitations of browser applications will go away, and we will see a component-based web application framework that doesn't even show an actual web browser.
But really, being able to take a laptop with me is nice, but I would rather not have to carry anything. That's why I think that Google Glass is a look into the future of computing. But I think within 10 or 15 years we will go even further than Glass. We will end up with one web/desktop/mobile/brain platform that interfaces directly with our brains.
The best I can relate it, is that I can take all the widgets that are used throughout the website and wrap them up into their own CSS and JS. No need for rigorous CSS namespacing, JS modules, etc. It's all packaged up, ready to drop into an HTML page. The most interesting part are the polyfills for the various Web Components, erm components, that are currently being drafted. At the moment, the polyfills have to implement most everything but eventually won't be needed when the specs are finalised and the browsers caught up.