Websites herunterladen, die Storefront UI nutzen

Über Storefront UI

Eine Komponentenbibliothek soll eigentlich verschwinden. Der Build-Schritt kompiliert sie, der Bundler benennt um, was übrig bleibt, toter Code wird entfernt, und die Datei, die im Browser ankommt, ist ein gehashter Blob, auf dem kein Name mehr steht. Erkennt man eine solche Bibliothek von außen, dann ist etwas durchgesickert: ein Präfix in Klassennamen, das nie umgeschrieben wurde, ein Überbleibsel im Stylesheet, eine liegen gelassene Source Map, ein versehentlich ausgelieferter, nicht minifizierter Build.

Storefront UI ist genau eine solche Abhängigkeit, vom Anbieter Alokai unter der Lizenz MIT veröffentlicht und in TypeScript für Commerce-Oberflächen geschrieben. Der Einsatz der Bibliothek markiert keinen Funktionsumfang, sondern eine Architekturentscheidung. Ein Team, das zu einem speziell für den Handel gebauten Komponentensatz gegriffen hat, hat sein Frontend in der Regel bereits von Katalog und Checkout entkoppelt, was die Website ins Headless-Lager einordnet und nicht ins Lager der themebasierten Monolithen. Diese Trennung ist kommerziell wichtig, weil beide Gruppen völlig unterschiedliche Produkte kaufen und über völlig unterschiedliche Kanäle erreicht werden.

Stand Oktober 2026 verzeichnen wir die Bibliothek auf 21 Websites, und die tatsächliche installierte Basis ist größer. Mit Bescheidenheit hat das nichts zu tun, sondern mit der Arithmetik der Build-Werkzeuge: Moderne Pipelines sind genau dazu da, die Spuren zu entfernen, auf die die Erkennung angewiesen ist, und je besser die Build-Konfiguration eines Teams ist, desto unwahrscheinlicher ist es, dass wir es sehen. Lesen Sie die Zahl als Stichprobe erkennbarer Installationen, nicht als Maß für die Verbreitung. Die Verzerrung begünstigt Projekte, die Builds im Entwicklungsstil ausliefern, und benachteiligt die polierten Produktivinstallationen, die ein Anbieter am liebsten finden würde.

Die Bibliothek ist seit 2019 verfügbar und damit jung genug, dass sie bei Teams im Einsatz ist, die ihre Storefront erst vor Kurzem neu aufgebaut haben, und nicht bei Websites, die ein Jahrzehnt angesammelten Frontend-Code mitschleppen. Den Eintrag mit den anderen Technologien auf denselben Domains abzugleichen, ist daher aufschlussreicher als die Zahl allein, denn so sieht man, woraus ein kürzlich neu gebauter Commerce-Stack tatsächlich besteht: welches Framework, welches Backend, welche Zahlungs- und Suchanbieter mit ihm zusammen auftreten.

Gleich mehrere Zielgruppen wollen genau diese Schnittmenge. Anbieter, die in den Headless-Commerce-Markt verkaufen, brauchen die Domains, nicht die Summe. Agenturen, die entscheiden, für welchen Stack sie Personal aufbauen, wollen wissen, wo die Aufträge liegen. Maintainer wollen sehen, wo ihr Code gelandet ist. Sicherheitsteams, die Lieferketten im Frontend verfolgen, wollen wissen, welche Websites eine bestimmte Abhängigkeit erben, wenn eine Sicherheitsmeldung erscheint. Eine Abfrage pro Domain klärt keine dieser Fragen, denn jede davon betrifft eine Menge. Der Export ist diese Menge, und der Vorbehalt zur Erkennung ist schriftlich beigefügt, damit niemand eine Stichprobe mit einer Vollerhebung verwechselt.