DEV Community

Cover image for DOM and the event driven architecture - Introduction
weedshaker
weedshaker

Posted on • Updated on

DOM and the event driven architecture - Introduction

At times of IE6 we were exited to have a primitive console. πŸ“Ί Later came firebug bug πŸ”₯🐜 and libraries like JQuery, which made it possible to easily navigate different web api implementations by browser vendors. While those issues started to be harmonized out of our ways (thank you W3C) compilers solved modularity and frameworks like react or angular solved state management/single page app and DOM concerns. And while all this was happening Macro Medias Flash with it’s powerful Action Script was mercilessly assassinated. πŸ”«πŸ˜’

Today, our web api’s reach a depth, which Action Script delivered in 2005 πŸ₯³ . At the same time our laziness and division about frontend technology has not only created a uniform, uncreative appearance by bootstrap and material UI. But opened the JavaScript, HTML and CSS stack for discussion by wasm (rust, .net, C++) solutions.

In general I see wasm as an enrichment of JavaScript but others see it as the end of such. This prediction is going to full fill, the more divided the frontend dev camps become. React vs. VueJs vs. Ember vs. Angular vs. etc etc. The only huge savior of JavaScript is by adopting the won learnings out of such frameworks and start using W3C web components with VanillaJS. #useWebApi !!! πŸ”¨πŸ˜ŽπŸ€™ and wake up to the fact that the W3C standard, tc39 (ES6) solved most past and future concerns. Since IE11 died ⚰️, we can use the fancy πŸ¦„ stuff anywhere without polyfills nor webpack, nor framework only one thing to learn: https://developer.mozilla.org/en-US/docs/Web/API

Finally, things are becoming simple again. πŸ€ͺ But then you will ask me how to solve your applications state management? My answer is β€œWhen in Rome, do as the Romans do”. Your application is in the DOM so do as the Domans do! How does the DOM do? The DOM is event driven and CustomEvents is a standard https://developer.mozilla.org/en-US/docs/Web/API/CustomEvent, by which your web components https://developer.mozilla.org/en-US/docs/Web/Web_Components will be communicating. ShadowDOM, event driven web components, asynchronicity and http2 are so much optimized that your site feels as fast as a static site and at the same time let’s you make it static, if desired and hydratable by the nature of web components. 🌊

Your time to interactivity is going to be lower than ever before. No more threat blocking code! πŸ†˜πŸ”¨

Web components are a perfect match for complex single page apps with reusable components, micro frontends on static pages and at the same time flexible enough for any other use case running in or on the DOM.

To visualize the statements above in code, I started the real world conduit example, which is similar to the TodoMVC (https://github.com/mits-gossau/event-driven-web-components-todomvc-app) but more specific for a web application scenario: https://github.com/Weedshaker/event-driven-web-components-realworld-example-app

I would be very happy, if some of you guys would join the development process!? πŸ₯°

Thanks for reading! πŸ™

Related Video Tutorials

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

Top comments (0)