Or, how I may have been missing the point
I've been having a hard time getting excited about Web Components. I mean, I'm pretty sure I get why they're useful and I expect to be using them a lot in the future. It's just that I haven't been able to see Web Components as the "tectonic shift" people make them out to be.
One reason for this lack of excitement might be that Web Components don't really enable me to build new kinds of things in the way that, say, WebGL or Device APIs do. Instead, Web Components enable me to do the kinds of things I'm already doing better: With higher modularity. With better tooling. With standardised solutions to common concerns like templating.
These are all things that I definitely welcome as a web developer. But I wouldn't go as far as to call them a tectonic shift.
What I've taken to be the idea people are most excited about with Web Components is reusability. That does seem like an overwhelmingly positive development - who wouldn't like more reusability? And I do look forward to more reuse in the small, within projects. But that's not the kind of reuse people seem to be talking about. They're talking about reuse in the large.
When people talk about a future where web applications can be assembled from prebuilt components that are commonly available, it just sounds too good to be true. I think that's because we've heard it so many times before. This kind of reuse in the large is like catnip for the software industry. It was supposed to happen with Object-Oriented Programming. It was supposed to happen with Service-Oriented Architecture. While both OOP and SOA took the industry a step forward, the goals involving reuse in the large turned out to be wildly overreaching. To some extent, it seems that there's a lot of similar talk about Web Components now, which had made me sceptical of the whole movement.
The Real Tectonic Shift
This was until I started thinking about Web Components from a different angle. Recently, as I was writing a section about AngularJS directives for my book, it struck me how similar the whole idea of an extensible DOM sounded like to the idea of extensible programming languages, and in particular, Lisps.
In the Lisp family of languages (Clojure being the most popular modern incarnation), language extensibility has long been a major differentiator. In particular, a language feature called macros is often used to extend the underlying language to make it a better fit for each individual program. You could say that in Lisps you first write a Domain-Specific Language for your app, and then write your app in that language.
Experienced Lisp programmers divide up their programs differently. As well as top-down design, they follow a principle which could be called bottom-up design – changing the language to suit the problem. In Lisp, you don’t just write your program down toward the language, you also build the language up toward your program. As you’re writing a program you may think “I wish Lisp had such-and-such an operator.” So you go and write it. Afterward you realize that using the new operator would simplify the design of another part of the program, and so on. Language and program evolve together. Like the border between two warring states, the boundary between language and program is drawn and redrawn, until eventually it comes to rest along the mountains and rivers, the natural frontiers of your problem. In the end your program will look as if the language had been designed for it. And when language and program fit one another well, you end up with code which is clear, small, and efficient.
The connection here to extending the DOM with AngularJS directives is obvious. By association, the connection to Web Components is even more obvious. After all, in many ways the current incarnation of Angular directives are a precursor to Web Components.
Web Components enable Bottom-Up Design for web applications. By allowing us to extend the DOM, they begin to let us think about web app development in different terms. The DOM becomes a DSL for our individual applications.
Shamelessly repurposing Graham's paragraph:
Experienced web developers divide up their programs differently. As well as top-down design, they follow a principle which could be called bottom-up design - changing the DOM to suit the problem. With Web Components, you don't just write your app down toward the DOM, you also build the DOM up toward your app. As you're writing an app you may think “I wish the DOM had such-and-such an element.” So you go and write it. Afterward you realize that using the new element would simplify the design of another part of the app, and so on. The DOM and the app evolve together. Like the border between two warring states, the boundary between the DOM and the app is drawn and redrawn, until eventually it comes to rest along the mountains and rivers, the natural frontiers of your problem. In the end your app will look as if the DOM had been designed for it. And when the DOM and the app fit one another well, you end up with code which is clear, small, and efficient.
Maybe this is where Web Components will turn out to provide most value. Maybe I was missing the point and "Bottom-up Design" is the true value proposition, rather than "reuse in the large". While the technological advances Web Components bring are limited, if they cause people to start thinking of the DOM as an extensible thing, the impact can be far larger than that.
To me, the Web Component spec alone isn't the thing that can bring on a "tectonic shift", just like CSS Media Queries weren't the thing. But Bottom-Up Design could be that thing. And just like you don't achieve a responsive design by throwing around some media queries, you don't achieve bottom-up design by putting your code into Web Components. Web Components just enable Bottom-Up Design. And that's something I could definitely get excited about.
Know Your AngularJS Inside Out
Build Your Own AngularJS helps you understand everything there is to understand about AngularJS (1.x). By creating your very own implementation of AngularJS piece by piece, you gain deep insight into what makes this framework tick. Say goodbye to fixing problems by trial and error and hello to reasoning your way through them
- AngularJS Dependency Injection from The Ground Up
- How I've Improved My Angular Apps by Banning ng-controller