event-driven-web-components-realworld-example-app VS web-components-cms-template

Note about Browser compatibility: This example uses the attribute "is", which is not yet supported by IOS. It is possible to simply avoid this problem by wrapping elements with web components. As can be seen at our Real World Example.

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!