Those 5 shifts, along with other significant events like Google’s creation of Chrome and the rise of mobile, have shaped the web development world as we see it today. Depending on who you listen to though, we may be on the cusp of another pivotal moment.
Component Based Development is a blanket term I’m using to describe a movement that has been growing over the past year in web development. The results of this movement have taken several forms. There’s an official W3C standard, Web Components, that will eventually be available in all browsers natively. That standard has polyfills, which allow developers to begin using Web Components now, along with convenience extensions. Several existing MVC frameworks have provided component features inspired by the Web Component spec. And there are alternative component implementations, which embrace the ideas behind component based development without embracing the specific implementation of Web Components.
So what is Component Based Development?
Components also have the potential to provide greater readability. Compare Google Map’s current Hello World example, with a web component powered alternative:
<html> <head> <meta name="viewport" content="initial-scale=1.0, user-scalable=no" /> <link rel="import" href="google-maps.html"> </head> <body> <google-map></google-map> </body> </html>
So Why Should I Care?
Did that introduction excite you? Or are you sitting there yawning? You may think this is solving problems you don’t have. You also might be the guy still supporting IE8, who can’t even contemplate worrying about “Web Standards” if they aren’t even supported in IE11. If that’s you, it’s still worth following this movement, even if you’re not coding like this just yet on your current projects.
Component based development has also gained significant support in the community. I already mentioned the strong support from existing libraries, but there’s more to it than that. Facebook, Google, and Mozilla, three of the web’s foundational companies, have all released component based libraries. Google’s Polymer library in particular has been featured as the center of their web developer tooling lately. Web Components are already supported in Chrome and Firefox. Along with the community support and the trend towards auto-updating browsers, this is likely to be a relevant every-day technology sooner than you may think.
2014 is an interesting time for web development. There’s a lot to be excited about, as the component paradigm is leading to a lot of interesting experiments that create new possibilities. Ideas like React’s Virtual DOM and Polymer’s completely declarative application structures are going to be tested and tried, and we’re likely to be better off in the end.
There’s also plenty to be skeptical about. The lack of any known support for Web Components in Safari or IE is troubling. While Polymer’s “everything is an element” philosophy is fascinating, I suspect that we’ll look back and see it as an example of taking a good idea too far. And like any technology, until it’s been proven in production, we can’t really know how these technologies will evolve.
For anyone invested in the Web Platform, it’s time to be informed. Regardless of where each individual spec goes, the ideas behind this movement are going to influence our professions for years to come. Over the next month or so, I’m going to be diving deep into the current state of components, taking a look at the various aspects of the Web Component spec and also looking at the various libraries that are providing their own take on component based development. I hope you’ll come along, and help grow the conversation about the future of the web platform.
In The Web’s Declarative, Composable Future Addy Osmani lays out a manifesto for component based development, and Web Components in particular. If you’re struggling to understand why somebody would want Web Components, this is the piece to read.
TJ VanToll reminds us that Web Components Aren’t Ready For Production… Yet on Telerik’s Developer Blog. He does a good job of higlighting the browser support issues along with the difficulties of polyfilling this particular technology.
This Github discussion is an interesting look into the thought process of why a traditional MVC library would be interested in providing component features, and the value they bring.