Die beliebtesten Node.js-Frameworks im Jahr 2022
Veröffentlicht: 2022-04-15- Wie wurden diese Daten bezogen?
- Die aktuellen Node.js-Trends
- #1 – Next.js
- #2 – Nest
- #3 – Strapi
- #4 – Remixen
- #5 – Als nächstes
- #6 – SvelteKit
- #7 – Fasten
- #8 – Rotholz
- #9 – Express
- #10 – Adonis
- #11 – Schlussstein
- Meta, native und eine Prise Headless
Express.js ist so alt wie Node.js, und während Express immer noch ein phänomenales Back-End-Framework ist, hinterlässt eine neue Generation von Tools und Kits ihre Spuren.
Vor allem hat sich der Trend zu Meta -Frameworks verlagert, bei denen ein beliebtes Framework wie React umfunktioniert wird, um die Full-Stack-Entwicklung zu unterstützen. Der Vorteil dieses Ansatzes besteht darin, dass Sie Ihr Fachwissen in einem bestimmten Framework pflegen und gleichzeitig an Backend-Sachen arbeiten können. Mit anderen Worten, führen Sie eine Full-Stack-Entwicklung durch.
Wie wurden diese Daten bezogen?
Alle Daten stammen aus Umfragen wie State of JavaScript, Stack Overflow Developer Survey und persönlicher Erfahrung bei der Arbeit mit verschiedenen Projekten. Dies ist keine Bewertung, die darauf basiert, welches Node.js-Framework die meisten GitHub-Sterne hat.
Stattdessen habe ich die Anzahl der im vergangenen Jahr gewonnenen Sterne verglichen. Dies ist ein solider Indikator dafür, wie aktiv ein bestimmtes Projekt ist und wie gut Entwickler darauf reagieren.
Wenn Sie eines dieser Frameworks in einer Echtzeitumgebung ausprobieren möchten, lesen Sie meinen Artikel über Hosting-Plattformen für Entwickler. Jede Plattform hat einen kostenlosen Plan, und bei fast allen können Sie ein GitHub-Repo importieren und direkt hosten. ZB können Sie jedes Repo nehmen und es in wenigen Minuten live haben.
Die aktuellen Node.js-Trends
Sie werden in diesem Beitrag feststellen, dass viele der in diesem Artikel erwähnten Frameworks auf einem Front-End-Framework basieren. Dies wird auch als Meta-Framework bezeichnet. Also, was hat es damit auf sich und warum dieser Ansatz?
Wenn wir uns etwas wie React ansehen, erfolgt die Darstellung einer Seite durch CSR – Client-Side Rendering. Sobald eine Anfrage gestellt wird, erhält der Browser eine Barebones-HTML-Datei ohne den eigentlichen Seiteninhalt. Der Browser unternimmt also einen zweiten Rundgang, um das JavaScript-Dokument zu erhalten, das den Seiteninhalt enthält, liefert es dann aus und rendert die eigentliche Seite.
Und dies geschieht jedes Mal, wenn der Benutzer mit der Seite interagiert. Auch wenn der HTML-Code unverändert bleibt, bedeuten unterschiedliche Routenanforderungen, dass der Browser immer wieder hin und her gehen muss, um den vom Benutzer gewünschten Inhalt wiederzugeben.
Dies wird oft auch als SPA oder Single Page Application bezeichnet.
Und hier sind die Nachteile dieses – CSR – Ansatzes:
- Caching – Da der gesamte Seiteninhalt über JavaScript gerendert wird, gibt es keinen eigentlichen HTML-Inhalt auf der Seite, der zwischengespeichert werden kann.
- SEO – Während Crawler „intelligenter“ werden, gibt es definitive Probleme damit, dass Robots Inhalte indizieren, die ausschließlich von JavaScript abhängig sind.
- Rendern – Das anfängliche Rendern ist oft langsam und reagiert nicht, bis das gesamte JavaScript geladen ist.
In diesem Zusammenhang besteht die Idee hinter Frameworks wie Next und Nuxt also darin, das Front-End-Framework zu nehmen, ihm aber SSR (Server-Side Rendering) durch Node.js zu geben.
Apropos SSR – Nick Johnstone veröffentlichte einen interessanten Kernsatz mit dem Titel „Die absurde Komplexität des serverseitigen Renderings“. Und es gibt auch einen entsprechenden Hacker-News-Thread mit ziemlich vielen Diskussionen zum Thema. Obwohl sich in naher Zukunft nicht viel ändern wird, glaube ich, dass einige dieser Konzepte die Funktionsweise einiger Frameworks erheblich verändern werden.
#1 – Next.js

Mehr als ein React-Framework – Next.js wird dank eines absurd hohen Entwicklungstempos immer beliebter. Next.js 10 bis Next.js 12 dauerte nur ein Jahr.
Das Kernkonzept hinter Next.js besteht darin, dass es React als Grundlage verwendet, aber die gesamte serverseitige Rendering-Struktur durch seine eigene Spezifikation durchführt. Da das Rendern serverseitig erfolgt, müssen Sie Seiten nicht clientseitig rendern, was enorme Leistungsvorteile und SEO bietet, wenn es darum geht.
Einer der Gründe, warum Next eine solche Massenakzeptanz erfahren hat, ist, dass es die Notwendigkeit beseitigt, ein eigenes Back-End zu erstellen. Gleichzeitig bieten sie sinnvolle Möglichkeiten, die Leistung Ihrer Apps sofort zu optimieren. Vercel hält daran fest.
#2 – Nest

NestJS hat es in aller Stille geschafft, erhebliche Zustimmung von der Back-End-Community zu erhalten. Eine der Hauptphilosophien hinter Nest ist, dass Frameworks wie React zwar die Front-End-Entwicklung beschleunigen, viele solcher Frameworks jedoch Schwierigkeiten haben, das Problem der Anwendungsarchitektur zu lösen. Nest löst dies durch einen architekturorientierten Ansatz.
Was natürlich für das Backend spezifisch ist.
Nest basiert auf drei Kernkomponenten (inspiriert von Angular) – Controllers , Providers und Modules . Durch die Verwendung von Modulen versucht Nest, das Problem der komplexen Anwendungshierarchie zu lösen. Jede Komponente kann in einem separaten Modul kategorisiert werden, in dem Sie ihre eigenen Controller, Abhängigkeiten und spezifischen Anbieter konfigurieren.
#3 – Strapi

Headless ist der letzte Schrei in der aktuellen Front-End-Erzählung. Und Strapi hat großartige Arbeit geleistet, um sich als eines der führenden Headless-CMS-Frameworks zu positionieren.
Also, was ist Strapi? Praktisch gesehen ist Strapi das Back-End Ihrer Front-End-Anwendung. In gewisser Weise beseitigt Strapi die Notwendigkeit, ein Framework wie Express zu lernen, da es den größten Teil der Beinarbeit über seine API erledigen kann.
Dazu gehört die Verwaltung Ihrer Inhalte über eine benutzerdefinierte Benutzeroberfläche, On-the-Fly-Endpunkte für GraphQL und REST, Benutzerverwaltung (Rollen usw.) und eine separate Plugin-Schnittstelle, auf der Sie aufbauen können. Strapi ist vollständig Framework-agnostisch und lässt sich in praktisch jede Sprache, jedes Framework oder jede Front-End-Bibliothek integrieren.

#4 – Remixen

Remix ist ein Full-Stack-Framework, das von den Machern von React Router entwickelt wurde.
Ich glaube, dass Remix auch eines der am schnellsten wachsenden Full-Stack-Frameworks ist, die wir in den letzten Jahren gesehen haben. Also, wie kommt es? Zum einen versucht Remix, sich so weit wie möglich in Webstandards zu integrieren, indem es prägnante APIs für allgemeine Statuscodes und Benutzerinteraktionen bereitstellt.
Im Gegensatz zu einem traditionellen Framework erstellt Remix keine auf Wasserfall (Komponenten) basierenden Strukturen. Stattdessen werden die Daten serverseitig parallel geladen und dann als HTML-Seite bereitgestellt. Dies bedeutet auch, dass JavaScript-basierte Funktionen (wie das Absenden von Formularen) die Website nicht beschädigen, wenn der Benutzer JavaScript deaktiviert hat.
#5 – Als nächstes

Nuxt 3 (für Vue 3) befindet sich in der offenen Beta: Halten Sie die Augen offen.
Nuxt baut auf Vue als Full-Stack-Framework zum Erstellen robuster Anwendungen auf. Es ist auch ein Meta-Framework, das erstellt wurde, um die Erfahrung der Full-Stack-Vue-Entwicklung drastisch zu verbessern. Nuxt unterstützt SSR, SPA und statisch generierte Seiten.
Der Hauptvorteil für Vue-Entwickler besteht darin, dass Nuxt Ansichten vorab rendern und als statische Dateien bereitstellen kann. Dies hat natürlich großartige Ergebnisse für die SEO-Optimierung und sorgt für einen erheblichen Schub an Interaktivität. Aber es gibt auch einige Nachteile.
Während Vue über einen dauerhaften clientseitigen Kanal verfügt, hat Nuxt keinen. Daher könnte sich die Interaktion mit dem DOM als schwierig erweisen, nachdem Nuxt die Seite bereits gerendert hat.
#6 – SvelteKit

Svelte hat den Cool-Kid-Status in der aktuellen Front-End-Ära, und das Team arbeitet an SvelteKit – einem Full-Stack-Framework, das auf Sapper aufbaut (es ersetzt). SvelteKit zeichnet sich durch ein kompliziertes dateibasiertes Routing-System aus.
Das Hauptziel von SvelteKit ist es, die Webentwicklung zu beschleunigen, indem einige der häufigeren Engpässe beseitigt werden. Durch die Implementierung von Snowpack, Vite und anderen externen Tools kann SvelteKit ein funktionsreiches Entwicklungserlebnis bieten.
Schließlich implementiert SvelteKit den Prozess der Hydration. Die Fähigkeit, den aktiven Zustand für serverseitig gerenderte DOM-Elemente beizubehalten.
#7 – Fasten

Beim Fastify-Framework dreht sich alles um Leistung, und einzelne Benchmarks haben gezeigt, dass es bis zu 60.000 Anfragen pro Sekunde verarbeiten kann. Sie können Fastify (zusätzlich zu bereits großartigen Tools) durch Hooks und Plugins erweitern. Und obwohl Fastify kein TypeScript-First-Framework ist, unterstützt es TypeScript.
Apropos Plugins, ein Großteil der Fastify-Entwicklung erfolgt über sie. So sehr, dass Fastify ein offizielles Repository sowohl für von der Community erstellte als auch für vom Fastify-Team erstellte Plugins hat. Die Idee hinter Plugins ist, dass sie eine saubere Systemarchitektur bieten und den Wechsel zu alternativen Frameworks überflüssig machen. Dies macht Fastify besonders nützlich für die Erstellung von APIs mit geringem Overhead und starker Echtzeitleistung.
#8 – Rotholz

Liebst du APIs? Magst du JAMStack? Wenn die Antwort ja lautet, werden Sie RedwoodJS lieben. Es ist ein Full-Stack-Web-App-Framework, das viele moderne Technologien nutzt. Und diese Technologien umfassen GraphQL, Prisma, Storybook und Jest. Das Frontend in Redwood baut auf React auf, und Sie erhalten auch vollständige TypeScript-Unterstützung.
#9 – Express

Ist Express in Ungnade gefallen? Nicht genau. Das Framework ist immer noch sehr beliebt und beliebt, nur nicht so sehr wie die anderen großen Player. Für ein Team, das seit Jahren mit Express arbeitet, macht es keinen Sinn, auf etwas anderes umzusteigen, da es keine grundlegenden Probleme gibt. Viele Frameworks bauen immer noch auf Express auf.
#10 – Adonis

Adonis ist ein auf TypeScript basierendes Back-End-MVC-Framework, das für Node.js entwickelt wurde. Denken Sie daran, dass Adonis, obwohl es sich selbst als Back-End-Framework bezeichnet, genauso gut eine Full-Stack-Entwicklung damit durchführen kann.
Einer der Hauptgründe, warum Entwickler Adonis lieben, ist die native Unterstützung für TypeScript.
Aber auch Unterstützung für ORM (Object Relational-Mapping), starke Sicherheitspraktiken und leicht verständliche Dokumentation.
Zu guter Letzt lässt sich Adonis auf einer grundlegenden Ebene in das Node.js-Ökosystem integrieren, sodass Vorkenntnisse in der Node-Entwicklung so ziemlich ein Muss sind.
#11 – Schlussstein

Das letzte Node.js-Framework in dieser Liste ist Keystone. Und ähnlich wie Express gibt es es fast seit dem ersten Tag. Dies macht Keystone zu einem ausgereiften Framework, das konkrete Werkzeuge und Integrationen bereitstellt, um ein entwicklerfreundliches Erlebnis zu schaffen.
Einige bemerkenswerte Funktionen (von denen viele im Laufe der Jahre verfeinert wurden) in Keystone umfassen automatisiertes CRUD über die GraphQL-API, die Sie weiter ausbauen können. Darüber hinaus können Sie Ihre eigenen React.js-Komponenten erstellen und implementieren.
Keystone wird in verschiedenen Entwicklungsbereichen verwendet und funktioniert gut mit mobilen Apps, praktischen Websites, E-Commerce-Schaufenstern und vielem mehr.
Meta, native und eine Prise Headless
Es ist schon eine ganze Weile her, seit ich das letzte Mal eine solche Übersicht erstellt habe. Damals waren die Dinge viel einfacher, und während Compound und Locomotive nirgends zu finden sind, ist es schön zu sehen, wie Keystone und Express ihren Weg durch den Test der Zeit gehen.
Ich kann auch sagen, dass es ziemlich viel Wirbel um Node.js gibt. Ich glaube, einige Leute sind unglücklich und fühlen sich damit festgefahren . Und auch die Idee von Paketmanagern (npm) beginnt sich zu veralten, da Pakete einem ansonsten kleinen Projekt immer mehr Haufen unnötiger Bündelgrößen hinzufügen.
Aber was auch immer der Fall sein mag, die Popularität jedes Frameworks spricht für sich. Insgesamt arbeiten Entwickler gerne mit Meta-Frameworks, was möglicherweise damit zu tun hat, dass es auch die Full-Stack-Entwicklung rationalisiert. Dadurch entfällt größtenteils die Notwendigkeit, ein neues Lieblingsframework von Grund auf neu zu lernen.