Nuxt 3: Schneller, schlanker, besser

NuxtJS hat das Release von Nuxt 3 für Herbst 2022 angekündigt. Frontend-Development-Experte Lukas Heinze arbeitet schon seit vielen Monaten mit der Beta-Version des Vue-basierten Frameworks. Im Interview erzählt er, was Nuxt 3 kann.

Was sind die wichtigsten neuen Features von Nuxt 3?

Lukas: Nuxt 3 punktet vor allem bei der Performance. Die Applikation ist um ein Vielfaches schlanker und schneller als die Vorgängerversionen. Und das sowohl clientseitig als auch im Hinblick auf den “Build”. Das liegt zum einen an den Optimierungen von Vue 3 und zum anderen daran, dass Nuxt 3 eine komplett neu entwickelte Server Engine hat: “Nitro”.

Inwiefern verbessert Nitro die Performance von Nuxt 3?

Lukas: Wenn man eine Applikation baut, muss menschenlesbarer Code in maschinenlesbaren Code umgewandelt werden. Das bezeichnet man als “Build”. Bei den Vorgängerversionen von Nuxt musste man alle Abhängigkeiten und Submodule gebündelt auf einen Server schieben. So ein Applikations-Build war dann durchaus mal ein paar 100 MB groß. Die neue Bauweise von Nitro macht Server Deployments bis zu 75 Mal schlanker und damit auch schneller. Wenn man jetzt eine Demo mit Nuxt 3 baut, ist diese nur noch etwa 5 MB groß. Das macht natürlich einen riesigen Unterschied für die Performance. Gleichzeitig ist es auch praktischer und skalierbarer, mit weniger Daten zu arbeiten.

Bringt Nitro noch weitere Vorteile?

Lukas: Man kann den Ordner einfach auf einen Server schieben und die ganze Anwendung läuft dann out-of-the-box. Das funktioniert bei sämtlichen Hosting-Anbietern, bei denen NodeJS-Server laufen. Auch das ist eine enorme Arbeitserleichterung.

Du hast vorhin erwähnt, dass auch Vue 3 in Sachen Performance optimiert wurde. Wie wirkt sich das auf Nuxt 3 aus?

Lukas: Da NuxtJS auf VueJS basiert, fließen auch die Optimierungen der neuesten Vue-Version in Nuxt 3 mit ein. Die wichtigsten Features von Vue 3 haben wir in unserem Blog schon einmal näher beschrieben. Eine der entscheidenden Neuerungen: Vue 3 ist modular aufgebaut. Die einzelnen Funktionen können unabhängig voneinander verwendet werden. Das macht die ganze Anwendung schlanker und schneller, was sich positiv auf die Performance auswirkt. Davon profitiert auch Nuxt 3.

Welche weiteren Features von Vue 3 finden sich auch in Nuxt 3 wieder?

Lukas: Die wichtigste Neuerung von Vue 3 ist aus meiner Sicht die Composition API. Diese steht für “true code re-usability”. Das heißt konkret: Alles, was man im Laufe eines Projektes entwickelt, lässt sich an anderen Stellen wiederverwenden. Dadurch generiert man eine stabile Code-Basis, die sich in verschiedenen Projekten wieder einsetzen lässt. Das bringt gerade für uns als Agentur einen großen Skalierungseffekt mit sich. Für unsere Kunden bedeutet das eine schnellere Time-to-market. Sie können schneller mit ihrer E-Commerce-Anwendung live gehen und Umsätze generieren.

Die Time-to-market ist ein gutes Stichwort. Welche weiteren Funktionen von Nuxt 3 erhöhen die Entwicklungsgeschwindigkeit?

Lukas: Da gibt es eine ganze Reihe an Features: Nuxt CLI, Nuxt DevTools, Nuxt Kit, webpack 5 und Vite sind allesamt Tools, die die Entwicklung eines Nuxt-Moduls leichter und schneller machen. Der Prozess für die Modul-Entwicklung war in Nuxt 2 noch etwas hakelig und wurde in Nuxt 3 u.a. durch Nuxt Kit erheblich verbessert. Es gibt jetzt neue Workflows, ein fertiges Starter-Template und viele weitere Helferlein, mit denen man viel einfacher Module bauen kann. Nuxt Kit haben wir zum Beispiel auch für die Weiterentwicklung unserer PWA hubble verwendet. Darauf gehe ich später noch genauer ein.

Es gab in der Vergangenheit immer wieder Probleme mit JavaScript und SEO. Woran liegt das genau und bringt Nuxt 3 dafür eine Lösung?

Lukas: SPA (Single Page Applications) und PWA (Progressive Web Apps), die auf JavaScript basieren, werden teilweise von den Crawlern der Suchmaschinen nicht richtig ausgelesen. Das liegt daran, dass JS clientseitig gerendert wird (CSR) und dieser Prozess für die Suchmaschinen sehr zeit- und kostenintensiv ist.

Um mit einer JS-basierten PWA sicher im Suchranking gelistet zu werden, muss sichergestellt werden, dass der Googlecrawler und andere Bots eine gerenderte Version, d.h. eine vollständig generierte Seite erhalten. Das ist beim serverseitigen Rendern (SSR) sowie bei statischen Seiten (“Static Site Generation", kurz SSG) der Fall. 

Früher musste man sich für eine Art des Renderns entscheiden: Entweder renderte man alle Seiten statisch während des Build-Prozesses. Das ist zwar besser für die Performance, aber problematisch bei Applikationen mit vielen dynamischen Seiten, wie z.B. für den Katalog eines Onlineshops. Die zweite Möglichkeit war, alle Seiten dynamisch beim Seitenaufruf vom Server rendern zu lassen. Das dauert zwar seine Zeit, die Seiten können dafür aber leichter von Suchmaschinen gelesen werden. 

Nuxt 3 will diese Problematik nun lösen, indem es ein hybrides Rendering-Modell, also eine Kombination aus statischem und dynamischem Rendern, benutzt. Allerdings ist dieses Feature momentan bei Nuxt 3 noch nicht implementiert. Die Weichen dafür sind aber gestellt.

Bringt das hybride Rendern neben SEO noch weitere Vorteile?

Lukas: Das hybride Rendering wirkt sich ebenfalls positiv auf die gesamte Performance aus. Man kann besser zwischen dynamischen und statischen Inhalten unterteilen. Statisch generierte Seiten können so schneller geladen werden, als wenn sie jedes Mal neu gerendert werden müssen. Das ist auch aus Entwicklersicht vorteilhaft. Bei Seiten, die serverseitig gerendert werden, muss man manchmal etwas aufpassen, weil manche Funktionen im Code nicht zur Verfügung stehen. Dieses Problem gibt es bei statisch generierten Seiten nicht.

Du hast bereits einige Vorteile, die Nuxt 3 mit sich bringt, erwähnt ‒ u.a. Verbesserungen in den Bereichen Performance, Entwicklung, Time-to-market und SEO. Gibt es noch weitere Neuerungen?

Lukas: Eine weitere wichtige neue Funktion von Nuxt 3 ist TypeScript. TypeScript wurde von Microsoft entwickelt und ist ein sogenanntes Super-Set von JavaScript. Das bedeutet, die Skriptsprache kann alles, was JavaScript auch kann, bringt aber eine wichtige zusätzliche Funktion mit: eine strikte Typisierung, die für einen stabilen Code sorgt. 

TypeScript erkennt Fehler schon im Entwicklungsprozess, während man den Code in der IDE schreibt. Früher hat man erst eine Fehlermeldung bekommen, wenn man die Anwendung im Browser ausgeführt hat. Dann musste man sich auf die Suche nach dem Fehler im Code machen. TypeScript zeigt Fehler hingegen schon während des Schreibens an und hat zudem eine Autocompletion. Man definiert am Anfang einmalig die Typen, die man beim Programmieren verwenden wird, und TypeScript schlägt diese dann in der IDE vor. Vorher musste man selbst aufpassen, welchen Datentypen sich hinter den Variablen verbergen, was natürlich eine viel höhere Fehleranfälligkeit bedeutete. TypeScript ist ein enormer Benefit für die Entwicklung. Wir haben es für die Weiterentwicklung unserer PWA hubble genutzt und waren begeistert.

Kommen wir nun zu hubble. Du hast die Progressive Web App maßgeblich mitentwickelt. Welche neuen Features bietet “hubble next”, die neue Version der PWA?

Lukas: Alle der genannten Vorteile von Nuxt 3 und Vue 3 finden sich auch in hubble next wieder. Ein Beispiel: Während wir in der früheren PWA-Version nur eine Verbindung zu Shopware 6 hergestellt hatten, ist hubble next nun Plattform-unabhängig. Die Composition API von Vue 3 hat die Grundlage dafür geschaffen.

Darüber hinaus sind selbstverständlich alle Features der Vorgängerversion der PWA auch in hubble next enthalten ‒ beispielsweise der Fokus auf Mobile Commerce, der modulare Aufbau und die herausragende Performance. 

Kannst du einmal für Menschen mit weniger Entwickler-Kenntnissen erklären, wie die Composition API funktioniert? ;-)

Lukas: Klar! Die Composition API besteht aus sogenannten “Composables”. “To Compose” bedeutet so viel wie “zusammenstellen” oder auch “komponieren”. In der Musik wären die Composables einzelne Noten, aus denen verschiedenste Lieder entstehen können. In der Entwicklung sind Composables wiederverwendbare Code-Schnipsel. Genau wie die Noten in der Musik, sind diese Composables generisch und können für sämtliche Projekte wiederverwendet werden. Wir haben hubble next mithilfe der Composables abstrakter gestaltet. Durch die Composition API lässt sich die PWA nun schnell und unkompliziert mit allen möglichen Headless-Commerce-Plattformen verbinden.

Hast du ein konkretes Beispiel dafür, wie ihr die Composition API für hubble next nutzt?

Lukas: Die frühere Version der PWA mussten wir an jede Plattform spezifisch anpassen. Denn jedes Shopsystem verwendet verschiedene Begriffe für die jeweiligen Daten und Objekte. So heißen die Artikel im Warenkorb zum Beispiel bei Shopware “line items”, bei Magento “catalog items” und bei anderen Plattformen wieder anders. Sie meinen aber alle das Gleiche. Die frühere PWA-Version hat nur die Sprache der Daten verstanden, wie Shopware 6 sie ausgeliefert hat. Hubble next ist nun sozusagen multilingual. 

Anstelle von “get line items” für Shopware oder “get catalog items” für Magneto, nutzen wir nun den Befehl “get cart”, also frei übersetzt “hol dir den Warenkorb”, als generische Funktion. So machen wir das für sämtliche Komponenten. Die Composables beziehen dann in der Sprache der Plattform die Daten und übersetzen diese in ein allgemein gültiges Format, das hubble next versteht.

Du hast vorhin erwähnt, dass ihr auch TypeScript für hubble next verwendet. Kannst du darauf nochmal näher eingehen?

Lukas:  Wir haben in TypeScript definiert, wie die Daten, die hubble next als Composable von den Plattformen empfängt, genau aussehen sollen. Bleiben wir beim Beispiel “get cart”. In TypeScript definieren wir den genauen Typ dieser Composable, also den Namen, die Codierung usw. Die Composables beziehen die Daten von dem jeweiligen Shopsystem und wandeln sie so um, dass sie unseren definierten Typen entsprechen.

Gibt es noch weitere Neuerungen in hubble next?

Lukas: Die PWA bietet nun einen Multilanguage Support. Das ist besonders für international agierende Unternehmen interessant. Neu ist auch der API-Client für Shopware 6. Dieser basiert ebenfalls auf TypeScript. Hubble next wächst jetzt quasi mit Shopware mit.

Wie genau nutzt ihr den Shopware 6 API-Client für hubble next?

Lukas: Aus der Shopware API lässt sich programmatisch ein API-Client generieren, da Shopware ihre Store-API vorbildlich nach der OpenAPI Spezifikation geschrieben hat. Bei jedem Shopware-Update können wir im neu generierten API-Client sehen, welche Dateien sich genau verändert haben, und können dann darauf reagieren. Das war vorher nicht so. Da mussten wir händisch die Release Notes und den Code nach Änderungen durchforsten, um dann zu überlegen, ob diese Auswirkungen auf unsere Integration mit der PWA haben könnten. Da konnte es natürlich schnell passieren, dass man mal etwas übersieht. Durch den API-Client haben wir nun einen effizienten Workflow. Darüber hinaus können wir dank des API-Clients jetzt auch genau angeben, mit welcher Shopware-6-Version hubble next kompatibel ist.

Was hat sich im Frontend von hubble verändert?

Lukas: Da hat sich einiges getan. Dank der Composition API können wir unsere Templates stärker von der Business-Logik trennen, was uns erlaubt, verschiedene Themes anzubieten. Der Check-out ist zum Beispiel komplett neu. So gibt es jetzt ein “Default Theme”. Das alte habe ich komplett überarbeitet und setze jetzt auf Tailwind CSS zusammen mit daisyUI. Tailwind ist ein sehr beliebtes CSS-Framework, das nach dem Utility-First-Ansatz arbeitet, mit dem man “Pixel perfect” stylen kann. Der einzige Nachteil daran ist aus meiner Sicht, dass die Klassen die Templates unglaublich aufblähen. Es geht ganz schnell, dass man so viele Klassen hat, dass man das Template nicht mehr richtig lesen kann. 

Hier kommt daisyUI ins Spiel. Die Component Library bündelt Klassen für die gängigsten Elemente eines Interfaces in konfigurierbare Komponenten. So können wir die vielen Individualisierungsmöglichkeiten von Tailwind CSS nutzen, halten aber gleichzeitig die Templates schon aufgeräumt. Zusätzlich bietet daisyUI einige Variablen, mit denen man super schnell und einfach das gesamte Look & Feel des Onlineshops verändern kann.

Ist hubble next bereits production-ready?

Lukas: Ja! Wir haben die PWA parallel zu den Nuxt 3 Release Candidates entwickelt. Nun ist sie fertig und steht in den Startlöchern. Sobald die finale Version von Nuxt 3 released wird, geht auch hubble next an den Start und ist sofort einsatzbereit. Wir starten gerade unser erstes Kundenprojekt mit der PWA. Dafür haben wir bereits Shopware 6 integriert und planen im nächsten Schritt die Integration weiterer Plattformen. Dank des neuen Aufbaus mit der Composition API und TypeScript erwarten wir, dass das sehr schnell und unkompliziert funktionieren wird.