DEV Community

Cover image for Web Components and now what?
weedshaker
weedshaker

Posted on β€’ Edited on

3

Web Components and now what?

Finally, you jumped on the bandwagon of web components! Congrats! πŸ˜†

Web Components are going to solve ALL your troubles with CSS, Frameworks and Life... not really... right? 😏 What about stores? Immutable data? 😨 And all the other buzzwords? Just forget about them! 😡 VanillaJS Web Components is all you need, since the architecture to make them work for complex applications is already there. It is called the DOM and it is Event Driven. πŸ˜„

An Event Driven Architecture makes stuff like stores obsolete. Your components react on events and if they need something, they emit their event to ask for it. Sure, at this level you are free to decide, if you want to cache certain events, fetches, etc. or if you just want to fire and forget. We chose to simply cancel ongoing fetches at some endpoints (https://github.com/mits-gossau/event-driven-web-components-realworld-example-app/blob/master/src/es/components/controllers/Article.js#L81) but not all those approaches require any difficult logic anymore. Why should you even try to bloat your frontend with a bunch of business logic, if you have an endpoint with that logic already implemented? Keep it simple! 🀯

Even more important is to keep the process of using Web Components simple. They already bring everything you need with them and if something is missing you can extend your Web Component with some convenient setters and getters, a mutation observer and even an intersection observer: https://github.com/mits-gossau/web-components-cms-template/tree/master/src/es/components/prototypes

The death of IE11 made any transpiler redundant. πŸ₯³ BUUUUUT what about TypeScript? Yes, also the TypeScript transpiler just puts additional complexity to your project, which you can spare yourself the trouble with: https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html JSDoc Types nearly do everything you can wish for but do not enforce additional dependencies on you, if you already work with VSCode, it works out of the box. And yes, I love type highlighting!

The next of your concerns may is the loading of the Web Components. For an SPA it is simple, just load them when required: https://github.com/mits-gossau/event-driven-web-components-realworld-example-app/blob/master/src/index.html In case of server side rendering, you could ether have the backend template engine decide what to render when, although my backend colleagues are not very keen dealing with JavaScript, so I wrote a simple loader script for them: https://github.com/mits-gossau/web-components-cms-template/blob/master/wc-config.js the only disadvantage is, that you likely loose couple milliseconds for the request to the wc-config.js 🚽 plus some more milliseconds to load the required Web Components. In case you need a Lighthouse score of 100 you better just render those Web Component Classes straight into your html file but I think the convenience is worth the price of losing a few milliseconds. This is anyway, what you at least save by not loading and interpreting a framework. πŸ˜„

Conclusion, it is worth to look into the nature of the DOM, an Event Driven Architecture, once you feel ready to start working with Web Components. This will make a lot of classical complexity nonessential and keeps your application easy, simple, scalable and reusable.

The Real World Example of an Event Driven Architecture: https://github.com/mits-gossau/event-driven-web-components-realworld-example-app
Alt Text

The TodoMVC Example of an Event Driven Architecture: https://github.com/mits-gossau/event-driven-web-components-todomvc-app
Alt Text

Related Video Tutorials

https://weedshaker.github.io/event-driven-web-components-tutorial/src/#/one

SurveyJS custom survey software

Simplify data collection in your JS app with a fully integrated form management platform. Includes support for custom question types, skip logic, integrated CCS editor, PDF export, real-time analytics & more. Integrates with any backend system, giving you full control over your data and no user limits.

Learn more

Top comments (0)

The best way to debug slow web pages cover image

The best way to debug slow web pages

Tools like Page Speed Insights and Google Lighthouse are great for providing advice for front end performance issues. But what these tools can’t do, is evaluate performance across your entire stack of distributed services and applications.

Watch video