When we recently spoke on an Web Platform Podcast episode, we spoke with panelist Leon Revill, who has raised this point of web components as a backward compatibility strategy. We think this is as a seriously underappreciated benefit of writing and using web components.
Which framework from three years ago would you prefer to use today if you were starting a new project?
The web development industry is a highly chaotic, substantially fractured, and quickly evolving marketplace of competing approaches to writing apps. Even if you have the luxury of developing in an approach you think is absolutely perfect for 2016, the chances are probably very low that you will still want to write your app that way in 2019. If you don't believe that, ask yourself: which framework from three years ago would you prefer to use today if you were starting a new project?
If you're working on something of lasting value, in three years time, you'll still be forced to reckon with some of your old code from 2016. Unless you're lavishly funded or insulated from the market, you probably won't be able to afford to always move all your old code to whatever you decide is the latest and greatest way to write software. You'll be forced to maintain code written in different eras, and that can be very tricky.
A web component provides a useful encapsulation boundary that can help keep old front-end user interface code usefully running directly alongside new code. While a variety of contemporary web frameworks offer proprietary component models, they can only offer backward compatibility to the extent that you're willing to keep writing your whole app in that framework indefinitely. By virtue of being a web standard, the value of web components you write today should be able to be preserved for a very long time.
Bonus: During our port, we were able to bring our popular Web Components Tutorial up to date. If you know people who would be interested in learning about web components, just point them at the newly-updated tutorial.