Before I launch into this 5-part series of posts, I just want to give a high-level overview of it: I wrote a lot. Partially because I’m long overdue on a blog post on all the stuff I’ve been experimenting with for the past several months, but mostly because much of the web tech I’ve been looking into is Web Components and I’m truly excited about it and feel like it represents a pretty big chunk of the future for web devs. Best of all, I think whether you use Polymer, React, Angular, or anything else, we can all be happy together in the common ecosystem that Web Components give us. So this post isn’t telling you what religion to pick; it’s telling you there’s something awesome happening we can all learn from.
You might not need all the information I’m writing here. So here are links and summaries to the individual segments of my 5-part ES6 Web Components Series.
Part 1: A Man Without a Framework (this page)
An opinion piece on why and how I decided to give ES6 Web Components a shot with no help from frameworks or libraries.
Part 2: The Building Blocks
A look at what I mean when I say Web Components and all the pieces that make that up.
Part 3: Making an ES6 Component Class
How to make a real ES6 Class by extending HTMLElement and making a proper component.
Part 4: Project Setup and Opinions
Opinions I’ve formed on project setup as I experimented with rolling my own components. This covers repo setup as well as common methods in my class.
Part 5: Conclusion
An important look forward if you read and took the other 4 parts of this series to heart and are as excited as I am about them. The short of it: While Web Components is super promising, take it with a grain of salt and do your own due diligence. In other words, I’m very excited about ES6 Web Components, but I haven’t been releasing production cross-platform code. Think about it before you do.
And so we begin:
Part 1: A Man Without a Framework
Dojo, might have been a little ahead of its time, though. In an age during which folks copied and pasted snippets of jQuery to make things go, Dojo was a hefty setup. It had a learning curve. Unless you were dedicated enough to get around the infuriating bits of that learning curve….wellllll….back to copy/pasting jQuery code.
I’m not against folks copying and pasting jQuery. It’s so fantastic that people learn new things, and there’s nowhere better to start. Throwing a bunch of code into a file, tweaking little bits here and there – that’s how I learn a brand-new technique to this day.
At this point in my JS career, though, I want a good place to call home. A comfy cottage that has decent conveniences. Fun to live in, but with enough maintenance already done for me to carve time out for doing more fun things. I don’t like doing dishes or handwashing laundry just like I don’t care for managing script dependencies, doing DOM manipulation with cases for every browser, or a whole other host of things. I want to work on my app!
My last comfy cottage was Angular. Angular had an easier learning curve than Dojo…but it still had one. What Angular did better was allow me to create modular bits (directives) that could all work together to make some very cool apps. Lots of times, I could focus on my actual application, rather than on what made Angular work. But occasionally, I’d still have to dig into Angular’s weird nuances to work something out. $Scope.digest anyone?
When I get that invested in a framework like Angular, I stretch my feet out toward the toasty fire and do some cool things with it I don’t think others are doing. It starts to feel like home, even if it’s a little messy. I invite some people over.
Then, of course, Angular 2 was announced. Lots of things I knew went out the window. What the hell!? Also, React was happening. Also, Polymer was happening.
So I thought to myself, well, if Angular 2 is no longer recognizable, why not reconsider this whole cottage thing. Leave all the options on the table and check out the new real estate.
React seems pretty awesome; I even played with it some. The whole virtual DOM thing is a cool paradigm. You update this DOM that’s off to the side in memory, and it watches the changes, and if there are things that change, the real DOM is updated. Clever. Lots of folks seem to love it and are building some pretty brilliant stuff with and for it.
Angular 2 also seems great. I was skeptical, but I got good vibes when my friend, Adrian Pomilio, presented on it at NCDevCon. Despite changing some stuff around, creating a slight learning curve, and making lots of Angular 1 developers angry, its early stage progress looks promising.
And then there’s Polymer. I started learning Google’s fancy Web Component framework at a very early stage (at 0.5). I took Polymer pretty seriously. Web Components just made sense. Yes, it’s a set of emerging standards, all rolled up into one buzzword. But the modularity of it….well, it gives me real hope for a freaking awesome way to work and even share our work.
Now, the problem with Polymer started for me when the 0.5 release iterated to the 0.8 release. And then the 0.8 release iterated to the 1.0 release. I knew to expect breaking changes between these sub 1.0 releases, but it was too much change to call working with Polymer fun. During the slow times, I could get cool stuff done for my application, but then the next wave came and I had to refactor everything and re-learn stuff that was gelling in my mind. What’s worse is I didn’t know how to keep track of the Polymer component seed generators or the different components that had different version dependencies. They never seemed to work out in a major upgrade; I’d have to tweak bower files to pull in new versions or old versions, and the errors weren’t clear on what was happening when something went wrong during this confusing time.
The further I’ve built it up, the more I’ve settled into my current comfy cottage. Sure, I have to plug some holes other frameworks already fixed, but I can look to them for inspiration and guidance. What seems common to all of these frameworks is the convergence on some sort of Web Components. Whether it’s true Web Components or not doesn’t matter; I can pull ideas from a host of frameworks that all seem to agree on modularity and custom element creation. And of course, an added bonus is learning how everything works under the hood. There were some design decisions, especially in Polymer, that had me scratching my head until I learned how the browser actually dealt with components.
What’s more, with modern browsers, lots of housekeeping problems have gone away. Cross-browser needs that jQuery answered have disappeared if the target browser is recent enough. The application lifecycle has become that of a component, and modularity can provide the foundation of an application structure. If that isn’t good enough, I can sprinkle in libraries to help that aren’t entire platforms of their own like Angular, React, and Polymer are.
Even better, since we’re talking Web Components, we can hypothetically share components between React, Angular 2, and Polymer. That’s a pretty great place to be.
(And an exciting note: Webkit just announced Shadow DOM support!)
If this pans out, we’ll know the underpinnings of how most future web technology works. Polymer works on Web Components. Both React and Angular have hinted at basing future tech on them, but they are smart enough to not bet the farm on it yet.
Couldn’t it be cool to be a man or woman without a framework?
Check out Part 2 in this monster 5-part series (cause I’m really excited about this stuff) on the building blocks of Web Components.
3 thoughts on “ES6 Web Components Part 1 – A Man Without a Framework”
Great article! I’ve reworked a complex website into using WebComponents and I’ve managed to avoid all of the frameworks; recently I cleansed all my code of all jQuery and I feel pretty good about that!
Feels good doesn’t it! jQuery is a fantastic library that still has many many use cases. That said, it feels great to write organized and maintainable code with no libraries or frameworks – and I’m pretty thrilled with web components enabling this
now this is a interesting article, and yes no need for frameworks, there is a reason for any thing to exits and the real existence reason for a framework organizing development of bigger projects not to deliver new features
Comments are closed.