Im Jahr 2020 entdeckte ich wieder die Freude daran, eine Website mit einfachem HTML, CSS und JavaScript zu erstellen – ohne Transpilierung, ohne Kompilierung, ohne Build-Tools, nur mit meinen Händen auf der Tastatur.
Da meine persönliche Marke sich mit „so spät dran sein, dass das Stadion abgerissen wurde“ zusammenfassen ließe, beschloss ich 2020, einen Podcast zu starten. Es ist der Podcast meiner Agentur Clearleft und er hat den überaus fantasievollen Titel The Clearleft Podcast erhalten. Ich bin sehr zufrieden mit dem Ergebnis der ersten Staffel. Ich bin auch sehr zufrieden mit der Website, die ich dafür erstellt habe.
Die Website ist nicht sehr groß, wird aber mit der Zeit wachsen. Ich habe darüber nachgedacht, wie der Build-Prozess für die Website aussehen sollte, und nach buchstäblich sekundenlanger Debatte entschied ich mich für keinen Build-Prozess. Null. Nada.
Das erwies sich als enorm befreiend. Es fühlte sich sehr praxisnah an, das tatsächliche HTML und CSS zu schreiben, das an die Endbenutzer ausgeliefert wird, ohne jegliche Vermittlung. Ich hatte das Gefühl, meine Hände in den Boden der Website zu stecken.
CSS hat sich in den letzten Jahren so stark weiterentwickelt – mit Funktionen wie calc() und benutzerdefinierten Eigenschaften –, dass man keine Pre-Prozessoren wie Sass mehr verwenden muss. Und Vanilla JavaScript ist leistungsstark, voll funktionsfähig und funktioniert browserübergreifend ohne Kompilierung.
Versteh mich nicht falsch – ich verstehe vollkommen, warum komplizierte Pipelines für komplizierte Websites notwendig sind. Wenn Sie Teil eines großen Teams sind, müssen Sie wahrscheinlich Prozesse einrichten, damit jeder auf konsistente Weise zum Codebase beitragen kann. Je komplexer dieser Codebase ist, desto mehr Technologie benötigen Sie, um Ihre Arbeit zu automatisieren und Fehler zu erkennen, bevor sie online gehen.
Aber diese Einrichtung ist nicht für jede Website geeignet. Und all diese Werkzeuge und Prozesse, die Zeit sparen sollen, verschwenden manchmal doch Zeit weiter unten auf dem Weg. Haben Sie jemals ein Projekt nach, sagen wir, sechs oder zwölf Monaten wieder aufgreifen müssen? Vielleicht möchten Sie nur eine kleine Änderung am CSS vornehmen. Aber Sie können es nicht, weil eine Abhängigkeit defekt ist. Also versuchen Sie, sie zu aktualisieren. Aber sie hängt von einer anderen Version von Node ab. Bevor Sie es merken, sind Sie wie Bryan Cranston, der eine Glühbirne wechselt. Sie sollten eine Zeile CSS bearbeiten, stattdessen kämpfen Sie gegen die Entropie.
Wenn ich ein Problem in der Frontend-Entwicklung angehe, wende ich gerne das Prinzip der geringsten Leistung an: Wählen Sie die am wenigsten leistungsfähige Sprache, die für einen bestimmten Zweck geeignet ist. Ein klassisches Beispiel wäre die Verwendung eines einfachen HTML-Button-Elements anstelle des Versuchs, die gesamte native Funktionalität eines Buttons mit einem Div und viel ARIA und JavaScript nachzubilden. Dieses Jahr habe ich erkannt, dass dasselbe Prinzip auch für Build-Tools gilt.
Anstatt standardmäßig auf die All-Singing-All-Dancing-Toolchain zurückzugreifen, werde ich mit einer langweiligen Basislinie beginnen. Wenn und wenn das zu schmerzhaft oder unhandlich wird, werde ich einen Task-Manager einsetzen. Aber jedes Mal, wenn ich eine Abhängigkeit hinzufüge, werde ich die Lebensdauer des Projekts verkürzen.
Mein Neujahrsvorsatz für 2021 ist, eine Diät zu machen. Keine schweren node_modules-Ordner mehr; nur knuspriges und leckeres HTML, CSS und JavaScript.
Amen.
Ein Problem ist, dass so viele coole Dinge (wie Bibliotheken, Komponenten usw.) heutzutage all diese Galaxien von Abhängigkeiten nutzen und daher mit sich schleppen, über die man sich vielleicht zumindest informieren und ein wenig verstehen muss. Zum Beispiel: ‚Oh, das ist eine schöne, kleine, leichte Start-Codebasis für meine Website! Ich denke, ich möchte sie benutzen. Mann… das ist SASS… Alles, was ich wollte, war CSS…‘
Es muss nicht alles oder nichts sein. Kürzlich habe ich eine kleine PWA-App in lit-element erstellt. Sehr dünne Schicht, die auf Webkomponenten fokussiert ist. Interpolation ähnlich wie bei React. Keine Laufzeitabhängigkeiten, aber eine gute Entwicklungserfahrung.
Die meisten Bibliotheken und Komponenten sind über CDN verfügbar, sodass npm immer noch vermieden werden kann.
Ich fühle das Gleiche!
Nichtsdestotrotz – ich habe meine Freude am Frontend-Coding wiedergefunden, als ich Svelte entdeckte.
Hugo klingt nach der Lösung. Ein einzelnes Binärprogramm bietet genügend Leistung, um ganze Tech-Stacks und Server zu ersetzen.
HTML+CSS+JS mit Markdown oder HTML als Quellcode für Inhalte. Meine persönliche Anpassung daran ist die Verwendung von TailwindCSS und AlpineJS für Stil und JS-Güte. Außerdem habe ich heute Morgen die Bryan Cranston-Szene erwähnt, etwa 2 Stunden bevor ich Ihren Artikel sah, jemand hört zu.
Als Neuling im Spiel wollte ich mich oft an die Standardwerkzeuge halten.
Hauptsächlich aus Angst und mangelndem Verständnis. Aber jetzt, da ich mit Build-Tools, Modulen und – nicht verurteilen – Bootstrap und dergleichen herumgespielt habe, habe ich eine neue Liebe für die einfachen Ergänzungen gefunden.
Ich habe noch nicht genug Erfahrung mit dem ‚alten Code, alte Projekte: kaputte Abhängigkeiten‘, aber ich weiß, dass das noch kommen wird.
Wegen meiner Liebe zu Standarddingen benutze ich manchmal einfach Standard-HTML, JS und CSS, aber die funkelnden Augen von Abhängigkeiten wie SelectJS, das grinsende Gesicht von Vue und die Verlockung von Svelte und Tools wie Tailwind… sie sind einfach unwiderstehlich.
Ich habe den Artikel genossen
Ich habe wirklich versucht, mich in Svelte einzuarbeiten, aber dann habe ich das Gefühl, dass ich in der Nischenhölle landen werde, und wähle etwas anderes. Ich fange an, Angst zu bekommen, als ich merkte, wie schwer es war, TypeScript einzurichten, weil ich statische Typisierung möchte. Etc.
CSS und Vanilla JavaScript können Ihnen bei Ein-Personen-Projekten so viel bieten, das ist wunderbar. Weiter in die buildstep-freie Zukunft! . . . Außer vielleicht, dass die Verlockung von Svelte mich noch eine Weile Node-Module installieren lässt
Amen.
Noch eine Sache: Lange Abhängigkeitsketten zu vermeiden ist nicht nur gut, um der Abhängigkeitshölle zu entkommen, sondern auch ein Segen für Benutzer mit langsamen Verbindungen. Bei langsamem WLAN laden viele Seiten mit „modernen“ Build-Pipelines über 10 Sekunden.
Wenn Sie aufgeblähte Seiten hassen, werden Sie diese Seite wahrscheinlich mögen: https://idlewords.com/talks/website_obesity.htm
Ich habe noch nie von diesem „Prinzip der geringsten Leistung“ gehört, aber das resoniert bei mir mit dem einzigen Ansatz, der für jedes Webstück, das Sie zu erstellen versuchen, funktioniert – der „progressiven Verbesserung“. Schade, dass sich die Webentwicklung schnell zu einer Suche nach dem komplexesten Workflow entwickelt hat, anstatt sich auf ihren ursprünglichen Zweck der Kommunikation zu konzentrieren.
Ja. Eine Milliarde Mal: Ja, bitte. Die sogenannte moderne Webentwicklung hat meinen Job absolut ruiniert. Mir wurde so viel vom Industriekonsens aufgezwungen, aber viele dieser Werkzeuge habe ich bereitwillig übernommen, weil ich anfangs fand, dass die Funktionen es wert waren. Ein paar Jahre später erkannte ich, dass ich keine Benutzererlebnisse mehr schuf. Ich kämpfte nur noch mit Werkzeugen und Abhängigkeitsintegrationen. Ich würde fast alles geben, um zurückzukehren.
Ich fühle das so sehr im Moment. Ich kämpfe seit Wochen mit einer neuen Frontend-Methodik, um das alte Angularjs abzulösen, das ich verwende. All das React, Vue, TypeScript, Kompilieren, Transpilieren, Debuggen von Code, den ich nicht wirklich geschrieben habe, macht mich so frustriert. Zurück zu den Grundlagen mit reinem HTML, CSS und winzigen JS-Bibliotheken, die ich direkt über CDN verlinken kann, um ein paar schicke Sachen zu machen, scheint das zu sein, wonach ich gesucht habe.
Klingt wie der Himmel.
Ich bin ein Frontend-Webentwickler.
Da das Endergebnis unserer Arbeit HTML, CSS und JavaScript ist, was zum Teufel mache ich da mit Docker und Azure?!
Es fühlt sich gut an, das zu hören
Wie pflegt man Elemente wie Navigationsleisten? Damit Sie diese nicht für jede Seite einzeln manuell ändern müssen?
Danke.
Jetzt kann ich der Menschheit vertrauen.
https://john-doe.neocities.org/
Das ist großartig für eine Einzelseiten-Website. Sobald Sie zwei Seiten haben, wiederholen Sie sich und müssen Änderungen an mehreren Dateien für dieselbe Aktualisierung vornehmen. Für die meisten Websites ist ein Prozess zur Handhabung von Teilvorlagen erforderlich.
Jeremy kann mich korrigieren, wenn ich falsch liege, aber ich glaube nicht, dass der Artikel gegen die Idee von Teilvorlagen ist.
Für meine eigenen Bedürfnisse wäre die Regel des geringsten Widerstands die Verwendung von PHP auf einem absolut grundlegenden LAMP-Stack.
Ein paar PHP-Includes und ich bin fertig – keine Kompilierung erforderlich und immer noch kein Build-Prozess.
Und dasselbe gilt für serverseitige Skripte.
Ich frage mich, ob dies wirklich die Erfahrung ist, die die Leute heutzutage machen? Sicher, ich wurde schon mehr als einmal verbrannt, als ich annahm, dass ein Projekt von vor ein paar Jahren einfach zu aktualisieren wäre, aber jetzt mit praktisch null oder sehr wenig Konfiguration für webpack/rollup, ist das wirklich immer noch ein Problem?
Das passiert definitiv immer noch.
Musste das Entwicklerteam daran erinnern,
npm updatenicht auszuführen und nurnpm installbei Pulls auszuführen.Einige zufällige Bibliotheksänderungen und Sie jagen sie einen halben Tag lang.
Manchmal frage ich mich wirklich, was mit moderner Frontend-Entwicklung passiert, wenn ich einen 100 MB großen
node_modules-Ordner sehe…@Jeremy Keith genau
Endlich habe ich hier draußen ein paar weitere Dinosaurier gefunden. Wir haben ein Team von 8 Leuten, die ständig mit neuen und besseren Ideen und Bibliotheken aufwarten. Am Anfang ist alles Spaß, aber nach einer Weile töten all die Abhängigkeiten und Updates meine Freude an der Arbeit. Diese Werkzeuge neigen manchmal dazu, mehr Zeit zu kosten, als sie mir sparen. Ich bin froh, wenn ein kleines Projekt gelegentlich mit gutem altem HTML, CSS, JS (und etwas PHP) gemacht werden kann.
So wahr!
Ich stimme vollkommen zu!
Ich habe mir während der Covid-Quarantäne sogar die Zeit genommen, 2 Open-Source-Projekte zu schreiben, die nur auf Proxys basieren und somit den JS-Code komplett vanilla lassen.
Die Dokumentation ist noch in Arbeit, aber Sie können sie bereits verwenden, z. B. für Two-Way-Binding, ohne den nativen Code Ihres aktuellen Projekts zu ändern.
In Zukunft sind Sie nicht an meine Bibliotheken gebunden und können diese jederzeit fallen lassen, ohne Ihren Code zu beschädigen.
https://www.noaml.in/projects
Nur meine Worte, KISS, nichts weiter. Danke für diesen Beitrag!
Absolut in Ordnung für eine einfache, nicht interaktive Einzelseiten-Website. Fügen Sie dynamische Formulare, nicht triviale UI hinzu und Sie haben ein Problem :)
Absolut einverstanden! Ich habe dieses Jahr viele „Vanilla“-Projekte gemacht – und eines, das mir bei all denen aufgefallen ist: Sie erreichen alle „100 %“ Leistung in Lighthouse – einfach weil es keinen großen Overhead an ungenutztem CSS und JS gibt.
Oh ja, Webentwickler entdecken, dass sie immer noch leistungsstarke Webs erstellen können, ohne 50 verschiedene Technologien zu verwenden und alle Systemressourcen zu verbrauchen
Das würde auch kein ESLint, Prettier und Stylelint bedeuten.
Benutzen Sie einfach Dreamweaver und fertig.
Laden Sie Ihre Abhängigkeiten selbst herunter und fügen Sie die Versionen offline in Ihre Projektdateien ein, damit Sie nicht ständig aktualisieren müssen.
Das Hinzufügen einer Abhängigkeit verkürzt nicht die Lebensdauer einer Website! Es begrenzt nur die Lebensdauer Ihres Gefallens an der Verwendung dieser Bibliothek in Ihrem Projekt, aber dasselbe gilt für Ihren handgeschriebenen Code, den Sie möglicherweise nicht mögen, wenn Sie ihn verlassen und nach einer Weile wieder darauf zurückkommen und sich fragen: „Warum habe ich ihn so geschrieben?!“
Nachdem eine bestimmte Version einer Bibliothek hinzugefügt wurde, kann sie für immer so bleiben, genau wie der von Ihnen handgeschriebene Code, dank stabiler Web-APIs.
Sie können sogar node_modules in das Repository committen, wenn Sie befürchten, dass eine Abhängigkeit verschwinden könnte.
Ich kann zustimmen, aber an diesem Punkt möchte ich fragen: Was ist, wenn ich Dinge wie CSS-Präfixierung, Minifizierung usw. tun muss?
Ich kann der aufgeblähten Natur eines Bundlers zustimmen, aber wenn ich eine externe Bibliothek benötige, muss ich das CDN (wodurch Cache-Vorteile verloren gehen) einfügen oder die Sachen manuell herunterladen, was möglich, aber mühsam ist.
Und bitte, erzählen Sie mir nicht, wie toll CSS ist: CSS ist ohne etwas wie SASS absolut nicht wartbar, es sei denn, Sie machen etwas sehr KISS (und viele Designer machen keine KISS-Layouts :P).
Vielleicht ist Snowpack der richtige Weg, aber ich denke immer noch, dass wir eine Art Tooling brauchen. Vielleicht ein einfacheres, aber ein Tool.
Ich kann das Konzept verstehen, dass es Situationen gibt, in denen Sie Ihr Leben über npm verwalten müssen. Nichtsdestotrotz, jedes Mal, wenn ich darauf stoße, finde ich mich laut fluchend mit meinen Freunden, weil Dinge, die trivial sein sollten, so kompliziert sein wollen. Ich hasse es einfach. Vielleicht bin ich noch nie in eine dieser Situationen geraten, oder vielleicht mag ich Ihre abschließende Aussage, Chris, so sehr, dass ich sie nicht erleben möchte. Jemals.
Junge Leute wissen, wie man „benutzt“, aber viele von ihnen wissen bereits nicht, wie man „macht“. In den nächsten Jahrzehnten, was meiner Lebensspanne entspricht, wird das meiner Meinung nach ein schönes Problem sein…
Ich habe eine Single-Page-Webanwendung mit jQuery und Vanilla JS/CSS erstellt, aber ich hätte sie auch komplett in Vanilla schreiben können. Daher habe ich mich immer gefragt, warum alle so begeistert von Frameworks/Bibliotheken waren. Ich kam zu dem Schluss, dass sie für viele Entwickler einfacher zu bearbeiten sein mögen und Dinge wie Babel helfen, die Unterstützung für ältere Browser sicherzustellen. Aber wenn Sie Ihren Code gut schreiben und keine Unit-Tests benötigen, gibt es keinen Grund, Frameworks/Bibliotheken zu verwenden!
Ich stimme aufrichtig nicht zu. Eine einzelne PWA mit einem großen Haufen jQuery-Kram ist ein Albtraum für Wartung und Debugging.
Sie können nicht sicher sein, dass der von Ihnen geschriebene Code gut geschrieben ist, besonders bei einer eigenwilligen Sprache wie JS. Sie brauchen eine Art Standard.
Ich denke, wir brauchen nur einfachere Werkzeuge, Svelte ist ein schönes Beispiel, auch wenn es weit von perfekt entfernt ist.
Ich arbeite an einem Ansatz mit einfachem HTML, CSS, aber TypeScript. Das Projekt basiert stark auf Webkomponenten, Service Worker und der Annahme, dass Browser HTTP/2 unterstützen (wodurch kein Bündeln mehr erforderlich ist).
Es gibt ein winziges Build-Skript, das tsc, rsync und node aufruft, um TypeScript zu kompilieren, Dateien zu kopieren und zusätzliche Skripte zur Build-Zeit (in TypeScript geschrieben, für die Generierung statischer Inhalte) in das Zielverzeichnis oder nach public/ für GitLab-Seiten auszuführen.
Es gibt immer noch node_modules für TypeScript und @types/node, aber es ermöglicht TypeScript und Skripte zur Build-Zeit.
Ich muss sagen, ich liebe es so sehr. Hauptsächlich, weil es kein Webpack gibt, vielleicht.
Also… das richtige Werkzeug für den Job benutzen. Denken Sie nach, anstatt dieselben Muster zu wiederholen. Im Allgemeinen stimme ich zu, aber manchmal ist eine Verallgemeinerung falsch. Einer der Nachteile von handgeschriebenem Code ist, dass andere Leute Schwierigkeiten haben könnten, diesen Code zu lesen. Wir schreiben schließlich für andere.
Viel Glück beim Minifizieren Ihres CSS oder gar beim Verpassen der Idee von Mixins…
Ich denke, dass es immer noch eine gute Lösung ist, wenn man ein grundlegendes Gulp hat.
Eine andere Sache, über die ich nachgedacht habe, ist: Gulp verurteilt Sie, wenn Sie eine schlechte Struktur haben. Stellen Sie sich vor, Sie arbeiten mit einer anderen Person zusammen, die ein Komma übersehen hat… Sie werden viel Zeit verlieren, um dieses Problem zu identifizieren, und das CSS wird versuchen, wie üblich zu laden.
Ich hoffe, Sie können auch darauf antworten, denn es scheint, als würden Sie nur alleine arbeiten.
Ich könnte nicht mehr zustimmen. Ich liebe, wie effektiv das alte, reine HTML/CSS ist. Es macht die leichtesten Websites. Ich habe meine eigene auf diese Weise gemacht. Und wenn sie größer wird, würde ich eine SSG wählen.
Liebe es. Ich bin voreingenommen zugunsten von Vanilla-Alles – es gibt etwas zutiefst Befriedigendes daran, seine Dinge von Grund auf neu zu schreiben.
Ich versuche, mich über die gängigsten Werkzeuge auf dem Laufenden zu halten, damit ich mit Teams an Projekten zusammenarbeiten kann, aber für meine persönlichen Projekte genieße ich Barebones-CSS, Vanilla JS und ein paar bescheidene Anpassungen, während ich vorgehe.
Ich stimme dem ziemlich zu. Die einzige Möglichkeit, wie ich das Gefühl habe, lernen zu können (was ich seit etwa 20 Jahren nebenberuflich als Amateur tue), ist, meine Hände schmutzig zu machen, indem ich direkt mit dem Code arbeite. Die 2 von mir erstellten Websites sind vielleicht nicht schick, aber sie funktionieren, und das zählt für mich: Darauf kann ich aufbauen.
Hallo Jeremy,
Toller Artikel.
Ich habe kürzlich die gleiche Entscheidung für ein Projekt von mir getroffen. Es gibt jedoch ein Problem: Das Kopieren des Headers und Footers in alle Ihre HTML-Dateien.
Ich habe dies getan, um dieses Problem zu lösen
htmlsync.js
Hier gibt es viel zu entdecken, aber die allgemeine Idee ist, dass es auf Ihren Anwendungsfall ankommt.
CDNs eignen sich hervorragend für das Hosting von Bibliotheken (und wenn ich mich nicht irre, gibt es ein CDN, das alle NPMJS-Bibliotheken hostet), aber es gibt legitime Anwendungsfälle, in denen das Hosten der Pakete auf Ihrem eigenen Server eine weitaus bessere Option ist.
Datenschutz zum Beispiel, der derzeit ein riesiger Trend in der Welt ist. Das Hosten von Bibliotheken auf Ihren eigenen Servern stellt sicher, dass Sie die volle Kontrolle über Zugriff und Protokollierung (oder deren Fehlen) haben. CDNs können die Nutzung pro IP verfolgen und durch schiere Menge die Internetmuster der Benutzer ableiten.
Ich bin seit fast 20 Jahren Teilzeit-Webentwickler und habe damit begonnen, als Vanilla die einzige Wahl war. jQuery war unerlässlich, um die Inkonsistenzen der Browser zu überbrücken. Als Ein-Mann-Betrieb baue ich derzeit die meisten Websites mit WordPress, da es ein so vollständiges Ökosystem ist und Kunden einfache Wartungsarbeiten selbst durchführen können. Leistung kann ein Problem sein, aber wie CSS-Tricks selbst zeigt, gibt es Lösungen. Ich liebte die Website, die ich mit Django für einen Kunden gebaut habe, der eine solide Datenbank brauchte. Es fühlte sich an, als würde sie die beste Kombination aus Kontrolle und Leistung bieten.
Ich habe mit React und Vue experimentiert, aber ihr Wert scheint auf große Gruppenprojekte oder komplexe Projekte, bei denen Vanilla-Code überfordert ist, oder ein Team, das viele Projekte erstellt, bei denen Komponenten leicht wiederverwendet werden können, abzuzielen. Ich finde Svelte spannend und erwarte, dass es in einem Jahr durchstartet, sobald Svelte-Kit solide ist.
Der Jamstack-Ansatz scheint einen guten Mittelweg zu bieten, der Leistung, die Möglichkeit für Kunden, Inhalte über Markup hinzuzufügen oder zu ändern, und eine relative Einfachheit des Build-Prozesses bietet.
Sicherlich, wie #Mike sagte: „Das richtige Werkzeug für den Job“ ist Regel Nr. 1.