It’s #FrontendFriday – Der Status Quo zu Microfrontend-Frameworks

07.10.2022

Yeah, es ist #FrontendFriday!

Im heutigen Blogpost möchte ich euch den Status Quo zu Microfrontend-Frameworks aufzeigen. In unserer Webfrontend-Forschungsgruppe beobachten wir ständig neue Technologien und Architekturen – so auch seit dem ersten Hype um das Buzzword Microfrontend. Im Rahmen der Evaluierung von Microfrontend-Frameworks konnte ich feststellen, dass sich besonders zwei Frameworks in den letzten Jahren als die Microfrontend-Frameworks etabliert haben. Diese möchte ich euch nun vorstellen.

Eines vorweg: seit dem Beginn der Microfrontends ist die Seite micro-frontends.org von Michael Geers ein must read, wenn es darum geht ein grundlegendes Verständnis von der Microfrontend-Thematik zu erhalten.
Microfrontends in action - book cover
Geers ist auch Autor des bekannten Buches “Microfrontends in Action”, welches ich ebenfalls nur wärmstens empfehlen kann.

Bevor man sich jedoch mit der Frage beschäftigt, welches Microfrontend-Framework für ein Projekt geeignet ist, muss man sich zwingend vorher die Frage stellen:

Wird ein Microfrontend wirklich benötigt?

(“wir wollen” !== “wir brauchen”)

Dies ist nur der Fall, wenn alle vier Fragen mit “ja” beantwortet werden.

  1. Generell: Steht im Projekt der Nutzen durch unabhängig voneinander deploybaren Einheiten in einem gesunden Verhältnis zum Integrationsaufwand?
    1. Ist absehbar, dass das Projekt zukünftig in mehreren Teams (min. 3 Teams mit jeweils mind. 2 Entwickler:innen) im Frontend umgesetzt wird?
    2. Ist der Einsatz von verschiedenen Technologien (Frameworks/Libraries) im Frontend notwendig – falls ja, warum?
  2. Wird auch im Backend eine vertikale Architektur (Microservices) eingesetzt?

Wird eine der Fragen mit “nein” beantwortet, muss man zwangsläufig kritisch in Frage stellen, ob eine Microfrontend-Architektur Sinn macht, d.h. wirtschaftlich und nachhaltig ist.

Verbreitung der Microfrontend-Frameworks


Quelle:https://www.npmtrends.com/qiankun-vs-@teambit/bit-vs-single-spa-vs-piral-vs-oc-vs-@luigi-project/client-vs-frint-vs-node-tailor-vs-puzzle.js
Mittels npm-trends.com lässt sich sehr gut ablesen, dass das Framework single-spa mit Abstand am häufigsten heruntergeladen und somit am weitesten verbreitet ist. An zweiter Stelle steht qiankun, welches auf single-spa aufbaut, und noch als “Newcomer” gilt.

Was unterscheidet die beiden Frameworks?

qiankun baut auf single-spa auf – das grundlegende Microfrontend-Setup unterscheidet sich jedoch. Deshalb ist je nach Anforderungen single-spa oder qiankun zu wählen.
Beide Frameworks lösen das Problem der Microfrontends sehr gut – jedoch auf verschiedene Weisen. Was genau die Unterschiede sind, wird in der folgenden Tabelle erläutert und soll bei Auswahl des Anwendungsfalls helfen.

single-spa qiankun
Leitspruch “javascript router for front-end microservices” “Probably the most complete micro-frontends solution you ever met”
“Micro-Granularität” Fein: Module-Loader (Microservice-Ansatz aus dem Backend bis ins Frontend).
→ Das Teilen von Common Libs, Funktionen und Variablen ist einfach(er). Keine strenge Entkoppelung.
Grob: App-Loader (der als “allgemein bekannte” Microfrontend-Ansatz).
→ Die Micro-Apps sind als getrennte, entkoppelte Anwendungen zu verstehen.
Entry-Mode JS Entry (über JS-Imports)
SystemJS
HTML Entry (über HTML-Tags)
JavaScript Sandbox Nein Ja
Style Isolation Nein Ja
Global State verfügbar Nein Ja
Module Federation Ja (Webpack 4 und 5) Nur unter Webpack 5 Apps
Visualisierung single-spa vs qiankun

Zusammengefasst kann man sagen, dass bei einer “feinen” Microfrontend-Architektur auf Modul-Basis single-spa das richtige Framework ist, und bei einer “groben” Microfrontend-Architektur mit gentrennten, eigenen Apps qiankun das Mittel der Wahl ist.

 

Mehr über Frontend Entwicklung lesen

Zurück zur Übersicht

Kommentar verfassen

Deine E-Mail-Adresse wird nicht veröffentlicht.

*Pflichtfelder

*