In trauter Zweisamkeit diskutieren Stefan und Anselm über den Drang zu sechzig Frames pro Sekunde.
[00:00:21] News
- Browsersync 2.0
- Die neue Version des Entwicklertools kommt mit graphischer Oberfläche und verstärktem weinre Support.
Schaunotizen
- [00:03:10] FLIP your animations
- Geschwindigkeitsrausch: Paul Lewis stellt eine Micro Optimisation für CSS Transitions und Animations vor, und wir fragen uns nur: Warum gibt’s das nicht nativ in den Browsern? In der anschließenden Diskussion sprechen wir über Sinn und Unsinn dieser feingranularen Optimierungen und stehen für „nichts implementieren, was eigentlich schon so funktionieren sollte“ ein.
- [00:17:48] 60 fps on the mobile web
- Da der DOM für Flipbook viel zu langsam war hat man kurzerhand mit Canvas und React das ganze Ding selbst implementiert (The Fast). Damit aber auch gleich einen massiven Shitstorm der Community ausgelöst (The Furious). Wir hinterfragen die Mutter dieses Gedanken, loben die Vielseitigkeit von React und analysieren ab welchem Zeitpunkt man mehr Probleme damit schafft als löst. Gegen Ende stehen wieder einmal für „nichts implementieren, was eigentlich schon so funktionieren sollte“ ein und verweisen auf Chris Heilmanns exzellenter Sicht der Dinge zu diesem Thema.
- [00:41:51] CSS Variables are a bad idea
- Aaron Gustafson schreibt den „considered harmful“ Artikel der keiner sein möchte und spricht sich gegen CSS Variablen aus. Den Grundgedanken hinter seinen Überlegungen verstanden versucht Stefan allerdings zu missionieren: Sieht man die Spezifikation als Variablen im Sinne eines Präprozessors sollte man es wirklich besser bleiben lassen. Hat man allerdings den Scope der „CSS Custom Properties“ (so wie sie eigentlich heißen) erkannt, hat man damit ein mächtiges Werkzeug in der Hand, für das es viele ungelöste Use Cases gibt. Vorsicht sei geboten bei Poylfills wie Pleeease. Wenn man’s wirklich meint, lassen sich CSS Custom Properties nicht polyfillen, ohne massiv Browserfeatures nach zu implementieren. Und wir wissen ja, dass wir „nichts implementieren, was eigentlich so funtionieren sollte“. Ein Hinweis auf Rodneys Artikel zu dem Thema aus dem Jahr 2013 sei noch einmal sehr ans Herz gelegt.
[00:56:39] Keine Schaunotizen
- Designing for the Elderly
- Worauf man achten muss, wenn man für ältere Menschen designed. Guter Artikel auf Smashing Magazine.
- Plumin.js
- Schreib dir deinen eigenen Webfont mit einer pfiffigen JavaScript API. Wir sagen nur Wow!
- Revisiting LESS
- Als Sass User schreibt Stefan über seine Erfahrungen mit der zwangsbeglückten Nutzung von LESS. Die herausragenden Features scheinen banal, sind aber am Ende die, die am glücklichsten machen.
Kommentare
franky #
Geschrieben am 4.03.2015 um 08:41
Von wegen: warum ist der DOM so langsam?
– Dom muss in allen usw cases gehen, der virtual Dom muss ganz genau für das eine framework funktionieren. Dadurch kann man natürlich ohne Ende optimieren.
– die dom-Implementierungen sind alle aus einer Zeit wo das web ganz anders genutzt wurde. Entsprechend werden die halt auf 20 Jahre alte use-cases optimiert von der ganzen Architektur her, und nicht auf die Anforderungen moderner mvc-frameworks.
Stefan #
Geschrieben am 4.03.2015 um 08:48
Hat ja alles seinen Grund… nimmst dem DOM die ganzen EdgeCases weg ist er auch flotter :D
franky #
Geschrieben am 4.03.2015 um 11:39
Muss nicht unbedingt sein, kommt wirklich fast zu 100% auf die Implementierung an. Z.B. ob man seine Properties nur beim Aufruf berechnet oder aktiv updated, etc. Triviales Beispiel:
Impl1 {
this.bla
this.dependingOnBla = function() { return /*some expensive calc*/ }
this.editBla = function(input) {
bla = input;
}
}
vs
Impl2 {
this.bla
this.precomputed;
this.dependingOnBla = function() { return precomputed; }
this.editBla = function(input) {
bla = input;
precomuted = /*some expensive calc*/;
}
}
Je nach use case ist die eine oder die andere Implementierung langsamer. Und wenn man das natürlich mit noch X anderen properties durchspielt ….
Und da spielt dann natürlich hinein dass man beim fake-dom genau die usage kennt und genau auf diese usage hin optimieren kann (z.B. ich weiß ich hab ein Verhältnis von 100:1 für Lese-Operationen -> wird wohl eine Lösung sein die die Berechnung beim Setzen und nicht beim Auslesen macht).
Schepp #
Geschrieben am 19.03.2015 um 11:33
Der DOM ist aber auch deswegen langsam, weil er in einer vollkommen anderen Umgebung lebt als unser JavaScript. Deshalb muss jede Kommunikation mit dem DOM zu bestimmten Kosten übersetzt werden. Deshalb gab es von Anfang an bei Blink die Idee, das DOM aus der klassischen C++-Umgebung in eine JavaScript-Umgebung zu verlegen:
Google Blink (new WebKit fork): Meaning of “Moving DOM into Javascript”?
RSS-Feed zu diesem Beitrag
Kommentare sind für diesen Beitrag geschlossen.