Der JS Party Podcast hatte gerade eine lustige Episode, in der sie diese klassische Frage diskutierten, indem sie sich in zwei Zweiergruppen aufteilten. Jede Gruppe erhielt eine „Seite“ dieser Debatte und durfte dann loslegen. Ich glaube nicht, dass jemand, der eine solche Sendung hört, nicht von Gedanken überschwemmt wird! Hier sind meine.
- Das ist einer dieser heiligen Kriege, die seit Jahren toben. Vielleicht liegt es daran, dass die Leute nach einer Antwort suchen, die für das gesamte Web gilt, und das Web ist zu groß, um eine so breite Antwort zu geben.
- Die Frage selbst ist einer Betrachtung wert. Warum sprechen wir darüber, unsere Seiten auf diese bestimmte Weise zu behindern? Sollten unsere Websites ohne HTML funktionieren? Sollten unsere Websites ohne Datenbanken funktionieren? Vielleicht konzentrieren wir uns am meisten auf JavaScript, weil JavaScript zum größten Engpass der Web-Performance geworden ist (noch mehr als das Netzwerk!) und wir erleben fehlgeschlagenes JavaScript häufiger als jede andere Art von Web-Ausfall (außer vielleicht, dass ganze Websites nicht geladen werden) (oder Icon-Fonts, verflixt).
- Ich genoss das ganze Stolpern über die Terminologie von „Web-Apps“ und „Websites“ (Web-Dinge!). Das ist so ein seltsames Ding. Es ist so einfach, sich den Unterschied im Kopf vorzustellen: es ist wie Facebook im Vergleich zu einem Blog! Aber wenn man anfängt, es genau zu definieren, wird es sehr schnell unklar und die Unterscheidung verliert jeden Wert, wenn sie überhaupt einen hatte. Mehr dazu hier.
- Barrierefreiheit ist sicherlich in allen Gesprächen über das Web involviert, aber sie kann hier wahrscheinlich nicht breit angewendet werden. Es gibt die Vorstellung, dass assistive Technologien kein JavaScript ausführen – eine Seite, die JavaScript zur Nutzung benötigt, ist für diese Benutzer ein Totalausfall. Soweit ich weiß, stimmt das längst nicht mehr. Wir können die Rolle von JavaScript bei Barrierefreiheitsproblemen bis zum Tod diskutieren, aber nur weil eine bestimmte Seite JavaScript benötigt, um zu laufen, macht sie die Seite nicht per se unzugänglich.
- Es ist einfach genug, JavaScript auszuschalten, im Web zu surfen, kaputte Dinge zu finden und sie wegen dieses offensichtlichen Fehlers zu kritisieren. Der Fehler ist, dass diese Seite oder eine Funktion auf der Seite hätte ohne JavaScript entwickelt werden können. Regel der geringsten Macht. Das ist knifflig. Es ist leicht, sich nicht um eine Person zu kümmern, die absichtlich einen Teil ihres Webbrowsers deaktiviert hat und trotzdem alles funktionieren lassen möchte. Das ist mir ehrlich gesagt egal. Aber der Resilienz-Teil ist interessanter. Wenn Sie einen Teil einer Seite so bauen, dass er ohne JavaScript funktioniert, wird er sowohl vor als auch nach der Ausführung von JavaScript funktionieren, was ziemlich großartig ist.
- Das Konzept, funktionale Inhalte und Features ohne JavaScript zu erstellen und das Erlebnis mit JavaScript zu verbessern, nennt man progressive enhancement. Ich bin sowohl ein Fan davon als auch vorsichtig, nicht darauf zu bestehen, dass alles auf der Welt immer so gebaut werden muss (siehe erster Aufzählungspunkt). Es gibt Situationen, in denen progressive enhancement sowohl technische Schulden erhöht als auch reduziert. Die einzige allgemeine Regel, die ich hier anwenden würde, ist, dass es sich lohnt, bis die Schulden zu hoch sind.
- Es gibt einen Zwischenmoment beim progressiven Enhancement. Wenn ein Feature ohne JavaScript funktioniert, bedeutet das, dass Sie wahrscheinlich das Laden dieses JavaScripts zur Leistungssteigerung aufschieben. Aber es muss schließlich heruntergeladen und ausgeführt werden. Was passiert in dieser Zeit? Es gibt Kosten für Leistung und UX. Im besten Fall sind sie vernachlässigbar. Im schlimmsten Fall brechen Sie das Feature in dieser Zwischenzeit ab.
- Ich finde es interessanter, solche Dinge auf einer Seite-für-Seite- und Feature-für-Feature-Basis zu diskutieren. Application holotypes könnten eine interessante Möglichkeit sein, das zu skalieren. Sie griffen oft auf Slack als Beispiel zurück, was eine perfekte Wahl ist. Wie würden Sie eine Filmrezensions-Seite mit 20 Autoren erstellen? Wie würden Sie eine soziale und medienlastige Seite wie Dribbble aufbauen? Wie baut man Dropdown-Navigation? Was ist mit einer einseitigen Broschüren-Seite, bei der der Kunde Parallax wünscht? Wie wäre es mit einer Fluglinien-App, die auch eine native mobile App benötigt? Und natürlich regt es zum Nachdenken über die Seiten an, an denen man selbst arbeitet. Läuft CodePen mit dem richtigen Technologiesatz? Und CSS-Tricks?
- Wenn eine Seite „client-side rendered“ (CSR) ist, bedeutet das, dass JavaScript die Daten abruft und das DOM erstellt und all das. Wenn wir darüber sprechen, ob Websites ohne JavaScript „funktionieren“ oder nicht, wird eine client-side gerenderte Seite ohne JavaScript zu 100 % fehlschlagen. Es ist eine Art Gegenteil von „server-side rendered“ (SSR), bei der das Dokument als HTML direkt vom Server kommt. SSR ist für die erste Ladeerfahrung fast mit Sicherheit schneller. CSR ist typischerweise schneller, um sich nach dem Laden auf der Seite zu bewegen (denken Sie an „Single Page App“ oder SPA).
- Es ist nicht nur SSR vs. CSR – es gibt ein ganzes Spektrum. Es wird immer üblicher, dass Websites versuchen, das Beste aus beiden Welten zu nutzen. Zum Beispiel Next/Nuxt/Gatsby oder Embers fastboot.
- Service Worker sind JavaScript. Web Worker sind JavaScript. Einige der ausgefallenen Resilienz- und Performance-Features des Webs werden von der gleichen Technologie angetrieben, die die Probleme verursacht, über die wir diskutieren.
Website? Warum braucht eine Website überhaupt JS? Um Formulare ohne Neuladen der ganzen Seite zu senden? Das ist alles, wenn es kein JS gibt, kann die Website trotzdem voll funktionsfähig sein, nur etwas hässlicher
Das Admin-Panel für diese Website ist zwar immer noch ohne JS möglich, aber es lohnt sich wahrscheinlich nicht, sich darum zu kümmern, da die UX-Verbesserungen einfach zu groß sind, um sie zu ignorieren
Ich sage nein. Konzentrieren Sie sich darauf, Ihre Website zugänglich, performant, sicher und nutzbar zu machen, und verwenden Sie JavaScript, um dies zu erreichen (insbesondere für die Zugänglichkeit).
Per Definition ist eine Website, die JavaScript zur „Nutzbarkeit“ benötigt, aus einer Vielzahl von Gründen für Personen, die kein JS ausführen, nicht zugänglich. Es wurde deaktiviert, lief auf einem veralteten Browser, die Verbindung war zu langsam, um das riesige Skript zu laden, das es benötigte, usw.
Zugänglich bedeutet nicht, dass es assistive Technologien die beabsichtigte Erfahrung und Inhalte liefern muss, sondern dass jeder (mit oder ohne Behinderungen, mit oder ohne Screenreader) darauf zugreifen können sollte.
In diesem Fall ist es nicht nur JS. CSS kann eine Website ebenfalls unzugänglich machen (z. B. wenn Sie einen Inline-Stil haben, der alles ausblendet, bis das CSS geladen ist, und das Element dann erscheinen lässt. Wenn das CSS nie geladen wird, ist Ihre Website nicht zugänglich).
Obwohl wir uns zweifellos bemühen sollten, unsere Projekte ohne JavaScript so funktional wie vernünftig zu gestalten, denke ich, dass wir weit über den Punkt hinaus sind, an dem „es kommt auf das Projekt an“ eine gute Antwort ist.
JavaScript (insbesondere asynchrone Anfragen) hat die Standardbenutzererfahrung dramatisch verändert. Benutzer erwarten jetzt nahtlose Übergänge, sie gehen davon aus, dass ein Formularknopf wie „Speichern“ automatisch aktualisiert wird und die Seite nicht neu geladen wird. Ein tatsächliches Pop-up-Fenster würde blockiert werden und wäre, wenn nicht, störend – aber ein Modal? Erwartet.
Sicherlich können einige dieser Erfahrungen bis zu einem gewissen Grad mit CSS repliziert werden, aber JavaScript bietet auch ein Maß an Barrierefreiheitsunterstützung, das reine CSS-Lösungen noch nicht angemessen reproduzieren können.
Ich mache das nicht bei jedem Projekt, aber bei Projekten, bei denen ich weiß, dass JavaScript unerlässlich ist, habe ich immer ein
<noscript>, das den Benutzer sehr deutlich darüber informiert, dass JS aktiviert sein muss, um mit dem Dienst interagieren zu können. Das erspart mir viel Kopfzerbrechen bei der Filterung von Fragen von Kunden, die JavaScript deaktiviert haben, weil ihnen der Neffe der Schwester ihres Chefs gesagt hat, es sei ein Sicherheitsrisiko.Ich bin nicht vertraut mit Benutzern, die JS deaktivieren. Das fühlt sich wie der falsche Ansatz an. Wenn Leistung und Datenschutz die Probleme sind, gibt es bessere Wege (z. B. Tracking-Schutz), als JS komplett zu deaktivieren.
Riesige Skripte sind tatsächlich ein Problem, aber andererseits, wenn der JS-Code einer Seite klein ist (< 100 KB übertragen), dann ist das kein Problem, denke ich.
Darüber mache ich mir keine Sorgen. Wenn eine Webseite so implementiert ist, dass sie zum Arbeiten externes CSS und JS benötigt, dann ist das in Ordnung. Wenn diese Ressourcen nicht geladen und/oder ausgeführt werden, wird die Seite natürlich kaputt gehen. Es ist die Aufgabe des Webentwicklers, zu versuchen, das zu verhindern (oder es zumindest weniger wahrscheinlich zu machen).
Folgeartikel von Jens Oliver Meiert mit einigen Nutzungsdaten.
Ich wollte „nein“ sagen, aber je mehr ich darüber nachdenke, desto mehr ist die Antwort „ja“. Nicht, weil ich glaube, dass es ein dringendes Bedürfnis gibt, Benutzer zu unterstützen, die sich weigern, JS zu verwenden (es gibt sogar ein Argument dafür, dass nicht wenige Möchtegern-Hacker sind, aber das ignoriere ich).
Der Grund, warum ich denke, dass Sie Ihre Website so bauen sollten, dass sie ohne JS funktioniert, ist, dass sie Ihnen hilft, sich auf bestehende Webtechnologien zu konzentrieren, sie zu lernen und zu implementieren, anstatt faul JS-Alternativen zu verwenden.
Zu oft habe ich Webentwickler gesehen, die direkt zu JS greifen, selbst wenn Vanilla HTML5 die gleiche Arbeit erledigen würde. Es ist in Ordnung, JS zu verwenden, wenn es einen guten Grund gibt, aber Unkenntnis über Ihre Optionen ist keiner davon.
Also ja, bauen Sie Ihre Website so, dass sie ohne JS funktioniert – das macht Sie zu einem besseren Entwickler.
Ich habe nie wirklich verstanden, warum das überhaupt eine Debatte ist. Sollte eine Website ohne CSS funktionieren? Sicher… aber warum? Sollte ein Haus ohne Fenster oder fließendes Wasser funktionieren? Wenn Barrierefreiheit ein Anliegen ist, kann JS diese Erfahrung verbessern, nicht beeinträchtigen.
JS ist eine Webtechnologie und Teil des Stacks, warum ist es eine Frage, ob man sich für die Rolle, die es spielt, darauf verlassen sollte? Was SONST würden wir verwenden, um die Vorteile zu erzielen, die JS bietet?
Progressive enhancement ist der Schlüssel. Das bedeutet, dass die wichtigsten oder Kernaspekte Ihrer Website funktionieren sollten, wenn JavaScript deaktiviert ist ODER ein Skriptfehler auftritt. Zum Beispiel sollte Ihr Warenkorb immer funktionieren: Warum würden Sie den Checkout in diesen Fällen anfällig lassen?
Zu oft stelle ich fest, dass eine Seite aufgrund eines Skriptfehlers oder einer fehlenden Abhängigkeit aufgrund von Ad-Blockern oder weil der verwendete Browser nicht aktuell genug für Ihre Skripte ist, kaputt ist. Also, vielleicht braucht nicht alles ein Noscript-Backup, aber Sie sollten bewerten, ob der Hauptzweck Ihrer Seite immer noch funktioniert.
Ich denke, es hängt von den Projektanforderungen ab, einschließlich der Barrierefreiheitsanforderungen.
In einigen Projekten, wie z. B. solchen mit Benutzern in bestimmten afrikanischen Ländern, ist die Verwendung von JS paradoxerweise die beste Lösung, um große technologische Herausforderungen bei der Barrierefreiheit zu lösen. Die Benutzer in diesen Ländern haben möglicherweise einigermaßen fortschrittliche/moderne Geräte, aber die mobile Datenmenge (ihre vorherrschende Datenquelle) ist verdammt teuer. In diesen Szenarien ist der Einsatz von JS normalerweise der effektivste Weg, um damit umzugehen.
Ich surfe im Web, ohne JavaScript aktiviert zu haben, und es ist ein erstaunlicher Ort. Ich bekomme keine Werbung. Ich bekomme keine nervigen Pop-ups, die versuchen, meine Großzügigkeit auszunutzen, indem sie keine Werbung blockieren. Ich benutze Brave und hoffentlich blockiert es all diese schrecklichen Tracking-Pixel, die mit einem Tag zu arbeiten versuchen. Meistens hat der FED, der es implementiert hat, es sowieso nicht richtig gemacht. Wenn ich auf eine Seite stoße, die ohne JavaScript nicht funktioniert, raten Sie mal, ich musste diese Seite nie besuchen. Soziale Medien sind toxisch. Medien selbst sind toxisch. Ich gebe kein Trinkgeld, wenn ich schlechten Service bekomme. Ich werde keinen Website-Besitzern Trinkgeld geben, deren Inhalte völlig wertlos sind und deren Werbung mehr Ladezeit beansprucht als die Zeit, die ich zum Lesen des Artikels benötige. Ich liebe es jedoch, wenn eine Seite mit deaktiviertem JS vollständig nutzbar ist, auch wenn das selten vorkommt. Wenn es um Menüs geht, suchen Leute, die JavaScript deaktivieren, nach Informationen, also erweitern Sie einfach das gesamte Menü. Respektieren Sie das Surfverhalten der Leute. Nehmen Sie sich die zusätzlichen 30 Minuten, um Ihre traurige „Web-App“ richtig zu machen – so wie das Web funktionieren sollte. Ich sollte in der Lage sein, das Web mit Lynx zu durchsuchen.
Ich habe JA gesagt!
Heutzutage sehe ich, wie Leute JS für Dinge verwenden, die sie mit CSS tun könnten (z. B. fadeIn), ich finde das verrückt, weil jeder nur JS lernt. Wir haben Semantik, Barrierefreiheit, Leistung usw. vergessen… aber andererseits lese ich solche Artikel, es ist wichtig für die Diskussion im Entwicklungs-Ökosystem.
Vor Jahren sollten Websites ohne CSS funktionieren, heute diskutieren wir über CSS-in-JS oder „Was sind die besten JS-Frameworks“…
Ich fange gerne damit an, Seiten nur mit HTML5 lesbar/nutzbar und zugänglich zu machen, bevor ich CSS und JS hinzufüge. Weniger ist mehr. Ich füge nur das CSS hinzu, das notwendig ist, und das JS, das absolut notwendig ist, um die Anforderungen zu erfüllen. HTML5 kann und sollte den Großteil der Arbeit auf jeder gut gestalteten Seite leisten. Es gibt viel grellen Müll da draußen.