Gerade auf îles gestoßen, einem neuen Static Site Generator, der sich hauptsächlich um Vue dreht. Die Welt hat keinen Mangel an Static Site Generatoren, aber es ist interessant zu sehen, worauf sich diese „nächste Generation“ von SSGs konzentriert oder was sie zu lösen versucht.
îles scheint sich stark von Astro inspirieren zu lassen. Wenn wir sie zusammen mit anderen aufkommenden und sich schnell entwickelnden SSGs betrachten, gibt es einige Ähnlichkeiten.
- Versenden standardmäßig null JavaScript. Interaktive Teile sind optional – darum geht es bei der Insel-Metapher. Astro und îles tun dies auf Komponentenebene und SvelteKit bevorzugt dies auf Seitenebene.
- Zusätzliche Raffinesse bei der Steuerung, wann die Hydration stattfindet, wie „wenn der Browser im Leerlauf ist“ oder „wenn die Komponente sichtbar ist“.
- Verwenden Sie ein schnelles Build-Tool wie Vite, das unter der Haube auf Go basierendes esbuild verwendet. Oder auf Rust basierendes swc im Fall von Next 12.
- Unterstützung mehrerer JavaScript-Frameworks für Komponenten. Astro und îles tun dies sofort, und ein weiteres Beispiel ist, wie Slinkity dies zu Eleventy bringt.
- Dateisystem-basiertes Routing.
- Annahme, dass Markdown für Inhalte verwendet wird.
Wenn man diese mit SSGs der ersten Kohorte, wie Jekyll, vergleicht, habe ich ein paar Gefühle.
- Diese sind eigentlich nicht *so* anders. Der Funktionsumfang ist weitgehend derselbe.
- Die größte Veränderung ist wahrscheinlich, dass weit mehr von ihnen auf JavaScript-Bibliotheken basieren. Es stellt sich heraus, dass JavaScript-Bibliotheken das sind, was die Leute wirklich von HTML-Präprozessoren wollten, vielleicht wegen des starken Fokus auf Komponenten.
- Sie sind inkrementell besser. Sie sind schneller, das Live-Reloading ist besser, die häufigsten Bedürfnisse wurden ausgemerzt.
Ihre Website hängt jetzt von einer Abermillion von npm-Paketen ab, die eines Tages kaputt/inkompatibel werden könnten.
Ahh PHP-Entwickler. Muss man sie lieben
Die größten Verbesserungen, die für mich wichtig sind, scheinen mit der Raffinesse rund um die Hydration zusammenzuhängen. Die Vereinfachung dieser JavaScript-Aspekte in einer Einzeiler hat einen enormen Einfluss auf die Entwicklung gehabt. Es macht den Bau der Website selbst viel spaßiger, da ich mich auf die Website und nicht auf die Tools zur Erstellung der Website konzentriere.
Wie vergleicht sich Hugo mit diesen? Lohnt sich überhaupt ein Vergleich?
Wir haben an einer neuen Website für unsere Landingpages gearbeitet und Prototypen mit Hugo und Astro entwickelt. Ich würde sagen, der größte Unterschied ist, dass Astro (habe mir íles nicht angesehen, aber ich stelle mir vor, dass es Astro ähnlich ist) JSX-basiert und weitgehend unopinionated ist, während Hugo eher ein strenges Templating-System ist.
Es scheint, dass Astro aus folgenden Gründen für uns gewinnt.
1) In Astro können Stile auf Komponenten beschränkt werden, was bedeutet, dass, wenn die Komponente nicht enthalten ist, auch ihre Stile nicht enthalten sind. Das konnten wir mit Hugo nicht erreichen. Obwohl es ein Asset-Management-System hat, hat es kein Konzept von komponenten-beschränkten Stilen. Nicht, dass ich hier das Ende der Fahnenstange erreicht habe, aber ich habe ein paar Stunden versucht, es zu schaffen und konnte es nicht. Man müsste Hugo wahrscheinlich forken und einen eigenen Binärcode mit dieser Funktion erstellen.
2) Mit Astro können Sie die volle Leistung eines modernen Frontend-Frameworks nutzen, ohne Client-seitige Kosten (es sei denn, Sie entscheiden sich dafür auf Komponentenebene). Das Ökosystem rund um diese Frameworks ist in den letzten Jahren explodiert und ich finde es angenehm, damit zu arbeiten. Die Entwicklungswerkzeuge sind fantastisch. Die Konzepte von Komponenten, die gemountet, ungemountet werden und Seiteneffekte bei Zustandsänderungen ausführen, finde ich in den neueren Frameworks einfacher zu realisieren als mit vanilla JavaScript (weil genau dafür sie gemacht wurden). Mit Hugo schreiben Sie Ihr JavaScript separat vom HTML. Das ist in Ordnung, aber ich genieße es, JavaScript in {react, svelte, etc.} zu schreiben, weil sie komplexe Dinge ziemlich einfach machen. Außerdem liebe ich es, HTML, CSS und JS im selben Dateiformat zu haben. Gepaart mit der Komponenten-/JSX-Ideologie finde ich das alles eine vernünftigere Art, eine Website zu entwickeln. Alle Abhängigkeiten können berücksichtigt werden und Sie wissen genau, wofür Ihr CSS und JS gedacht ist.
3) Mein letzter Punkt knüpft auch an die Tatsache an, dass man mit Astro viel Asset-Management-Magie bekommt, die man bei Hugo nicht findet, weil Astro ein Produkt der modernen Werkzeugkette ist. Es wird kluge Entscheidungen darüber treffen, was mit CSS und JavaScript geschehen soll.
Sicher, es gibt noch mehr Gründe, aber das ist schon ein ziemlich langer Kommentar!
Ich stimme vollkommen zu, dass sie sich sehr ähnlich sind, tatsächlich ist Jekyll eine große Inspiration für îles.
Ich habe mit îles begonnen, nachdem ich Jekyll Vite veröffentlicht hatte und das Gefühl hatte, dass die Komponentenentwicklung immer noch umständlich war (include-Tags).
Ich vermisse immer noch einige der Annehmlichkeiten von Jekyll bezüglich Collections, plane aber, das bald abzudecken.
Ich würde auch argumentieren, dass das Asset-Management in diesen modernen Tools viel einfacher ist, dank Vite. Man kann jedes Tool verwenden, ohne darauf zu warten, dass eine gute Seele es in ein Ruby-Gem verpackt.
Ein weiterer Vorteil dieser neuen Tools ist, dass sie die Komponenten vorrendern können, die dann hydriert werden, was FOUC und Layoutverschiebungen verhindert.
Dies führt zu einer spürbaren Verbesserung der Benutzerfreundlichkeit einer Website.
Ich unterstütze die Frage von Joeee, wie vergleichen sich diese neuen JS-basierten SSGs mit dem Go-basierten Hugo?
Holen sie nur auf? Hugo hatte bereits die Geschwindigkeit und das dateisystembasierte Routing.
Ich würde gerne eine Übersicht darüber sehen, was die neuesten SSGs hinzufügen, was Hugo nicht hat.
Hugo erscheint mir besonders wegen der Geschwindigkeit relevant.
Schauen Sie sich die realen Daten zu all dem an, worüber wir berichtet haben.
Aber es basiert nicht auf JavaScript-Bibliotheken, was, wie ich bemerkt habe, bedeutend ist. Die Art und Weise, wie man sie verschachtelt und Props weitergibt und so weiter, wird zu einer Art De-facto-Methode der HTML-Verarbeitung.