Ich habe noch einen halbfertigen Rant auf Halde, in dem ich am Beispiel eines gewissen, aus unerfindlichen Gründen populären E-Commerce-Systems (dessen Name mit M anfängt und mit agento aufhört) auf Websites schimpfe, die ohne JavaScript nicht funktionieren. Da ich mir aber ziemlich sicher bin, dass ich mich dort gleich mehrfach im Ton vergriffen habe, lösche ich diesen Text jetzt und lasse Jenn Lukas sprechen. Die gute Frau bringt die wichtigsten Gründe nämlich in wesentlich zivilisierterer Form vor, als ich mir das gelingen würde und liefert uns einen schönen kurzen Vortag, den man wunderbar als Munition gegen die meine-Website-muss-ohne-JS-nicht-funktionieren-Fraktion verwenden kann:
Jenn Lukas - JSConf 2010 auf Blip.tv
Alle guten Gründe hin und her – was mich an JS-untauglichen Webseiten mehr als alles irritiert, ist dass es sie überhaupt gibt. Wenn man nur kurz überlegt, bevor man draufloshackt, passieren ohne JS benutzbare Websites wie von selbst. Unobtrusive JavaScript ist kein Hexenwerk, sondern, sofern man seine Auszeichnungs- Gestaltungs- und Script-Schichten sauber trennt, fast unvermeidlich. Um Seiten zu bauen, die nur mit JavaScript funktionieren, muss man sich richtiggehend anstrengen. Und mir ist nicht wirklich klar, was in den Köpfen jener vor sich geht, die sich diese Mühe machen und derartiges HTML an die Öffentlichkeit lassen:
<button type="button" class="button" onclick="productAddToCartForm.submit()"><span><?php echo $this->__('Add to Cart') ?></span></button>
Klar, wenn man ein hyper-dynamisches neues Webapp rund um neueste JavaScript-Features herum konstruiert und das Projekt ohne JS prinzipbedingt nicht funktionieren könnte, wäre das etwas anderes. Aber eine herkömmliche Website oder einen Onlineshop mutwillig oder fahrlässig fest an JS zu binden, ist, als würde man über das Schiebedach in ein Auto einsteigen. Das kann man sicher so machen, aber wenn vorher nur kurz nachdenkt und entsprechend plant, kommt man ohne zusätzliche Mühen auch anders in die Karre – und sieht dabei dann auch nicht aus wie ein Vollhonk.
Kommentare (31)
rr ¶
9. November 2010, 14:14 Uhr
Da gibt es einige verkorkste ecken im Netz zu finden, wo Javascript nicht nur sinnlos ist, sondern auch Browserfunktionalität einschränkt. Zum Beispiel, wenn man versucht einen Javascript-Link mit der rechten Maustaste in einem neuen Fenster zu öffnen.
Felix de Ruiter ¶
9. November 2010, 14:37 Uhr
Ach Peter, du hast so die Angewohnheit, Dinge so wunderbar auf den Punkt zu bringen, dass mir das Herz aufgeht. Danke! =)
Markus Q ¶
9. November 2010, 14:43 Uhr
Hallo Peter,
danke fuer das video - werd ich gleich mal meinen kollegen zeigen ;-)
aber nachdem du auch einen magento-rant erwaehnst: kannst du mir den draft mal zukommen lassen? bin naemlich auch ned ganz gluecklich damit aber mangels alternativen (bzw. was gibt es fuer shop-alternativen?)...
thx
q
antpaw ¶
9. November 2010, 14:52 Uhr
einerseits ist in dieser sicht rails 3 der vorbildliche Vorreiter des unobstructive javascript im webapp bereich. doch gleichzeitig ist eine rails webapp die mit dem neusten restful ninja tricks gespickt ist einfach nicht benutzbar ohne javascript, weil die browser keine "put" oder "delete" requests können und man mit javascript sie nachträglich reinhacken muss. so wird das immer ein zweiseitiges schwert bleiben.
Peter ¶
9. November 2010, 15:08 Uhr
Zitat Markus Q:
Der Rant ist leider bereits gelöscht. Und brauchbare Alternativen gibt es nicht, nur kann das ja schlecht als Entschuldigung für die Ranzigkeit von Magento herhalten.
FNessel ¶
9. November 2010, 16:40 Uhr
Das Thema hat so einen Bart, das es schon fast wieder anfängt aktuell zu werden. Denn:
Da sind die Grenzen inzwischen fließend. Wo fängt denn eine „hyper-dynamische Webbapp“ an und was bedeutet „funktionieren“ genau?
Um ein ganz einfaches Beispiel zu nennen: Der Fallback bei den ganzen Lightboxen ist, das einfach das Bild geöffnet wird. Das wiederum wurde von Kunden bei mir schon des öfteren mal als Fehler reportiert, weil sie nicht verstanden haben wieso sich da einfach ein Bild öffnet und die Website weg ist.
Grundsätzlich bin ich ja bei euch, aber viele dieser „Ajax“-Features sind auch so erhebliche UI-Verbesserungen, das es ohne sie kaputt wirkt oder manche Sachen auch einfach gar keinen Sinn machen.
Peter ¶
9. November 2010, 16:50 Uhr
Zitat FNessel:
Und wenn, wie im Video, gar nichts kommt, wird das nicht als Fehler interpretiert?
Philip ¶
9. November 2010, 16:59 Uhr
Ich halte das prinzipiell für eine schöne Theorie, aber in der Praxis leider häufig nicht so einfach, sich dran zu halten.
Was macht man denn, wenn der Kunde eine Bilder-Slideshow haben will und dabei nicht auf Flash aufsetzen möchte? Ohne Javascript sieht man nur die normalen Bilder. Mache ich mir ja jetzt in HTML ein großes Fallback, welches dann mittels Javascript in die entsprechende Slideshow "portiert" wird, sodass man auch alle Bilder ohne HTML sieht? Klar, könnte ich machen. Ich muss aber dem Kunden sagen, dass seine Entwicklung dadurch länger dauert, als wenn man es direkt (zugegebenermaßen etwas dreckig) in Javascript umsetzt. Die meisten Kunden wissen eh nichts von Non-Javascript-Fallbacks und würden dann kommen mit "Aber ich möchte doch, dass das so oder so aussieht".
Ich verstehe eigentlich heutzutage kaum noch, warum man sich bei einigen Sachen überhaupt die Mühe für einen Fallback macht. Ich kenne kaum eine Kundenseite, wo die Javascript-Verbreitung nicht bei über 99% ist. Für diese Seiten ist ein "Fallback" nur ein weiterer Kostenfaktor und keine Marketing-Maßnahme. Klar könnte man jetzt sagen, dass Screenreader die Seite nicht so sehen können, aber auch dort ist die Zielgruppe nicht wirklich groß (zumindest nicht bei meinen Kundenseiten). So leid es mir tut, aber wenn ich für 10-15% IE6-User meine Seite nicht optimiere, dann auch nicht für <1% Screenreader-User.
Wenn ein Kunde auf ein ordentliches Fallback bzw. BITV-Kompatibilität wert legt, dann muss man ihn schon im Briefing darauf aufmerksam machen, dass man zunächst ein Non-Javascript-Layout machen muss, welches im nachhinein mit Javascript nur um vereinfachte Funktionen erweitert wird - nicht zuerst Layout, dann BITV-Konformität. Einige Sachen sind eben dann nicht möglich bzw. sind deutlich aufwändiger.
Korrigiert mich bitte, wenn ich hier völlig falsch liege.
Samisdat ¶
9. November 2010, 17:08 Uhr
Ich korrigiere Dich!
Enno ¶
9. November 2010, 17:18 Uhr
Zitat Philip:
Ein Glück, dass du nicht über Behindertenparkplätze oder die Barrierefreiheit von Architektur zu entscheiden hast. Und ein Unglück, dass du es in deinem kleinen Teil des Web darfst.
Am Rande: *Optimieren* muss man sicherlich nicht mehr für den IE6 oder alternative Endgeräte, aber *funktionieren* sollte die Seite damit schon. Zum Glück macht der Markt über kurz oder lang zuverlässig Kleinholz aus Firmen, die arroganterweise annehmen, auf 15% ihrer potenziellen Kunden verzichten zu können.
Torsten ¶
9. November 2010, 19:17 Uhr
Nur zur Erheiterung von Peter hier mal ein Beispiel, was manche im Netz für einen Link halten:
Das tut weh, oder? ;-)
florian ¶
9. November 2010, 19:57 Uhr
Lieber Philip,
eine Korrekutr für dich, obwohl du unter einem Prozent der hiesigen Kommentatoren ausmachst:
eine Seite - gerade für gewerbliche Kunden - sollte funktionieren. Hält man sich an die wichtigsten Standards, funktioniert eine Seite quasi automatisch barrierefrei.
Zugegeben: in entsprechenden Situationen kann es sinnvoll sein, keinem abgesegneten Standard zu entsprechen. Da sollte man aber wissen, was man tut; bspw. box-shadows nutzen, die KEINEN Effekt auf die Funktionalität haben.
Darüberhinaus sollte Javascript an sich nur als ein Werkzeug betrachtet werden, dass einem das Leben leichter macht. Komplexe Frontends gehören ab einem bestimmten Grad dazu!
Letztlich sind sich Leute, die Javascript tatsächlich ausgeschaltet haben, genauso wie behinderte Menschen, schon bewusst, dass die Welt für sie weniger farbig und beweglich ist. Man muss sie deshalb aber nicht per se ausschließen.
Oder - um es mal an deinem Beispiel festzumachen: für eine Galerie reicht es, nur die Bilder darzustellen, mit Javascript kann man das auch toll verbessern ... aber bitte: die Leute wollen im Endeffekt nur die Fotos sehen. Und wenn das eine Prozent dir so egal ist, dass dus denen im Moment vorenthälst: zeig denen die Fotos und du verbesserst deren Situation um gerundete hundert Prozent.
Ich hab da auch noch ein paar Frage:
auf den von dir nicht als Quelle angegebenen Seiten wird ein "Non-Javascript-Anteil" von unter einem Prozent gemessen.
1. Wenn die Seiten kein Javascript verwenden ist die Statistik für dich ... wertlos?!
2. Wenn die Seiten Javascript voraussetzen, warum sollte die jemand ohne Javascript benutzen?!
3. Wird der "Non-Javascript-Anteil" per Javascript gemessen?!
4. Wenn der Anteil per HTTP-Header gemessen wird: jemand benutzt aus persönlichen Gründen kein Javascript, übermittelt aber ganz normal alle Header-Infos?!
5. Bekanntlich ist Google ein Mensch und kommt wunderbar mit Javascript zurecht. Jetzt die Frage: oder?
Rodney Rehm ¶
9. November 2010, 21:02 Uhr
Amüsant. Wir schreiben das Jahr 2010 und es gibt tatsächlich noch (gewerblich aktive und erfolgreiche?) Webdesigner™, die einen grundlos blockierenden Einsatz von Javascript für gerechtfertigt halten.
Zitat florian:
a) masochistische Neigungen des Benutzers (vgl. Internet Explorer Benutzer)
b) Link gefolgt, kaputte Seite gefunden, gegangen (Neudeutsch: Bounce)
c) Maschine (Bot), die sich nicht als solche identifiziert
d) …
e) Traue keiner Statistik, die du nicht selbst gefälscht hast.
Zitat florian:
That Just Made My Day! :)
Zitat florian:
Mal von (angepassten) AJAX-Requests abgesehen, enthält der HTTP-Request keine Informationen über das Vorhandensein von Javascript?
Zitat florian:
Google hat V8. Google frisst heutzutage auch AJAX-Seiten, sofern sie gewissen Regeln entsprechen: http://bit.ly/cc64XU - ok, ja, das mag weniger Javascript sprechen, als auf URL-Konventionen zu setzen sein, zugegeben.
Oliver ¶
10. November 2010, 08:28 Uhr
Ich möchte noch eine weitere Zielgruppe der Nicht-Javascript-Nutzer aufführen: einige mobile Browser, zum Beispiel der weit verbreitete Opera Mini, nutzen Serverseitiges Caching und zeigen dem Nutzer immer nur eine fertig gerenderte Version der Seite. Javascriptfunktionen werden dabei zwar weitestgehend über neue Seitenaufrufe umgesetzt, aber das funktioniert nicht immer. Da ist es doch schön den Inhalt trotzdem zu sehen, auch wenn die Lightbox oder ähnliches weg fällt.
Ich denke sogar, dass diese Browser gar nicht in die Sparte "hat-kein-javascript" rein fallen, da die Serverengine sicherlich auch das js auswertet, der Client aber nicht.
florian ¶
10. November 2010, 15:28 Uhr
@Rodney Rehm:
Das war eher gemeint als "warum sollte man sich Gedanken über Gardinen machen, wenn es keine Fenster gibt" ...
Richtig. Aber Informationen darüber, welcher Browser im Einsatz ist. Und hochgetunte Statistik-Module verwenden auch noch Javascript, um entsprechende Angaben zu ergänzen.
Wobei die Frage "Eine Angabe über die Verwendung von Javascript lässt sich häufig aus dem verwendeten Ajax-Header herleiten, oder?!" auch sehr gut gepasst hätte! ;)
OK, die Einleitung war blöd ... ich hätte lieber von einfachen Parsern und "um Javascript erleichterte Clients" (etwa Google&Co., Mobiles, ...) schreiben sollen.
Witzig an @Philips Kommentar auch (wo ich nochmal drüber nachdenke ...):
die Unverhältnismäßigkeit deines "Javascript-Monotheismus" sollte auch allen klar werden, wenn man sich vor Augen führt, was für eine (mediale) Welle es schlägt, wenn Apple so komisches Flash eben nicht implementiert. Wobei die - bisher ja nur betroffenen - Apple Mobiles wahrscheinlich einen verächtlich geringen Anteil der Internet-Userschaft ausmachen. Ist wohl so ein Ding von "Gottes Gnaden"/Lobbyismus.
Robert ¶
10. November 2010, 18:53 Uhr
Zitat Philip:
<blockquote cite="http://www.peterkroener.de/warum-websites-
Ich verstehe eigentlich heutzutage kaum noch, warum man sich bei einigen Sachen überhaupt die Mühe für einen Fallback macht. Ich kenne kaum eine Kundenseite, wo die Javascript-Verbreitung nicht bei über 99% ist. Für diese Seiten ist ein "Fallback" nur ein weiterer Kostenfaktor und keine Marketing-Maßnahme. Klar könnte man jetzt sagen, dass Screenreader die Seite nicht so sehen können, aber auch dort ist die Zielgruppe nicht wirklich groß (zumindest nicht bei meinen Kundenseiten). So leid es mir tut, aber wenn ich für 10-15% IE6-User meine Seite nicht optimiere, dann auch nicht für <1% Screenreader-User.
...
Korrigiert mich bitte, wenn ich hier völlig falsch liege.
Du liegst völlig falsch und hast zudem das Problem nicht verstanden. Wenn du nicht weißt, wie man Javascript barrierefrei - zum Beispiel tastaturbedienbar - programmiert, solltest du dir Nachhilfe holen. Und wenn deine Kunden auf fast 9 Millionen vorwiegend ältere Kunden verzichten können, dann herzlichen Glückwunsch. Das Ignorante liegt IMO darin zu glauben, Blinde seien die einzigen, die Barrierefreiheit bräuchten.
mike ¶
12. November 2010, 14:16 Uhr
Zitat Philip:
Ich kenne kaum einen Webdesigner, der Statistiken zu lesen UND zu verstehen weiss.
Was hiermit passiert wäre.
Schade, dass in solchen Diskussionen immer wieder Paradebeispiele herkommen müssen, die ihre Ahnungslosigkeit in solcher Deutlichkeit und Ausführlichkeit herausstellen müssen.
Oliver ¶
12. November 2010, 14:22 Uhr
Zitat mike:
Ganz groß diese Von-oben-herab-Mentalität. Wenn jeder "Ahnung" hätte könnten wir uns doch gleich die Diskussion sparen.
Michael ¶
13. November 2010, 18:18 Uhr
Auch von mir ein Dankeschön. In einer Zeit, in der fast jeder Webdesigner, Webworker, Webentwickler etc. von sich behauptet, nach Webstandards und selbstverständlich barrierefrei und suchmaschinenoptimiert zu arbeiten, dürfte es doch solche Probleme nicht mehr geben!
Leider ist dem nicht so. Für mich stellt sich auch weniger die Frage, ob man es sich leisten kann, bestimmte Nutzergruppen auszuschließen, sondern es geht viel mehr um das Prinzip, ja vielleicht sogar um Gleichberechtigung, dass möglichst jeder ein Anrecht darauf hat eine Website zu verwenden.
Jenn trifft es wirklich gut. Danke für das Video!
Wenn man nach dem Prinzip HTML > CSS > JS und/oder Flash arbeitet, dann ist es doch gar kein so großes Problem.
André ¶
13. November 2010, 20:54 Uhr
Zitat FNessel:
Anstatt das nackte Bild zu öffnen, könnte auch einfach eine Webseite mit dem Bild geöffnet werden. Dann ist die Site bei einem Klick auf ein Thumbnail genausowenig "weg" wie bei einem Klick auf den Impressum-Link.
mike ¶
13. November 2010, 22:13 Uhr
Zitat Oliver:
Korrekt. Nicht korrekt ist meines Erachtens in ein Weblog reinzulatschen und millionenfach durchgekauten und weitere millionenfach widerlegten Nonsens reinzurotzen. Wenn ich bei den "Grossen" mitspielen will, dann mache ich mich vorher kundig oder frage freundlich.
Bei Blasen wie "99% haben JS aktiviert" geht mir das Messer in der Tasche auf. Insofern teile ich hier auch nur meine Meinung mit - zumindest solange Peter das "genehmigt".
André ¶
14. November 2010, 14:37 Uhr
Grundsätzlich sehe ich es genauso, dass eine Website auch ohne JavaScript funktionieren sollte. Es gibt aber Anwendungsbereiche, wo es nicht bloß darum geht, eine "klassische" Bildergalerie mit ein bisschen Lightbox-Gezappel aufzumotzen.
Bei der Programmmierung von Warenkorb-Systemen, die ganz ohne JavaScript funktionieren, hat mich bisher immer gestört, dass der Warenkorb des Besuchers auf dem Webserver zwischengespeichert werden muss. Dies zieht allerlei Kram nach sich, zum Beispiel das Löschen verwaister (nicht als Bestellung abgeschickter) Warenkörbe, aber auch Sicherheitsfragen, da Besuchern im Prinzip Schreibrechte auf dem Webserver eingeräumt werden, die es vor Missbrauch (z.B. Flooding) zu schützen gilt.
Ein javascript-basierter Warenkorb hat diese Probleme nicht - dank "Local Data Storage" und früherer "Tricks" mit Frames oder window.name kann der Warenkorb im Browser des Besuchers abgelegt werden. Hier kann es kein einfaches "Noscript"-Fallback geben, weil ein client-seitiger Warenkorb ohne JavaScript nunmal nicht funktioniert. Also liefe es wieder auf einen zusätzlichen server-seitigen Warenkorb hinaus - mit all den oben genannten Problemen.
Da die server-seitige Version mindestens den gleichen Aufwand wie die JavaScript-Version macht, könnte man diesen Zwiespalt natürlich auch so lösen, indem man überhaupt keine JavaScript-Version anbietet. Das würde aber bedeuten, den 98-99% der Besucher mit eingeschaltetem JavaScript all die angenehmen und nützlichen javascript-basierten Features vorzuenthalten, nur weil 1-2% der Besucher JavaScript ausgeschaltet haben. Es wäre durchaus möglich, dass man damit mehr Benutzer zur Konkurrenz vertreibt als nur die 1-2%, die wegen eines fehlenden Noscript-Fallbacks dorthin gehen würden.
Wenn man also weder das eine noch das andere möchte, bleibt einem nichts anderes übrig, als die Warenkorb-Verwaltung zweimal zu programmieren: einmal als JavaScript- und einmal als PHP-Version. Vorher sollte man aber den Auftraggeber aufklären und prüfen, ob sich die PHP-Version überhaupt jemals amortisieren würde.
Abgesehen davon halte ich client-seitige Warenkörbe einfach für das bessere Konzept. Ich hab mich lange gegen reine JavaScript-Lösungen gesträubt, aber angesichts der Möglichkeiten, die JavaScript heute bietet, empfinde ich diese Haltung immer mehr als Anachronismus. Die Lösung kann nicht sein, neben der fortschrittlichen Lösung bis in alle Ewigkeit zusätzlich oder gar ausschließlich noch eine Steinzeit-Lösung bereitzustellen. Entweder wir akzeptieren JavaScript endlich als eine der selbstverständlichen Säulen der Web-Welt oder es muss ein ganz neuer Ansatz entwickelt werden, der ohne JavaScript und auch ohne PHP auskommt, also rein auf HTML basiert. Eine Vorstellung, wie sowas aussehen könnte, hätte ich schon, aber das wäre ein ganz neues Thema ...
mike ¶
14. November 2010, 15:14 Uhr
Ein clientseitiger Warenkorb?
Und wenn ich - aus welchen Gründen auch immer - meine Bestellung nicht jetzt abschicke, sondern später, auf einem anderen Rechner? Wenn ich bspw. zur Kontrolle der bestellten Waren noch einmal einen Experten zu Rat ziehe?
Wie willst Du denn mit einem Warenkorb einen Server flooden? Der serverseitige Warenkorb hat einfach eine Verfallszeit von sagen wir 14 Tagen und fertig.
Sehe da überhaupt kein Problem.
Peter ¶
14. November 2010, 15:22 Uhr
Zitat André:
Dafür kann dann jeder halbwegs fitte JS-Nerd dann fremde Warenkörbe ausspähen. Diese Tendenz, aus Bequemlichkeit alles clientseitig zu speichern, ist der Grund, warum Douglas Crockford HTML5 (nebst Local Storage und sonst allem) abschaffen will.
Ist das nicht lustig? Früher galt JS als nicht ernstzunehmendes Spielzeug, jetzt ist es plötzlich unser aller Lösung für sämtliche Probleme.
Richard ¶
11. Dezember 2010, 03:45 Uhr
Nette Diskussion. Ich vermisse hier aber den nach meiner Meinung wichtigsten Punkt. Wer bezahlt die Mehrarbeit? Wenn ich meinen Kunden sage die Optimierung kostet x €, dann kann ich dir versichern das diese Mühe umsonst ist. Ich kenne das ganze auch vom IE6 ganz gut. Seid einem Jahr unterstütze ich diesen nur noch rudimentär. Gegen Mehrpreis passe ich die Programmierung so an, dass es zu 98% gleich aussieht. Bisher wollte das kein Kunde, weil auch die alle den Fortschritt sehen.
Das selbe passiert zur Zeit auch mit Flash. Bekomme ich beim Kunden kaum noch verkauft. Da hört man direkt "das iPhone kann das nicht", "bin mir nicht sicher ob das noch Zukunft hat" usw. Die wollen dann eher eine JavaScript/Html Lösung.
Man sollte immer daran denken das wir für Leute arbeiten die uns für unser Wissen und vor allen Dingen für unsere Zeit bezahlen. Und Zeit ist leider absolut begrenzt und somit bei guten Webdesignern teuer ;-).
@Peter
Grosses Lob für den tollen Blog und deine Beispiele in dem Beitrag sind auch absolut richtig. Sowas kann man leicht und locker ohne Mehrkosten besser regeln.
Gerald ¶
8. Januar 2012, 14:35 Uhr
Interessante Diskussion hier (und meiner Meinung nach noch immer aktuell). Für mich mag es noch angehen, wenn eine Webseite aufgrund inkompatibler JS-Tricks nicht ganz so schön bzw. nicht überall gleich aussieht. Wenn es aber um Webapplikationen geht, dann sollte das Funktionieren nicht von der Client-Konfiguration abhängen. Aus diesem Grund muß man sich schon die Mühe machen etwa den Inhalt eines Warenkorbs so zu verwalten, dass nichts passieren kann - also am Server. Mit Mechanismen wie PHP-Sessions ist das auch wirklich nicht so schwierig, oder ?
Peter Kröner ¶
8. Januar 2012, 17:36 Uhr
Warenkörbe kriegt man mit PHP-Sessions und ohne JavaScript hin. Eine clientseitige Mal-Webapp mit Canvas, Drag & Drop und File API nicht.
Gerald ¶
9. Januar 2012, 09:58 Uhr
Klar HTML & CSS haben ihre Grenzen.
Umgekehrt kann man aber auch die Frage stellen, ob JS eine geeignete Sprache bzw. Umgebung ist, um die angesprochenen Mal-Applikationen zu programmieren.
Viele Entwickler würden diese Frage wahrscheinlich verneinen, denn
wenn ich mich so umschaue am Markt, sind die bekannten Vertreter in diesem Bereich doch in Java, C++ oder C# geschriebene Desktop Applikationen.
Aber das soll jetzt kein Flame gegen JS werden. Manche Dinge, wie zum Beispiel das Setzen des Cursors auf ein bestimmtes Eingabe-Feld oder das Schließen eines Browserfensters lassen sich sehr gut mit JS erledigen.
Wenn dann ein Benutzer JS deaktiviert hat, wird die Applikation trotzdem verwendbar sein. Ich denke das ist wichtig.
Peter Kröner ¶
9. Januar 2012, 13:36 Uhr
Man könnte auch ein etwas weniger abgefahrenes Beispiel als ein Malprogramm nehmen, zum Beispiel Google Docs. Das ist erprobt, populär und ohne JavaScript absolut nicht funktionsfähig. Wäre doch schade, wenn es diesen nützlichen Dienst nicht gäbe, nur weil es ein Dogma gibt, alles im Browser müsse ohne JS funktionieren. Das geht eben nur bei Webseiten.
Anselm Hannemann ¶
9. Januar 2012, 14:08 Uhr
Gut, Taskliste kann man ja auch nehmen. Sowas soll ja synchron gehalten werden. Das geht mit Webtechniken (ergo via Browser) viel einfacher als mit C# o.ä. – genauso kann man das auf cloudbasierte Bildeditoren ummünzen. Und ohne JS kann kein Cloudbasierter Service geschaffen werden, wie in dem Fall benötigt.
Ich war gerade bei einem Projekt dabei, wo eine Art InDesign im Browser gebaut wurde. Mit Workflow, Live-View auf iPad usw. – wie soll das Cross-Plattform mit herkömmlichen Programmiersprachen umgesetzt werden? Oder ohne Javascript?
Ich sage eher: Wer sowas nutzen möchte, braucht einen anständigen Browser. Das ist doch bei C# ähnlich. Kein C# Programm geht auf einem Mac oder unter Linux, man braucht sogar auf dem Windows Rechner das .net Framework. Und einen passenden Rechner auch, der das Programm ausführen kann.
Name ¶
4. April 2013, 17:02 Uhr
Was hier noch nicht angesprochen wurde ist, dass aus Sicherheitsgründen für das eigene System davon abzuraten ist, irgendwelchen Code auf dem Clienten auszuführen. Das kann der Betreiber auf dem Server machen.
Websites, die ohne Script nicht bedienbar sind, werden gleich wieder geschlossen und haben damit weniger Besucher.