- Ein HTML-first-Ansatz sorgte dafür, dass ein Antragsformular für öffentliche Dienste auch ohne JavaScript funktionierte, sodass Nutzer ihren Antrag selbst auf schwachen Geräten, in schlechten Browsern und bei instabilen Netzwerken abschließen konnten
- Die bisherige React-App wurde nach 3 Tagen wegen Kundenbeschwerden wieder abgeschaltet; Probleme waren Loading-Spinner, globaler JavaScript-State, Accessibility-Mängel und ein Bildspeicher-Ansatz, der an das
localStorage-Limit von 5 MB stieß - Die neue Implementierung basierte auf Astro, machte jeden Formularschritt zu einer eigenen Seite und speicherte übermittelte Daten und Uploads in jeder Phase in einer Backend-Session, um Datenverlust bei Eingaben zu verhindern
- Die Formularvalidierung wurde mit einer Web Component umgesetzt, die die eingebaute HTML-Validierung des Browsers umhüllte; bei Fehlschlägen kam eine Struktur mit Progressive Enhancement zum Einsatz, die zur nativen Browser-Validierung und danach zur Validierung durch die Backend-API überging
- Nach dem Launch verdoppelte sich die Zahl der abgeschlossenen Formulare, und es zeigte sich, dass Nutzer, die wegen JavaScript-Fehlern absprangen, in JavaScript-basierten Analysepaketen nicht auftauchen
Problemhintergrund und der gescheiterte frühere Versuch
- Der Kunde war ein Versorgungsunternehmen, und Serviceanträge konnten über ein altes ASP-Formular auf der Website oder über manuelle Abläufe gestellt werden
- Manuelle Abläufe waren für das Unternehmen teurer, und in der regulierten Monopolsituation konnten bei einer Kundenzufriedenheit unter 96 % Strafen in Millionenhöhe in Pfund anfallen
- Zwei frühere Versuche zur Lösung des Problems waren gescheitert; beim jüngsten Versuch hatten Auftragnehmer aus einem anderen Land eine React-App gebaut
- Die React-App wurde 3 Tage nach der öffentlichen Freischaltung wegen Kundenbeschwerden wieder abgeschaltet
- In der App waren Loading-Spinner und globaler JavaScript-State ineinander verwoben, außerdem war sie nicht barrierefrei
- Bild-Uploads waren eine Kernfunktion des Formulars, doch es wurde versucht, Bilder und sämtliche Formulardaten im auf 5 MB begrenzten
localStoragezu speichern
Kriterien für einen HTML-first-Ansatz
- Die neue Website wurde mit Astro gebaut und übernahm eine HTML-first-Struktur
- JavaScript wurde nur innerhalb von Web Components verwendet und diente dazu, eine Website, die auch ohne JavaScript korrekt funktioniert, schrittweise zu verbessern
- Es galt die Vorgabe, dass ein öffentlicher Dienst auf möglichst allen Geräten funktionieren muss
- Es galt die Vorgabe, dass er auch bei schlechter Verbindung funktionieren muss
- Es galt die Vorgabe, dass einmal eingegebene Formulardaten niemals verloren gehen dürfen
- Das Beispiel von Terence Eden zeigt, dass die einfachen HTML-Seiten von GOV.UK es ermöglichten, Informationen zum Wohngeld selbst im langsamen und speicherarmen Browser der PlayStation Portable zu lesen
- Die GOV.UK-Seiten bestanden aus schlichtem, leichtgewichtigem HTML und mussten selbst in miserablen Browsern funktionieren
Formularstruktur und Datenerhalt
- Jede Formularsitzung musste eine eindeutige ID haben
- In allen Schritten des Formular-Wizards mussten übermittelte Daten und hochgeladene Dateien im Backend gespeichert werden
- Das Formular musste auch ohne JavaScript vollständig ausfüllbar sein
- Das Formular musste auch in alten und leistungsschwachen Webbrowsern vollständig ausfüllbar sein
- Die Barrierefreiheit musste die WCAG-Kriterien erfüllen; das Team setzte nicht auf AAA, sondern auf AA als Ziel
- JavaScript und modernes CSS sollten zur Verbesserung des Erlebnisses eingesetzt werden
- In der endgültigen Struktur wurde jeder Schritt des Formular-Wizards zu einer eigenen Seite, und beim Klick auf Weiter wurde das Formular abgeschickt
- Wenn die API die Daten als gültig beurteilte, wurde der Browser zum nächsten Schritt weitergeleitet
- Formularübermittlung und Redirect sind ein altes Webanwendungs-Muster, das dank Remix eine kleine moderne Renaissance erlebt hat
- Bei diesem Dienst handelte es sich nicht um eine App mit Echtzeitdaten, sondern um ein großes Formular; vor dem Rendern 20 MB JavaScript auszuliefern, war daher unpassend
Formularvalidierung und Progressive Enhancement
- Formularvalidierung und das Rendern von Formularfehlern gelten als Bereiche, in denen Teams wegen React-Validierungsbibliotheken oft viele Entwickler-Monate investieren
- Browser bringen bereits ein Validierungssystem mit, das sich mit weniger Aufwand nutzen lässt als minderwertige Nachbauten, die separat als Bibliothek gepflegt werden müssen
- Die umgesetzte HTML Web Component war ein einfaches Custom Element, das vorhandenes HTML umhüllte
- Diese Web Component nutzte kein Shadow DOM und renderte in JavaScript kaum HTML
- Die Komponente umhüllte ein HTML-Formular, übernahm die HTML-Validierung und stellte sie in moderner Form dar
- Die HTML-Validierungs-Popup-Tooltips wurden unterdrückt, und Fehler wurden in einem mit dem Feld verbundenen
aria-describedby-Element platziert - Inzwischen wird die Verwendung von
aria-errormessageempfohlen - Sobald während der Eingabe ein gültiger Zustand erreicht wurde, wurde die Validierung gelöscht und bei
blursowie beim Absenden erneut ausgewertet - Dieses Nutzererlebnis wurde mit weniger als 1 KB ausgeliefert und fiel bei Fehlern auf die eingebaute Browser-Validierung zurück
- Wenn auch die eingebaute Browser-Validierung scheiterte, übernahm die Backend-API die Validierung
- Validierungsprobleme wurden dem Nutzer zum frühestmöglichen Zeitpunkt gemeldet, den sein Browser zuließ, und selbst bei Fehlern gab es immer einen akzeptablen Fallback
- Später wurde für die allgemeine Nutzung eine neue Version der Web Component von Grund auf neu geschrieben; ihr Name ist validation-enhancer
- Das Nutzungsbeispiel zeigt eine Struktur, in der
validation-enhancerein HTML-Formular umhüllt undinput type="email",requiredundaria-errormessageunverändert nutzt
Email
Submit
Ergebnisse nach dem Launch und Fazit
- Nach dem Launch verdoppelte sich die Zahl der Menschen, die das Formular abschlossen
- Die für die Analyse zuständigen Personen wussten nicht, woher diese Nutzer kamen
- JavaScript-basierte Analysepakete sehen keine Nutzer, die wegen JavaScript-Fehlern abspringen
- Der Ansatz, Backend-Sessions aufrechtzuerhalten und Nutzerdaten niemals zu verlieren, erwies sich als wirksam
- In einem Fall schloss ein Nutzer das Formular einen Monat nach dem Start ab
- Nach Ende des Auftrags reagierte der Nachfolger mit der Aussage, dass eine Struktur, die auch ohne JavaScript immer funktioniert, dem Team mehr Arbeit mache
- Nutzer alter Browser, Nutzer mit schlechter Netzwerkverbindung und Nutzer von Assistenztechnologien auszuschließen, ist bei einem monopolartigen öffentlichen Dienst nicht akzeptabel
- Der Drang, die rauen und unausgereiften Praktiken aus der Expansionsphase der Softwareindustrie weiter voranzutreiben, sollte abgelegt werden
- Wenn man eine Webanwendung baut, die selbst auf einer PlayStation Portable und mit 3G-Verbindung funktioniert, dann funktioniert sie für alle Nutzer und möglicherweise auch noch in 30 Jahren
2 Kommentare
Hacker-News-Kommentare
Als Nicht-Webentwickler frage ich mich, warum dieser Ansatz mehr Arbeit machen soll
Der im Artikel beschriebene Ansatz wirkt ziemlich einfach: Standardkomponenten für Formulare bauen und darunter einen Submit-Button platzieren. Ich habe das vor langer Zeit auch so gemacht, als ich meine persönliche Website gebaut habe, und es war nicht besonders schwer. Vielleicht kenne ich mich auf dem Gebiet nicht gut genug aus, aber eine aufwendige Frontend-Oberfläche zu bauen wirkt deutlich schwieriger
Nicht weil sie dumm wären. Wenn man direkt fragt: „Kann man eine Website ohne React bauen?“, würden sie natürlich mit „Ja“ antworten. Aber wenn sie eine neue Website bauen sollen, starten sie aus Gewohnheit und weil sie die Arbeit einfach erledigen wollen, gedankenlos ein neues React-Projekt
Einige kennen tatsächlich keine andere Methode. Sie wissen nicht, wie man einen normalen HTTP-Server aufsetzt, der pures HTML ausliefert, und haben keine Erfahrung damit, Formulare zu bauen, die ohne JavaScript validiert und abgeschickt werden. Solche Leute schreiben keine Beiträge auf HN und beteiligen sich auch nicht an Online-Diskussionen über neue Tools und Techniken oder über alte Tools und Techniken. Sie haben in einem Bootcamp oder in einem einzigen Web-App-Kurs an der Uni gerade genug gelernt, um einen Job zu bekommen, und seitdem immer nur die konkreten Werkzeuge gelernt, die der Arbeitgeber verlangt oder die jemand im Team ausgewählt hat
Aus der Perspektive eines Älteren hat es bei mir eine Weile gedauert, das zu bemerken, aber inzwischen verstehe ich es. Je nach Karriereweg begegnen manche Menschen den einfachsten Grundlagen von HTML, CSS und reinem JavaScript erst später als den komplexen, frameworkspezifischen Teilen dieser Technologien. Deshalb wirkt es auf sie nicht weniger professionell, sondern eher noch kryptischer, fortgeschrittener oder wie nebensächliches Wissen
Auch die Aussage „Das macht für uns viel mehr Arbeit“ muss nicht absichtlich falsch sein. Wenn man eine Aufgabe mit Werkzeugen erledigt, mit denen man nicht vertraut ist, kann es sich tatsächlich nach viel mehr Arbeit anfühlen, selbst wenn diese Werkzeuge weniger komplex sind
Die App war schnell und einfach, aber es gab einen Preis. Unsere Möglichkeiten waren eingeschränkt, UI-Elemente mit reichhaltiger Funktionalität einfach als npm-Pakete einzubinden, und um eine gute User Experience zu liefern, war deutlich mehr Arbeit nötig. Alles dauerte länger, und am Ende war die User Experience auch schlechter. Man gibt sich Mühe, aber manchmal reicht die Zeit trotzdem nicht, um bis zum Schluss alles sauber umzusetzen
Das Unternehmen ist gescheitert, und ich glaube nicht, dass React es gerettet hätte. Aber ich kann aus eigener Erfahrung sagen, dass eine moralische Besessenheit von „Einfachheit“ auch nicht geholfen hat. Es ist immer ein Trade-off
Jemand sagt, er habe eine einfachere und vernünftigere Lösung geliefert als die, auf die die meisten gekommen wären, aber die Person, die das Projekt übernommen hat, war nicht zufrieden
Wissen wir, ob die Qualität des übergebenen Codes hoch war? Hat diese Person einfach nur darauf reagiert, dass es „nicht React“ war? Gab es im Unternehmen vielleicht eine vorgegebene Template-Struktur dafür, wie Apps gebaut werden sollen?
Wissen wir nicht
Ich habe eine Weile nichts mehr darüber gehört, aber der Vorschlag HTML Triptych ist immer noch etwas, von dem ich hoffe, dass es irgendwann in Browsern landet. Die Art, wie HTML-Formulare mit REST-Endpunkten sprechen, ist ein gutes Muster
Unterstützende Validierung für Nutzer erledigt man über Input-Attribute, die eigentliche Validierung passiert auf der anderen Seite der Anfrage, und der Ablauf ist dann GET /form => POST /thing => GET /thing/1. Wenn die Triptych-Funktionen umgesetzt werden, wäre das ein hervorragendes Muster
[0] https://triptychproject.org/
Ich mag React-Websites überhaupt nicht, aber was ich nicht verstehe: Nutzen solche Websites Lazy Loading denn gar nicht?
Selbst große Single-Page-Apps sind sehr schnell, wenn Komponenten nur bei Bedarf geladen werden
Ich bin von Angular1 über Vue2 zu Svelte2 gewechselt und schließlich bei reinen Web Components ohne Shadow DOM gelandet, und damit zu arbeiten macht Spaß und ist schnell
Die meisten Apps baue ich heutzutage einfach mit HTMX + Go + SQLite.
Für die meisten Projekte fühlt sich das als völlig ausreichend an.
Eine meiner Seiten ist sehr bildlastig und verarbeitet 10 TB Traffic pro Monat. In diesem Fall sieht das Setup so aus: 1. Ich nutze S3, weil ich einen zuverlässigen Datenspeicher brauche 2. Davor steht Cloudflare mit aktiviertem Tiered Cache. Dadurch holen die POPs Inhalte bevorzugt von Cloudflare statt vom Origin. Ich cache alles sowohl im Browser als auch bei Cloudflare für ein Jahr, habe Regeln gesetzt, die die Origin-Cache-Policy und Query-Strings ignorieren, und verwende nur unveränderliche Objekte, die versioniert werden müssen 3. Davor steht BunnyCDN.
Cloudflare allein erlaubt einem nicht, eine bildlastige Website auf diese Weise zu betreiben, daher senkt dieser Ansatz die Kosten erheblich. Laut Richtlinie sollte man es hauptsächlich nicht für Bilder verwenden, sondern für HTML, CSS, JavaScript und andere Website-Inhalte.
Nur mit S3 würden die Kosten explodieren.
In letzter Zeit entwickle ich allerdings mobile Apps. PWA hat Grenzen. Das Betriebssystem kann den IndexedDB-Speicher zurückfordern, daher kann man innerhalb der App ohne Registrierung oder Backend-Eingriff keinen zuverlässigen Datenspeicher bereitstellen.
Am Ende blieb mir unter Android nichts anderes übrig, als zu Flutter zu wechseln, aber das brachte andere Schmerzen mit sich. Es ist frustrierend, wenn App-Updates lange auf „In Prüfung“ stehen. Die Web-App derselben Anwendung ist im Vergleich extrem schnell aktualisiert.
Ich frage mich, warum es kein mobiles Betriebssystem gibt, mit dem man Apps in JavaScript, HTML und CSS bauen kann und das ohne großen Aufwand auch noch stabilen Speicher bietet. Dass sich PWA-Apps schnell aktualisieren lassen, ist ein echter Vorteil.
Die Zeitreise ist der einfache Teil; danach muss man irgendwie den Niedergang von Palm und das Vergessen von webOS als Smartphone-Betriebssystem verhindern.
Wenn 2009 zu weit weg ist, kann man sein Glück auch mit Firefox OS im Jahr 2012 versuchen.
Spaß beiseite: Menschen und Unternehmen haben es tatsächlich versucht. Aber schlechtes Timing und verschiedene Ereignisse kamen zusammen, sodass diese Realität in unserer Zeitlinie nie eingetreten ist.
Es fühlt sich genau wie der Sweet Spot an: kein unnötiger Ballast wie in C, aber es geht einem wie Java aus dem Weg, sodass man sich auf die Business-Logik konzentrieren kann. Anders als Rust.
Es ist nicht für alles gut. Gerade die schwachen Möglichkeiten zur Abstraktionsbildung sind schade. Aber für Server-Apps mit viel Business-Logik ist es hervorragend. Es wirkt nicht wie eine Sprache, die alles sein will, sondern wie eine, die auf diesen Bereich spezialisiert ist.
Ich habe auch ein paar Bibliotheken gebaut, um SQL- und HTMX/Web/OAuth-Teile zu abstrahieren. Inzwischen sind meine Apps einander sehr ähnlich, sodass sich Features leicht hin- und herkopieren lassen.
https://github.com/cattlecloud/webtools
https://github.com/cattlecloud/litesql
Als Gegenposition gibt es In Defence of the Single Page Application.
https://williamkennedy.ninja/javascript/2022/05/03/in-defenc...
In Defence of the Single Page Application - https://news.ycombinator.com/item?id=31275178 - Mai 2022, 32 Kommentare
Dieser Beitrag ist gut und ein hervorragendes Beispiel dafür, ein Problem zu nehmen und es mit der passenden Technik in der passenden Tiefe zu lösen. Es hilft enorm, wenn man das Domänenwissen des Kunden wirklich vollständig hat.
Allerdings gefällt mir das Framing „einfaches HTML ist besser als React“ nicht. Man könnte dieselbe Geschichte nämlich genauso gut als React-Entwickler erzählen.
Man könnte endlos über viele Themen sprechen, die der Artikel nur oberflächlich streift, etwa die Komplexität und Feinheiten serverbasierter Session-Speicherung gegenüber browserbasierter Speicherung, aber das würde zu lang werden.
Was in HTML einfach ist, ist auch in React einfach.
Es ist buchstäblich derselbe Code. Nichts hindert einen daran, in React browserbasierte native HTML-Validierung zu verwenden. Der Code, der in React komplex wird, etwa übermäßig komplizierte Validierungslogik, wird auch in Astro komplex. Astro hat seine eigene Herangehensweise an Schema-Validierung und Ähnliches, und wenn man das in eine Astro-Seite integrieren will, muss man dort ebenfalls Client-Router und Ähnliches einbinden, wodurch es auch dort sehr leicht übermäßig komplex wird.
Das Vergleichsbeispiel ist vermutlich auch ein ausgelagertes Auslands-Team mit unvollständigem Wissen, das durch die Projektstruktur dazu angereizt ist, so schnell wie möglich, in so wenig Zeit wie möglich und mit möglichst viel Komplexität eine Lösung zu bauen.
Der letzte Punkt ist subtil. Das heißt nicht, dass die Agentur das absichtlich tut, aber durch die Anreizstruktur lohnt sich übermäßige Komplexität für sie tatsächlich, daher gibt es keinen direkten Anreiz, einen einfachen Weg zu wählen.
Wie auch immer: Eine einfache Lösung, die das konkrete Problem direkt angeht, ist immer besser, egal für welchen Stack man sich entscheidet.
Ich habe nichts gegen Formularvalidierung in Astro; ich wollte nur betonen, dass es mehr gibt als bloß „native HTML-Browser-Validierung“.
Toller Artikel, aber jedes Mal, wenn ich solche inspirierenden Texte lese, bin ich hin- und hergerissen. Die Aussage stimmt völlig, und mir gefällt die Idee einer einfachen Website, die gut funktioniert, schnell lädt und nicht von modernen Browsern abhängt.
Dann frage ich mich aber, ob das vielleicht nur daran liegt, dass ich nicht schlau genug bin, um React oder die jeweils angesagten schicken Technologien zu verstehen.
Es fühlt sich an, als gäbe es eine Grenze meines Verständnisses, die ich nicht überschreiten kann. Wenn man mir einen einfachen Editor wie Sublime gibt und sagt, ich soll eine Webseite bauen, ist das selbst mit JavaScript ein glücklicher Ort für mich. Gibt man mir VSCode oder Zed, irgendwelche Claude/Copilot/ChatGPT-Plugins überall und React-Tutorials, wird mein Gehirn zu Brei.
Es ist nichts Schlechtes, Dinge einfach zu halten; oft muss man eher klug genug sein, um sie nicht unnötig zu verkomplizieren.
Embrace Extend Extinguish ist real, und die Leute, die da mitmachen, haben es verdient, durch LLMs ersetzt zu werden, die schneller lügen und noch schneller Müllcode ausspucken.
Das erinnert mich an fast 15 Jahre zurück. Ich habe in Grails Backend-Session-Management verwendet und HTML-Formulare mit responsive CSS und „ein bisschen“ JS verbessert.
Der Unterschied zu damals ist, dass die Browsertechnologie noch nicht so weit war wie heute. Man musste viele Browser berücksichtigen, es war schwierig, weil man mit IE7 und sogar IE6 umgehen musste, und man brauchte umfassendes QA. BrowserStack kam erst später.
Es gibt einen Grund, warum sich JavaScript-Bibliotheken weiterentwickelt haben. Es gab kein npm, nicht einmal bower. Dann kam Backbone.js und ich mochte es. AngularJS war beeindruckend, die nächste Angular-Version brachte einen massiven Kompatibilitätsbruch, und danach kamen React, Polymer und andere.
Heutige native Browser können sehr viel und Progressive Enhancement ist einfach. Aber das war nicht immer so. Die Entscheidung, damals React einzusetzen, war aus vielen Gründen vertretbar, und das könnte auch hier gegolten haben.
Vor mehr als 10 Jahren habe ich bei GOV.UK für das Justizministerium solche Apps gebaut. Wir haben unsere eigene Formular-Wizard-Bibliothek entwickelt, um lange Formulare schrittweise zu validieren und auf mehrere Seiten aufzuteilen, weil Ruby on Rails das nicht von Haus aus unterstützte.
Damals war der Grundsatz sehr wichtig, dass alle Menschen digitale Dienste nutzen können sollten, unabhängig davon, mit welcher Umgebung sie darauf zugreifen.
Für jede Session-ID kann man die Seiten einer mehrseitigen Anwendung dieser Session-ID zuordnen, sodass der Nutzer sie bei Bedarf sogar selbst eingeben könnte. Eigentlich sollte man es aber anhand ausreichender Informationen wie IP-Adresse, Upload-Datum, Browser und Betriebssystem erkennen können. Die genaueste Session muss jedoch im Browser liegen, damit die Cookies eines einzelnen Antrags nicht mit denen anderer Antragsteller vermischt werden, etwa eines Verwandten mit einer PlayStation Portable.
Ich frage mich, welche Technologie sie in mobilen Apps verwenden. Ich vermute, es sind keine vollständigen nativen Apps, sondern eher Webviews.
Das hier ist nicht: „Wir haben eine React-App in HTML-Formulare umgebaut und dadurch die Performance verbessert.“ Es ist: „Wir haben eine schlechte Webseite in eine gute Webseite verwandelt und dadurch die Performance verbessert.“
Es ist töricht, das der Technologie zuzuschreiben, die das Browser-Erlebnis antreibt. Man kann mit React eine hervorragende User Experience schaffen, und man kann mit reinem HTML eine grauenhafte Website bauen.
Die Verbesserung kam aus einer Änderung des Designs, nicht aus der Technologie.
Aber ja, das stimmt. Die nutzerseitige Veränderung kam daher, dass das Design korrigiert wurde, nicht durch die verwendete Technik.
Das erinnert stark an schlechte Bullet Points im Lebenslauf. Jemand schreibt dann etwa: „Website mit HTML-first neu geschrieben, Besucherzahl um 100 % gesteigert“, als wäre der geschäftliche Erfolg auf die Codeänderung zurückzuführen. Fragt man nach, stellt sich heraus, dass die gesamte Seite neu gestaltet wurde, um Designprobleme zu beheben oder Funktionen hinzuzufügen, und dass der Besucherzuwachs dadurch ausgelöst wurde.
Douglas Crockfords JavaScript: The Good Parts ist lächerlich kurz. React: The Good Parts wäre noch kürzer.
Interessanterweise beschreibt der Originaltext einen mehrseitigen Wizard-Formularstil, den ich in den letzten etwa 10 Jahren fast gar nicht mehr gesehen habe. Und wenn ich so etwas doch gesehen habe, dann war es meistens ein schreckliches Enterprise-System. Das Letzte, an das ich mich erinnere, war so etwas wie ein Oracle-Produkt für Spesenabrechnungen.
Das Problem bei solchen Dingen ist immer, dass sie während der eigentlichen Arbeit langsam sind. Auf jeden Button wartet man mehrere Sekunden. Wenn man dann ein oder zwei Schritte zurück muss, ist es doppelt so nervig. Schlecht gebaute Single-Page-Apps sind dagegen oft am Anfang langsam. Das Laden dauert, aber wenn sie einmal geladen sind, ist die Performance normalerweise in Ordnung.
Lobste.rs-Kommentare
Etwas zu bauen, das für Menschen richtig funktioniert, ist natürlich mehr Arbeit. Aber genau das ist letztlich der Kern der ganzen Arbeit
Es wirkt eher so, als hätten die Nachfolger eigentlich sagen wollen, dass sie die Grundlagen der Webplattform nicht besonders gut kennen
Das soll nicht heißen, dass das wünschenswert ist, sondern nur, dass die Realität im Moment so aussieht
Der Abschnitt, in dem stand, dass es Zeit gekostet hat, Kollegen „Formular absenden und weiterleiten“ zu erklären, ist unerquicklich. Alle haben sich zu sehr an client-zentrierte Web-Apps gewöhnt
Die Webentwicklung ist gerade wirklich in einem traurigen Zustand, und es gibt vieles, das neu vermittelt werden muss
Ich glaube nicht, dass man ein so hohes Maß an Kompatibilität braucht, um diesen Ansatz zu rechtfertigen. Wie im Artikel gesagt wird: Es ist einfach nur ein Formular
Deshalb würde ich es wohl in jedem Fall so bauen
Ich würde gern einmal versuchen, eine Site zu bauen, wie sie im Artikel beschrieben wird. Die Einschränkung eines sehr kleinen Downloads, der in fast allen Browsern laufen und zugleich barrierefrei sein muss, klingt nach einer ziemlich interessanten Herausforderung
Ich frage mich, ob es Firmen gibt, die sich darauf spezialisieren, und ob sie einstellen. Vielleicht bin ich auch nur eine ältere Person, die die einfachere Art von früher vermisst
Die Funktion ist gut genug isoliert, dass sie sich sehr leicht als wiederverwendbare Bibliothek herausziehen ließe, und es gibt noch viel zu tun. So etwas möchte man direkt als Standard in Web-Frameworks haben. Wirklich ein guter Artikel
Etwas ironischerweise musste ich in Firefox in den Lesemodus wechseln, weil wegen eines bestimmten Stils der eigentliche Text weder vollständig sichtbar noch auswählbar war. Der Titel, die rosa Anführungsmarkierungen und Code-Blöcke waren sichtbar, der Rest aber nicht
Bearbeitung: Nach dem, was ich weiter unten sehe, liegt es vermutlich an meiner Umgebung. Ich lasse es für den Kontext stehen
Den Artikel selbst konnte ich gut lesen. Ob Entwickler oder Endnutzer, wir alle zahlen den Preis für die „Agilität“ von React. Ich habe bei der Arbeit schon oft gedacht, wie schön es wäre, einen anderen Stack verwenden zu können
Außerdem fand ich die Empathiefähigkeit des Autors beeindruckend und wie er das als eine Struktur entworfen hat, bei der „alle gewinnen“. Sich zu kümmern zahlt sich am Ende aus
Dem stimme ich stark zu. Ich habe früher einen Blog gebaut, der extrem viel JavaScript verwendete, und wegen der JS-basierten Funktionen wäre es fast zu einer Revolte gekommen
Ich hatte noch keine Zeit, auf einen HTML-first-Ansatz umzusteigen, aber nach außen hin habe ich es größtenteils wie eine HTML-first-Webseite aussehen lassen
In meinen Analysedaten habe ich sehr ähnliche Ergebnisse gesehen. Die Absprungrate sank von 80 % auf ungefähr 50 %, und neue Besucher bei späteren Artikeln wurden fast doppelt so viele
Wenn ich daran denke, wie viele Menschen wegen meiner anfänglichen, mit JS gebauten Katastrophe meine Domain womöglich für immer meiden, wird mir ganz anders. Für eine Webseite oder einen Blog ist das einer der wichtigsten Ratschläge überhaupt
So eine Herangehensweise hilft auch beim automatischen Ausfüllen von Formularen. Früher war einmal ein ganzes Formular dynamisch, und die einzelnen Teile hatten keine Attribute, an denen man sie erkennen konnte, sodass kein Auto-Fill möglich war
Das war bedauerlich, weil es eher auf hübsches Aussehen als auf Funktion hin überdesignt war, und deshalb habe ich diesen Artikel über nutzerorientiertes Design gern gelesen
Wenn man dazu noch SSE-Streaming und eine Morph-Bibliothek nimmt, kann man auch dynamische, Echtzeit- und Multiplayer-Funktionen ziemlich elegant bauen