Mention tooling to build micro-frontends about micro-frontends HOT 7 CLOSED

I agree with @naltatis - the whole point of the approach of the "DOM being the API" is, that every framework / library that sticks to these conventions can be used. Maintaining a list of "tools", "frameworks" will neither be complete, nor current. Furthermore including certain tools or not could lead to endless discussions about being biased.

Using the presented approach, you can use any library you want and it does not necessarily have to be web-component-centric. We are using this approach with e.g. Angular 5 / Preact ; they do not use themselves the Custom Element API, but still can be used as components, because they behave according to the conventions presented here.

It is about software architecture, not a certain tooling or library. Compare this to for example with MVC as an architecture style - the list of frameworks on http://todomvc.com/ is in no way complete and their issue tracker is flooded by Authors of other MVC implementations.

from micro-frontends.

Yes, the term "Micro Frontend" as defined by ThoughtWorks describes the an architecture with vertically organized end-to-end teams. On this site I'm describing a way to solve the frontend-integration challenge in the browser with existing web standards.

Facebook BigPipe and Zalando Mosaic Project also implement the Micro Frontend architecture, but they've build a custom integration platform to achieve this. Same goes for Microservice Websites, which describes a more server focused integration solution.

Coming back to the topic of this issue. In my examples Custom Elements are simply used as the boundaries and interface for a teams feature-component. What the teams use internally does not matter (from a system architectures point of view).

Defining a Custom Element by hand is quite simple, as I've tried to show in the article. I don't think we need additional tool-support here.

I would really like a future where we don't need special tools/frameworks to build good browser software. But we aren't there yet. I think Evan You (creator of Vue) summarized it aptly:

The problem is two-fold: people want component-oriented development experience, and interoperability. Currently web component is trying to solve both of them, but it turns out that it doesn’t solve the development experience issue very well on its own. IMO it is better if the spec focus on interoperability alone, and leave the dev experience part to frameworks.

from micro-frontends.

Haven't heard of them before. I'll look into them.
Generelly I'm trying to keep the site as framework/tool agnostic as possible. But it would definitly helpfull for people to also have more concrete examples or a starter-project for a specific stack (see also #4).

from micro-frontends.

More tools for webcomponents:

1. Polymer (https://www.polymer-project.org/)
2. slim.js (http://slimjs.com)
3. skate-js (https://github.com/skatejs/skatejs)
4. x-tag (https://x-tag.github.io/)

from micro-frontends.

Starter kit for slim.js (webpack, typescript or es6) - https://github.com/eavichay/slim-webpack-boilerplate

from micro-frontends.

I tend to agree, but the rising approach of "micro-frontends" does lead to solutions like web-components (IMHO it will eventually get there as the optimal solution) and these aren't treated enough. If libraries or ecosystems that works on top of this API are pushed aside, community will still be afraid to embrace those breakthroughs.

from micro-frontends.

Putting things in perspective: Micro-Frontends are an approach, to break the frontend monolith apart in function verticals. Quoting ThoughtWorks:

In this approach, a web application is broken up by its pages and features, with each feature being owned end-to-end by a single team. Source

Achieving this goal can be done in many different ways. Web Components are just one (and don't get me wrong; I think they are the best solution) way of achieving this.

Web Components allow for a complete and sound composition framework; that will ultimately allow to incorporate all other approaches.

The thing is, we might have different notions of what a Web Component actually is. For me - everything adhering to the outlined conventions - is a Web Component. That is technically speaking every HTMLUnknownElement (i.e. custom tag) that:

• communicates via Events
  • listen for specific _Custom Event_s on itself
  • emits specific _Custom Event_s on just itself (i.e. that do not bubble)
• can be parametrized with attributes
• is isolated in itself (i.e. everything can read from a single bundle file)
  • and thus should prevent leaking of inner styles, either via Shadow DOM or via scoped styles and ids

But I also agree with you @eavichay the compositional nature of Web Components is not stated clearly enough; although I do not blame @naltatis, because I think so far it simply has not been his goal to present a most generic solution, but a viable one working for his projects so far pretty well.

I am in the process of using this excellent work and formalizing it for a generic Micro-Frontend(TM) architecture, that we will use for further projects; if only time would be more lenient with me.

from micro-frontends.