Hallo! Ja, ich lebe noch. Ich hatte bloß ein paar Monate lang viel zu viel Arbeit am Hals und habe Webtech-Fragen nur per E-Mail oder in meinen Veranstaltungen bearbeiten können. Aber allein schon um die ganzen Spammer- und Webseitenaufkauf-Anfragen endlich mal loszuwerden, musste ich mal wieder dringend etwas schreiben. Und da ihr mir ja schön regelmäßig neue Fragen zu HTML5 und Co zuschickt, mangelt es mit wahrlich nicht an Material. An die Arbeit!

Asymetrische Addition in JavaScript

Warum ergibt in JavaScript [] + {} als Ergebnis den String "[object Object]", während {} + [] die Zahl 0 liefert?

Das erwartete Ergebnis der Addition eines leeren Objekts und eines leeren Arrays ist immer der String "[object Object]". Dass das bei {} + [] nicht passiert, liegt ganz einfach daran, dass hier gar nicht addiert wird.

Obwohl JavaScript bis Version ECMAScript 6 nur Function Scope gab, existierte der Block als Syntax schon immer. Man kann seit jeher { var x = 42; } schreiben, hat aber nichts viel davon. Wenn wir {} + [] ausführen (d.h. den Code genau so in die Konsole tippen), produzieren wir einen leeren Block und die Anweisung +[] – und das führt dazu, dass das Array in eine Zahl umgewandelt wird. Über den Umweg eines leeren Strings (die Zusammenfassung aller im Array enthaltenen Elemente) spuckt Number() eine 0 aus und zack: {} + [] === 0.

Wenn wir die beiden Schweifklammern in Klammern verpacken, interpretiert sie die JS-Engine nicht mehr als Block und wie bestellt kommt das richtige Ergebnis heraus: ({}) + [] === "[object Object]"

Native Prototypen erweitern – immer böse?

Die Prototypen nativer Objekte zu erweitern gilt als schlechter Stil. Was hältst du von solchen Erweiterungen, die die spezifizierte Methoden von ECMAScript 6 nachbauen? Zum Beispiel gibt es da diesen Poylfill für String.prototype.includes …

Polyfills sind die Ausnahme von der Regel, vorausgesetzt sie setzen den Standard entweder zu 100% korrekt um oder funktionieren auf eine Weise, die später nicht mit der echten Implementierung kollidiert. Einen Polyfill so zu konstruieren ist eine unglaublich anspruchsvolle Aufgabe.

Vor nicht all zu langer Zeit hat ein winziger Fehler mit drastischen Folgen im Polyfill für das Picture-Element für Aufsehen gesorgt und beinahe Umbauten in den echten Implementierungen und dem Picture-Standard selbst verursacht. Solche Dinge passieren, wenn ein Polyfill nicht perfekt ist (weniger als perfekt ist hier nicht akzeptabel) und sich an genau der Stelle einnistet, an der später die echte – möglicherweise subtil andere – Platz zu nehmen versucht.

Wenn ich den in der Frage verlinkten Polyfill mit dem Standard für String.prototype.includes vergleiche, sieht er mir nicht sehr exakt aus. So hat z.B. hat die Funktion im Polyfill nicht die length von 1, die der Standard vorschreibt. Auch fehlt der TypeError, der geworfen werden müsste, wenn der Input-Suchstring ein regulärer Ausdruck ist. Mir persönlich wäre dieser Schnipsel zu riskant, um ihn als Polyfill zu benutzen oder zu veröffentlichen.

Is Service Worker ready?

Ich möchte eine Webapp mit begrenztem Nutzerkreis bauen. Als Browser könnte ich Chrome voraussetzen. Die App muss erkennen, wenn kein Netz mehr vorhanden ist und getätigte Formulareingaben zwischenspeichern, bis der Nutzer wieder verbunden ist. Kann man dafür schon den Service Worker verwenden?

Was Chrome angeht ist die Unterstützung für Service Worker schon recht umfassend. Allerdings scheint mir für das beschriebene Problem der Service Worker gar nicht nötig zu sein. Nur wenn ein Hintergrunddienst laufen oder (u.A. zum Zwecke des Offline-Supports) Requests manipuliert werden sollen, führt kein Weg am Service Worker vorbei. Wenn es aber nur darum geht, Formulareingaben lokal zu speichern (und nicht das Ausliefern des Formulars das zu lösende Problem ist) reicht einer der guten alten HTML5-Speichermechanismen wie Web Storage oder Indexed DB. Hiermit könnte man einfach immer die Formulareingaben speichern ohne sich mit der Offline-Status-Erkennung (im besten Fall knifflig, im schlechtesten Fall unmöglich) herumzuschlagen. Und rund um das Thema „Formulardaten speichern“ gibt es sogar fertige Scripts wie Garlic.js

Zusammengefasst: Ja, für Chrome stünden Service Worker bereit, aber vielleicht reicht ja sogar ein sehr viel älterer Webstandard.

Welche Breakpoints für Responsive Design verwenden?

Ich habe nach Empfehlungen für Breakpoints für Responsive Design gesucht und über 3000 verschiedene, widersprüchliche Empfehlungen. Welche Breakpoints sind denn nun empfehlenswert?

Es gibt nur einen universellen Breakpoint für Responsive Design: den, ab dem es anfängt nicht mehr gut auszusehen. Ab welcher Bildschirmbreite ein Design verändert werden muss, hängt ganz allein vom Design ab – und da das bei jeder Webseite anders ist, gibt es keinen einzelnen Breakpoint der für alle gültig ist. Meine Empfehlung: einfach das machen, was gut aussieht und gut funktioniert.

Weitere Fragen?

All diese Fragen wurden mir per E-Mail, Twitter oder einen anderen digitalen oder analogen Kanal gestellt und auch eure Fragen zu HTML(5), CSS(3), JavaScript und anderen Webtechnologien beantworte ich gerne! Einfach mich anschreiben oder gleich das komplette Erklärbären-Paket kommen lassen.