The Web, its components (their reusability), its frameworks, and its discontents.
For a long time, the components that we developers used to build the Web were relatively few and fixed. Yet from the lowly , the boastful , the helpful , all the way to their late arriving cousin
At the very smallest, <span>your content here, whenever filled with only one required data point, your content, will take up the space on the screen needed to deliver that content to the visitor. In a similar simplicity of implementation, need only be supplied with an ‘src’ attribute and it will deliver forth any image your heart might desire. One component, an infinity of single data points, and each one delivers something unique to the visitor. Reusability at its finest. Then, even with just one more required data point, ‘href’, we see how in all its glory is little more than an extension of the . Content causes it to fill space on the screen and an ‘href’ gives it the magic power of being able to take you to any other place on the Web. With just these three components the Web can ask us about our day, cheer us up with cat photos and give us the option to see dog photos instead, if that’s our thing. There’s really not much more left that we’d need it to do, right?
Well, in a similar feat of reusability and simplicity we were gifted the
At the time of its birth(s) (2007 if you’re an Opera or Apple fan, 2010 if your a YouTube fan, or 2013 if your a Netflix fan), the
The
“Have you used this jQuery plugin?” (There are too many that were amazingly useful in yesteryear to list here.)
Or even better…
“Have you used that framework for backbone.js?” (Marionette took a beautifully simple framework and then turned it to 11.)
And, not to be one upped, Ember even went so far as to call them components. Components that even started to look like the building blocks we’d used to build the Web for many years, except for those weird squiggly angle brackets…curly braces?…they even had attributes! If you took the time, you could make a small number of attributes add up to a whole lot of functionality. Another era of the web was rising, the features we developers were adding to the web with javascript were even close to the first class citizens we’d been chasing for so long in terms of structure and simplicity.
That is… except for one small point. I mean really small, like you’d barely even notice on most days. You’d especially not notice it on big news day like that one in 2013 when virtual DOM by way of reactJS changed the entire landscape of JS based user interface development as we knew it, and so soon after having been changed in its entirety the last time.
Not only was React already with the program calling what you built with it components from the start, it also reminded us all what we were already thinking…that frameworks were too much and that we should probably downsize. At this seemingly perfect intersection of motive and desire, we all got incredibly excited. Deservedly so. We were making more components, cooler, smaller, and more performant than ever.
“My component’s on GitHub, PRs greatly appreciated!”
“My component’s on NPM, `$ npm install super-cool-react-component`.”
Productivity was high, reusability was high, we were sharing our hot new components with anyone and everyone who was using React, and it was great!
Then the one small point hits you, the one point that’s still there, the one that’s been with us since we decided the <span/>s and <a/>s and <img/>s of the world weren’t enough anymore, what about the people not currently using your flavor of the month framework/library? How do you share my components with them? If you can’t really share your components with everyone, are they really components then?
Whether we were writing less and doing more, giving structure to our web application, making those applications ambitious, or just focusing on building user interfaces, our quest to build our own components on the web, with the reusability, portability, and simplicity of the web on which we were building them, always paled in comparison to the ancestors who we hoped they would equal. That is, until something came along that was so simple in its paradigm shift that that we didn’t understand why we hadn’t thought of it before. Stop building components on the web, and start building components with the web.
Web Components, brilliant!
Built off a combination of four separate specifications, the element, custom elements, shadow DOM, and HTML imports, Web Components are actually native citizens of the web, with all the associated rights and powers. We can use all the power of the browser to manage our DOM rather than abstracting it out into custom JS. That DOM can look like all the rest of our DOM with the angle braces that go along with it. Its innards can even be formatted with the clean upper lip of ES2015 template string. While shedding the hacks and workarounds and short comings of yesteryear, we can finally build the amazingly flexible, eminently reusable features and products we had always intended. And build we did, Microsoft invested itself in X-Tag, Mozilla decided to build their OS with them, Google created a community around the Polymer Project, on top of projects of varying size, both public and private, from too many other teams and companies to count. So many that Web Components even got their own web site to make it that much easier to share and reuse them, https://customelements.io/.
One of those companies happens to be mine, PhotoShelter. In the summer of 2015, the broader commitment to and agreement on the standards that come together to power Web Components combined with the release of Polymer 1.0 helped us go from cautious observers to actively developing. The magnified success of earlier prototypes fueled us with enough momentum to commit to building our first for production components while targeting a longer term conversion of our front end application to one that could be shared more broadly and flexibly than ever before. As part of that process, we converted a number of our user facing features to web components throughout the fall. Some of which are available today on our member homepage dashboard, and you can see them in action via a free 14 day trial, however we’re very excited to announce our very first public facing use of components are being released this month.
The PhotoShelter Engineering Team is excited to be part of the growing web component community the opportunity to #useThePlatform that comes with it. Checkout our some of our early steps in converting a ten year old product to web components and some of our most recent activities as part of that process.