Gatsby, Sublime Text und die Frage nach anderen Werkzeugen für statische Seiten

Gatsby ist ein Generator für statische Seiten, der auf React aufsetzt. Und das Tutorial »Setting up and Getting used to Gatsby« ist eine Schritt-für-Schritt-Anleitung, wie man so eine statische Webpräsenz damit hochzieht. Leider wird beim letzten Schritt, dem Deployment, also dem Hochspielen der statischen Seiten auf einen Server, davon ausgegangen, daß man GitHub Pages nutzen will. Bei aller Sympathie für GitHub will ich meine Seiten nicht in diesem Datensilo verbuddeln. Wenn also jemand einen Link hat, wie man mit Gatsby und React eine statische Website hinter einem beliebigen Webserver hochzieht, den bitte ich um Hinweise in meinen Email-Kommentaren.

Das Verstecken des Deployments auf GitHub Pages ist übrigens eine Unart, die man in vielen Tutorials zu statischen Seiten auch bei Jekyll, Hugo oder Blogdown findet.

Nun zu etwas anderem: Meine Überlegungen, meine (statischen) Webseiten nicht mehr mit RubyFrontier herauszuschreiben, sind ja der Tatsache geschuldet, daß die Software im derzeitigen Zustand nur mit TextMate 2 zusammen läuft und somit Mac only ist. Da ich aber nicht weiß, ob ich mir in Zukunft die teuren Apple-Computer noch leisten kann, suche ich nach einem plattformunabhängigen Werkzeug.¹ Und das betrifft auch die Frage des Editors: Mit Atom werde ich einfach nicht warm, vielleicht sollte ich es doch einmal mit Sublime Text versuchen. Das Teil ist zwar proprietär, aber wenigstens plattformunabhängig und läßt sich mit Python-Skripten anpassen. Der Artikel »A Guide to Sublime Text Snippets« macht jedenfalls Lust auf mehr.

War sonst noch was? Ach ja, Dave Winer nutzt immer noch Frontier, um seine Utility-Skripte zu schreiben. Er hat ein paar Beispiele hochgeladen, leider funktioniert (zur Zeit?) der Link nicht. Natürlich braucht man entweder ein Frontier oder den OPML Editor, um diese Beispiele zu nutzen. Warum das hier steht? Weil auch ich Frontier lange Jahre genutzt habe, um meine statischen Seiten herauszuschreiben. Und das Teil war auch sonst so etwas, wie mein Uber Tool. Auch wenn es längst in die Jahre gekommen ist, ich trauere ihm heute immer noch ein wenig nach.

Außerdem denkt Winer darüber nach, eine River 5 Distribution für Linux zu erstellen. Das erinnert mich daran, daß auch ich schon lange einen River of News für dieses statische Blog Kritzelheft schreiben wollte.

Und drittens hat Winer auch noch eine Idee, wie er in Zukunft mit kurzen Textschnipseln und längeren Beiträgen in seinem Blog umgeht. Diese Idee sollte ich auch für den Schockwellenreiter implementieren. So viel zu tun, so wenig Zeit …

Last but not least werde ich mich am Wochenende mit Burks treffen. Wir wollen (nicht nur, aber auch) ein wenig darüber schwadronieren, wie wir uns mit statischen Seiten das Netz zurückerobern und auf Nachhaltigkeit setzen können.

---

6 (Email-) Kommentar

---

»Bei aller Sympathie für GitHub will ich meine Seiten nicht in diesem Datensilo verbuddeln.«
Wieso sprichst Du von GitHub als Datensilo, wenn es sich „nur“ um das hochladen statischen Webseiten handelt?
Unter Datensilo verstehe ich eine Anwendung, die meine Daten in einem proprietären Format abspeichert, so dass ich bei einer späteren, von mir gewünschten Migration, diese Daten nicht ohne weitere in einem Format bekomme, dass ich problemlos weiter verarbeiten kann. Wenn man also z.B. Confluence als Wiki-System einsetzt, hat man viel Spaß wenn man diese Daten z.B. in ein DokuWiki übertragen will.
Bei der Verwendung von statischen Website-Generatoren, wäre ich jetzt aber davon ausgegangen, dass sich Eingabedateien für diese Generatoren, sich immer noch in einem allgemein lesbaren Format bei mir auf der heimischen Platte befinden.

– Heinz Z. (Kommentieren) (#)

---

Als Alternative zu Sublime möchte ich noch CudaText zu nennen. Open Source und Python Plugins sollten genau in deine Richtung gehen. Ich nutze den Editor selbst mit eigenen Plugins für Webentwicklung und Programmierspielereien.

– Tom B. (Kommentieren) (#)

---

Einfach nach dem „Backen“ der Site das Verzeichnis mit html, js und co. („_site“ bei jekyll, „public“ bei Gatsby) auf den Server übertragen (ich mache das mit einem Shellskript das rsync-Befehle enthält), das ist eigentlich alles in Sachen „Deployment“.
Diesen Hang zu Github-Pages kann ich auch nicht nachvollziehen, es ist mit dem Code der ganzen Welt doch schon genug da zentralisiert.

– Ralf G. (Kommentieren) (#)

---

Als langjähriger BBEdit, dann Textmate und anschließend Sublime-Benutzer bin ich mittlerweile mit Visual Studio Code sehr zufrieden. Es ist flott, erweiterbar und man merkt ihm die Praxisnähe an, mit der seine Entwickler zu arbeiten scheinen.

– Bernhard F. (Kommentieren) (#)

---

Und da wäre noch https://beakerbrowser.com/. Aber das wissen Sie ja schon.

– Erwin L. (Kommentieren) (#)

---

https://www.gatsbyjs.org/tutorial/part-one/#deploying-gatsbyjs-websites-on-the-web Das beschreibt, dass man nach dem Build (‚gatsby build‘) das produzierte public-verzeichnis mit den HTML/SSR-Javascript Seiten auf jeden Server hochladen kann, z.B. via rsync oder git. Oder man nutzt static server Anbieter wie surge oder auch now.sh - https://zeit.co/now - bzw. S3-Amazon. Ich kann da keinerlei Einschränkungen für das Deployment erkennen.
Eine flexiblere Alternative mit mehr Programmieraufwand wäre next.js. https://zeit.co/blog/next

– Thomas O. (Kommentieren) (#)

---

(Kommentieren)