ES6 Web Components Part 5 – Wrap-Up

In Part 4 of my 5-part write-up, Project Setup and Opinions, I talked about lessons I took away from experimenting with ES6 Web Components. Lastly, is my wrap-up post…

This was a monster write-up! In my four previous parts, I’ve shown you the basics on Web Components, what features make up a Web Component, how ES6 can help, and some coding conventions I’ve stumbled on through my experimentation.

That last sentence is my big caveat – it’s trial and error for me. I’m constantly experimenting and improving my workflow where it needs to be improved. Some pieces I’ve presented here, but I may come up with an even better way. Or worse, I may discover I showed you folks a really bad way to do something.

One particular thing to be cautious of is recognizing I’m not talking about cross-browser compatibility here. I have done a bit of research to show that, theoretically, things should work cross-browser, especially if you use the WebComponents.js polyfill. I have done a little testing in Firefox, but that’s it. I really haven’t tested in IE, Edge, Safari, et cetera. I’m lucky enough to be in a position right now at my job and in my personal experiments where I’m focusing on building in Chrome, Chromium, or Electron (built on Chromium). I’m trying to keep compatibility in mind; however, without a real effort to test in various browsers, you may run into issues I haven’t encountered.

It isn’t all doom and gloom, though. WebComponents.js is used as the Google Polymer polyfill. Its why Polymer claims to have the cross-platform reach it has. See the support grid here for supported browsers.

Even better, as I complete this series, Webkit has just announced support for the Shadow DOM. This is fantastic, because the Shadow DOM is the hardest piece to polyfill. A while back, Polymer/WebComponents.js had removed polyfilled Shadow DOM support for CSS because it wasn’t very performant. Microsoft announced a while back that it’s working on the Shadow DOM, while Firefox has it hidden behind a flag.

All this is to say, if you take anything away from this series of blog posts on ES6 Web Components, takeaway ideas. Treat them as such. Don’t take this to your team and say “Ben Farrell has solved it all; we’re all in on Web Components.” I truly hope everything I’ve said is accurate and a fantastic idea for you to implement, but don’t risk your production project on it.

With all that said, aside from the implementation details, I do think Web Components are a huge leap forward in web development. It’s been encouraging me to use pure vanilla Javascript everywhere. I haven’t needed jQuery, syntactic sugar provided by a framework, nontraditional markup for binding – it’s all pure JS. I have been using JS techniques like addEventListener, querySelector, cloneNode, et cetera. Those are all core JS, CSS, and HTML concepts. When you understand them, you understand what every JS framework and library is built on. They transcend Angular, React, jQuery, Polymer, everything. They will help you learn why your favorite tool is built the way it is and why it has the shortcomings it does.

Not only am I building pure JS here, but I’m organizing my code into reusable and modular components – what every JS framework tries to give you.

For these reasons, I think there is huge potential in Web Components and I think it most likely represents what we’ll be doing as a community years from now, especially when (hopefully not if) all features of Web Components and ES6 are implemented in browsers everywhere.

As I said in my first post, I do like Google’s Polymer a lot. But again, I strive to do less application-like things and more creative-like things. Therefore, MY components are fairly custom and don’t need a library of Google’s Material-designed elements. I’ve started a Github Org called Creative Code Web Components that contains a video player and camera that draw to the canvas and effects can be created for them on the pixels. I’ve created a speech-input component as well, along with a pure ES6 Web Component slide deck viewer.

Those components are all in early stages, but for fabricating various creative projects, I feel like this the right way forward for me. Thus far, I have a real modular set of pieces for creating a neat prototype or project.

Perhaps if you are doing a real business application, Polymer is great for you. Or React. Or Angular. Regardless, I think what I’ve been learning is great info for anyone in web dev today to have. I wouldn’t have written 10,000 words about it otherwise!

This has been my big 5-part post about creating Web Components with ES6. To view the entire thing, check out my first article.

6 thoughts on “ES6 Web Components Part 5 – Wrap-Up”

  1. Great article!!! Extremely easy to understand, and touched on many of the exact things that I have had questions about!! Thanks!

  2. Thanks for this!! Was just starting to look into doing WC in vanilla JS and this gives me a solid starting point. Thanks for taking the time to share your experiences!

  3. Hi,

    This would be an excellent tutorial. I have started looking at web components because I want to move away from any JSF framework (I have been using butterfaces and bootsfaces for the simplicity). And I want to learn and use something simple for UI, that is why I will never move to Angular/React etc. (I am a java ee dev).

    But even for a simple web component, why the hell should I use any javascript tool (gulp/grunt/babel)? Why learn another tool? I have loved so much, writing simple javascript + html + css (and jquery) some years ago.

    I have looked for ES6 compatibility. I see that at the current level, Safari + Chrome + FF would be at a correct compatibility level to use.

    Could you maybe create a modified version of this tutorial, to just use ES6?

    Thanks

    1. Even though I think a build step (even just for concatenation) is still a good thing to do for your final project output, I totally agree with you that it would be nice if it just worked without Babel (or any transpiling). This article was a while ago, and currently you are right I think most browsers support the level of ES6 that I need. I used to (by convention) give my ES6 flavored JS files an ES6 extension. I don’t bother anymore, it’s all just Javascript now that there’s widespread support. So, most everything I do here just works. The only tricky thing is the use of the “import” statement. This is not a supported ES6 feature in any browser, and that is what you WOULD need Babel for – but I actually found a great polyfill: https://github.com/ModuleLoader/es-module-loader. In the end though, I don’t know that “import” is winning the war. I see more use of require.js than anything. That said, I’m being a little stubborn because I REALLLLLLY like import and the ES Module Loader polyfill is pretty great. I really do need to write another post to reflect this new ES6 reality, and I plan to soon. Thanks for your comment!

Comments are closed.