It’s been a while since I wrote a blog post! No, I haven’t abandoned writing – I do really enjoy writing about new technology and techniques, especially on the web. So much so, in fact, that I started writing a book with the good folks at Manning Publications called “Web Components in Action”.
Going back a few years in this blog, I just couldn’t shut up about Web Components. I’ve given a few talks at various conferences on them as well. Weird thing is, that I’ve been using them around 4 years now, and I’m still excited about them.
When I first started using Web Components, I was a bit frustrated at the constant abandoning of JS frameworks. I was on Angular 1.x at the time, and developers seemed like they were ready to move onto the next big thing, which was React. I’ve been at this game long enough to know that once I really started enjoying React like I did with Angular, it would be time to move onto the next thing. Fast forward to 2018, and I’m seeing signals to indicate I may have been right – Vue.js is rising in popularity.
Now I’m not against any of these frameworks, but it’s just a bit tiresome to finally be proficient enough in a tool and you’re working on this amazing side project idea with an awesome front-end stack, when late in the game you keep having that nagging in the back of your mind that you need to switch your tools of choice because everyone else is.
I was ready to move on from Angular to the next obvious thing, but I really wanted to think about escaping from this endless cycle. I ultimately chose Google’s Web Component framework Polymer as the next thing to learn attempting to buck the trend to steer towards a Web specification backed framework vs the next big thing.
Now, as awesome as Polymer is now in 3.0, it was a bit of a mess back when I started learning it with v0.6. When I started peeling back the layers of what Polymer offered, I realized that while Polymer is nice and all, it was really Web Components that I was excited about. Since that time, I moved on from working on a Web Components based Design System at GE to a prototyping role at Adobe. This summer marked my 3rd year at Adobe, and EVERY SINGLE web project I’ve kicked off has been Web Component based.
Web Component based projects were a little rough at the beginning while figuring out a good workflow. At one point, the floor dropped out and we switched the Custom Element API from v0 to v1. I was also initially excited about the Shadow DOM, but needed to opt out of that given its lack of browser support and polyfill options. HTML Imports also died during that time. Looking back, I definitely can’t blame developers for writing articles claiming that Web Components were an unfulfilled promise. What’s left? The Web Component hype was initially around these three pillars: Custom Elements, HTML Imports, and the Shadow DOM.
I ran with custom elements for a while, but then something happened. ES2015/ES6 modules became a dependable feature in our browsers. I could import JS module based HTML markup and CSS to properly separate concerns in my components. I can import actual Web Components with JS, RIGHT INSIDE other components. The fat arrow for scope management became reliable as well, so dealing with listeners and timers in my Web Component classes became a breeze.
So yes – to some extent Web Components are an unfulfilled promise. The hype of the 3 main pillars of Web Components are pretty much dead. Instead I see a new Web Component promise coming into play. Web Components to me are now Custom Elements alone, with a killer toolbelt of ES2015 language features, HTML templates, and more to makeup your workflow.
I can’t emphasize JS modules enough. I’ve been using them for custom code and importing HTML/CSS, yes, but I also feel like we are on the cusp of a significant change in how we do libraries in JS. Templating libraries like lit-html and hyperHTML can now be imported and used without taking over your project like other popular frameworks tend to do. I’ve written a couple other smaller helper imports and have an idea for another ambitious library. My point here is that we likely will get bored with the Web Components specification sometime and it won’t be the new shiny thing – but instead of abandoning it as a way to work, JS module based libraries that sit on top will be the new hotness as we creep closer to 2020.
The next hammer to fall with Web Components will FINALLY be the Shadow DOM. We can depend on it now in Chrome and Safari. We’re just waiting for Firefox and Edge. Firefox is really close (you can turn on a flag in the settings to enable), and Edge is under development.
It really does sound like late 2018 or early 2019 will be a pretty big turning point for the Web Components story. That’s why it’s exciting for me that my book “Web Components in Action” is due to be released in Spring 2019 – I just think this is such perfect timing.
Thats why I’m working hard to get it right. Given that we’ve had a round of beta readers for the first few chapters, and anyone can buy the book as a pre-release now, we’ve gotten some great feedback. One of my main challenges that I’m working through now is how to best balance those readers who aren’t familiar with ES2015 features (like even the basics of using “Class”) with readers who are very up to date on all of these features and just want to learn Web Components. As I’m making this book more approachable for both audiences, I also have chapters on the component lifecycle, using modules in Web Components, and using modules for templating waiting to be reviewed and published under the Manning Early Access Program (MEAP).
Overall, I’m feeling good about my first book, so much so that my mind is spinning about what I can do after its published. I’d love to continue writing and teaching, plus I’m a AR/VR nerd right now – so when I did a marketing video for this book, I just had to combine my interests and use Mindshow:
All in all, I’m excited to get my first book done and on bookshelves, and I’m excited to see what 2019 will bring for Web Components!