Die Benchmark-Ergebnisse für Next.js 12 können überzeugen. Aber lohnt sich der Wechsel?

Bei unserem letzten Teambuilding-Event habe ich einen Vortrag darüber gehalten, warum JavaScript-Entwickler ihre Tools nach Rust verlagern. Es war ein ziemlich gut aufgenommener Vortrag und wir entschieden, dass es cool wäre, ihn mit der Welt zu teilen. Hier ist es also. Dies ist die bearbeitete Version des Vortrags, die zum Lesen geschrieben wurde, und es wird einen Screencast auf unserem Podcast-Kanal geben. Tauchen wir also direkt ein.

Hintergrund

Ein allgemeiner Trend in der Softwarebranche besteht darin, die Tools, die wir als Entwickler zum Erstellen unserer Anwendungen verwenden, in derselben Sprache zu schreiben, die wir zum Erstellen von Anwendungen verwenden. Zum Beispiel ist pip in Python geschrieben, Composer ist in PHP geschrieben, Maven in Java usw. Dies ist sinnvoll, da die Leute, die die Tools erstellen, meistens auch diejenigen sind, die sie verwenden. So ist es einfacher, einfach in der Sprache ihrer Wahl zu arbeiten.

JavaScript ist keine Ausnahme. Von Gulp und Bower bis babel und Webpack haben wir alles in JavaScript geschrieben. Das funktionierte gut für uns, aber es gab ein paar Probleme.

Das Problem mit JavaScript

Um das Problem zu sehen, müssen wir uns die Eigenschaften von JavaScript ansehen. JavaScript ist eine leichtgewichtige Skriptsprache für Webseiten. Sicher, wir verwenden es jetzt überall, von Backends bis zu Datenbanken, aber es wurde ursprünglich dafür gemacht, zuerst Seiten glänzend zu machen und alles andere erst danach, was sich zeigt.

Es ist eine interpretierte Sprache, die just-in-time kompiliert werden kann und Single-Threaded ist. Ja, ja, ich weiß, wie man mehrere Instanzen hochfährt und mit Webworkern kommuniziert … aber meiner Meinung nach ist das kein Multi-Threading, das ist ein seltsamer Voodoo-Workaround, der versucht, uns von der Tatsache abzulenken, dass wir kein natives Multi-Threading haben .

Ein größeres Problem ist, dass es auf der Konsole im Vergleich zu anderen Sprachen ziemlich langsam ist.

Während JavaScript auf einer Seite fantastisch ist, ist es auf einer Konsole irgendwie scheiße.

Eines Tages trafen sich ein paar JavaScript-Entwickler in einem dunklen Raum und nach einem Drink zu viel sagte jemand:

„Hey Leute, was ist, wenn … hört mir zu … was, wenn wir die Tools, die unser JavaScript erstellen, nicht in JavaScript schreiben?“

Es gab ein kollektives Keuchen, Stühle wurden geworfen, Kämpfe brachen aus und nachdem sich der Staub gelegt hatte, stimmten alle zu, es auszuprobieren.

Ok, das habe ich mir vielleicht ausgedacht, aber das Ergebnis ist immer noch dasselbe, wir erstellen jetzt JavaScript-Build-Tools in anderen Sprachen als JavaScript.

Aber warum Rost?

In einem Wort… Geschwindigkeit und Pufferüberläufe .

Rust ist eine universelle Programmiersprache mit mehreren Paradigmen, die auf Leistung und Sicherheit ausgelegt ist. Es ist wie C++, aber für Millennials und Zoomer. Es ist eine Systemsprache, die Speichersicherheit erzwingt und eine „sichere“ Parallelität hat. Es ist syntaktisch ähnlich wie C++ und was noch wichtiger ist, es ist fast so schnell wie C++.

Vielversprechende Behauptungen

Es gibt derzeit eine Reihe von Projekten, die darauf abzielen, JavaScript-Tools durch Rust-basierte zu ersetzen. Einige Beispiele sind ParcelJS, Deno, ESBuild und der Speedy Web Compiler (SWC). Sie alle behaupten, schneller zu sein als alles, was sie zu ersetzen versuchen, und wenn Sie lachen wollen, sehen Sie sich den Vergleich von Esbuild an .

Für diesen Beitrag werde ich nicht alle überprüfen, aber ich werde SWC über Next.js genauer unter die Lupe nehmen.

Schneller Web-Compiler (SWC)

SWC ist eine erweiterbare, auf Rust basierende Plattform für die nächste Generation schneller Entwicklertools. Das heißt, es ist ein Framework zum Erstellen von Buildern. Sie können SWC sowohl zum Kompilieren als auch zum Bündeln verwenden. Es nimmt JavaScript-/TypeScript-Dateien mit modernen JavaScript-Funktionen und spuckt gültigen Code aus, der von allen gängigen Browsern unterstützt wird.

Die neuesten Next.js Rusty-Tools

Next.js hat in Version 12 einen Rust-Compiler auf Basis von SWC eingeführt. Auf der Next.js-Site behaupteten sie, dass sie lokal ~3x schneller aktualisieren und ~5x schnellere Produktions-Builds erstellen.

Das klingt für mich nach einer überprüfbaren Behauptung. Also habe ich es getestet.

Ich habe genau das gleiche Projekt in den Versionen 11 und 12 erstellt und die gleichen 400 generierten Komponenten hinzugefügt. Ich habe dafür den React Benchmark Generator verwendet . Der einzige Unterschied zwischen den Projekten war die Version von Next.js, alles andere war identisch.

Die Ergebnisse waren ziemlich überzeugend. Hier ist für Next.js 11:

Und für Next.js 12, los geht's:

Next.js 12 benötigte 12 Sekunden, um das zu tun, was Next.js 11 in 1 Minute 40 Sekunden tat. Das ist ungefähr 8 mal schneller. Sie haben also eindeutig nicht übertrieben.

Ich habe auch nicht erwartet, dass Next.js 12 12 Sekunden braucht. Denke das war ein glücklicher Zufall.

Ist es den Hype wert?

Jetzt ist die naheliegende Frage: Lohnt sich der Aufwand?

Die Anwendung, die wir am Ende des Tages erstellen, ist dieselbe, richtig? Dies ändert nicht die Endbenutzererfahrung, sondern nur die Entwicklererfahrung, also warum sich die Mühe machen? Warum etwas reparieren, das bereits gut funktioniert hat?

Weil es nicht gut funktionierte. Wie ich bereits sagte, ist JavaScript großartig auf einer Seite, aber scheiße auf einer Konsole. Entwicklermaschinen sind mächtige Bestien, und diese Kraft nicht zu nutzen, ist eine schreckliche Verschwendung. Es ist auch eine teure Verschwendung.

Stellen Sie sich vor, Sie sind in einem Team von 20 Entwicklern, die an einem großen Projekt arbeiten, das auf einem Cloud-basierten CI bereitgestellt und getestet wird. Jeden Tag veröffentlicht jedes Mitglied Ihres Teams mehrere Fehlerbehebungen und Funktionen. Hier ist, was wahrscheinlich passieren wird.

Wenn Ihr CI unbegrenzte gleichzeitige Builds bietet, aber nach Build-Minute oder nach Sekunden Prozessorzeit abgerechnet wird, kostet Next.js Sie buchstäblich 8-mal mehr als Next.js 12.

Wenn es andererseits einen Festpreis und eine feste Anzahl gleichzeitiger Builds gibt, müssen Sie eine Weile warten, wenn Ihre Build-Warteschlange wächst, oder Sie müssen bezahlen, um die Anzahl gleichzeitiger Builds zu erhöhen, die Sie ausführen können.

In jedem Fall kosten Sie langsame Builds mehr Zeit oder Geld oder beides.

Fazit

JavaScript ist eine erstaunliche Sprache und das Internet wäre ohne sie nicht dort, wo es ist. Aber wir müssen es nicht verwenden, um unsere Tools zu bauen, denn dafür gibt es schwierigere, bessere, schnellere und stärkere Sprachen wie Rust, und das ist in Ordnung. Es nimmt nichts von JavaScript weg und es ist kein Verrat, JavaScript-basierte Tools für schnellere Rust-basierte Tools fallen zu lassen. Und seien wir ehrlich, ich werde nicht durch mehrere JavaScript-Instanzen leiden, nur um Voodoo-Multithreading zu bekommen.