WebOS hat aber auch gezeigt, wie wichtig das JS Framework ist. Mojo und Enyo waren beide nicht gerade schnell.
Eine WebOS Anwendung brauchte oft leicht 1-3 Sekunden zum starten, deutlich länger als z.B. eine normale iOS oder Android App. Dabei lag es eigentlich nicht an WebOS selbst, schrieb man eine App ohne Mojo und Enyo, direkt in C++ oder HTML/JS aber ohne die Frameworks, starteten die Apps ebenfalls fast sofort.
Man kann mit JS viel falsch machen, und oft wird es auch falsch gemacht.
Allerdings ist hier nicht JS das Performance-Problem. Die Ausführung des JS-Codes selbst ich hochoptimiert - sei es nun Spider/TraceMonkey oder V8 Engine, die zum Einsatz kommt.
Das Performance-Problem sind die DOM-Operationen. Und hier sind die Frameworks schuld. Eine kleine Methode wie show() sorgt intern z.B. für eine Animation (fadeIn). Das geht aber nicht so einfach. Dafür muss man einen CSS-Wert im Intervall anpassen (opacity)
Folglich kommt dann so etwas dabei raus:
var i=0 domElRef = document.getElementById('whatEverEl'), fading = setInterval(function() {
// Alle 100 ms CSS-Wert anpassen domElRef.style.opacity = domElRef.style.opacity += 0.1; i++;
if (i === 10) { clearInterval(fading); }
}, 100);
Damit fadet dann ein DOM-Element innerhalb einer Sekunde ein/aus.
Tja, das sind aber 10x redraw EINES DOM-Elements. Bei jedem redraw muss die Rendering Engine erstmal schauen: - welche Breiche zu redrawen sind - wie die sichtbaren und unsichtbaren Elemente vor/hinter dem zu fadenen Element sich verhalten (zIndex) etc. pp.
Außerdem geschehen bei JS/DOM-Interaktionen eine Menge String/Number-Datentypcastings.
Das alles nur bei EINEM DOM-Element.
Eine App besteht aus HUNDERTEN.
Macht im Gro dann: Ein Tab per Finger auf einem Button erzeugt bei einem nicht optimierten Framework gern mal 100 * 100 redraw Operationen pro Sekunde. (wenn es dumm läuft und das Framework anstatt einem Parent-DOM-Element alle Childs fadet)
Und dann heißt es, JS sei langsam. Das ist unfug. Die Implementierung ist of Dumm und das Rendering der Browser ist das eigl. Bottleneck. Zurückzuführen auf schlechte Kenntnisse der Entwickler.
Man kann mit teilweise kleinsten Änderungen richtig träge JS-Anwendungen in extem schnelle Anwendungen umwandeln. Faktor 10 - 50 schneller ist oft eine Frage weniger Entwicklertage.
Ich spreche aus der Praxis. Bin als Entwickler / Berater unterwegs, hab nen Buch geschrieben (O'Reilly) etc. pp. Leider wird oft bei JS in Fragen Performance der gleiche Fehler gemacht, wie bei PHP in Fragen Sicherheit und schlechter Code. Die Sprache/Technologie mag Tendenzen aufzeigen. Zum Schluss kommt es aber _immer_ auf das Entwickler-Team und das Management an.
btw: Warum ich hier Management erwähne. Es gibt durchaus Entwickler, die es gut könnten aber vom Management aus Gewinnzielen heraus zu "Massive Feature Producing" gezwungen werden.
Also bitte auch keine Schimpftiraden auf die vielen schlechten Entwickler. Klar gibt's die auch. Aber im großen und ganzen sind es - zumindest in der Wirtschaft - eher die Managemet-Entscheidungen die schlechten Code prodzuieren. Wie gesagt, z.B. auch wenn man sich jede Woche umentscheidet, dass man jetzt doch lieber etwas anders haben möchte. Da braucht es nämlich meist Architekturänderungen. Für Refactoring gibt man den Entwicklern aber dann keine Zeit! Und beschwert sich später über die schlechten Entwickler, die so viele Bugs prodzuieren oder den Code nicht dokumentieren...
Ich bin ja ein Fan von HTML5-basierenden User Experiences. WebOS hat mir schon gefallen.
WebOS hat aber auch gezeigt, wie wichtig das JS Framework ist. Mojo und Enyo waren beide nicht gerade schnell.
Eine WebOS Anwendung brauchte oft leicht 1-3 Sekunden zum starten, deutlich länger als z.B. eine normale iOS oder Android App.
Dabei lag es eigentlich nicht an WebOS selbst, schrieb man eine App ohne Mojo und Enyo, direkt in C++ oder HTML/JS aber ohne die Frameworks, starteten die Apps ebenfalls fast sofort.
Man kann mit JS viel falsch machen, und oft wird es auch falsch gemacht.
Allerdings ist hier nicht JS das Performance-Problem. Die Ausführung des JS-Codes selbst ich hochoptimiert - sei es nun Spider/TraceMonkey oder V8 Engine, die zum Einsatz kommt.
Das Performance-Problem sind die DOM-Operationen. Und hier sind die Frameworks schuld. Eine kleine Methode wie show() sorgt intern z.B. für eine Animation (fadeIn). Das geht aber nicht so einfach. Dafür muss man einen CSS-Wert im Intervall anpassen (opacity)
Folglich kommt dann so etwas dabei raus:
var i=0
domElRef = document.getElementById('whatEverEl'),
fading = setInterval(function() {
// Alle 100 ms CSS-Wert anpassen
domElRef.style.opacity = domElRef.style.opacity += 0.1;
i++;
if (i === 10) {
clearInterval(fading);
}
}, 100);
Damit fadet dann ein DOM-Element innerhalb einer Sekunde ein/aus.
Tja, das sind aber 10x redraw EINES DOM-Elements. Bei jedem redraw muss die Rendering Engine erstmal schauen:
- welche Breiche zu redrawen sind
- wie die sichtbaren und unsichtbaren Elemente vor/hinter dem zu fadenen Element sich verhalten (zIndex)
etc. pp.
Außerdem geschehen bei JS/DOM-Interaktionen eine Menge String/Number-Datentypcastings.
Das alles nur bei EINEM DOM-Element.
Eine App besteht aus HUNDERTEN.
Macht im Gro dann:
Ein Tab per Finger auf einem Button erzeugt bei einem nicht optimierten Framework gern mal
100 * 100 redraw Operationen pro Sekunde. (wenn es dumm läuft und das Framework anstatt einem Parent-DOM-Element alle Childs fadet)
Und dann heißt es, JS sei langsam. Das ist unfug. Die Implementierung ist of Dumm und das Rendering der Browser ist das eigl. Bottleneck. Zurückzuführen auf schlechte Kenntnisse der Entwickler.
Man kann mit teilweise kleinsten Änderungen richtig träge JS-Anwendungen in extem schnelle Anwendungen umwandeln. Faktor 10 - 50 schneller ist oft eine Frage weniger Entwicklertage.
Ich spreche aus der Praxis. Bin als Entwickler / Berater unterwegs, hab nen Buch geschrieben (O'Reilly) etc. pp.
Leider wird oft bei JS in Fragen Performance der gleiche Fehler gemacht, wie bei PHP in Fragen Sicherheit und schlechter Code. Die Sprache/Technologie mag Tendenzen aufzeigen. Zum Schluss kommt es aber _immer_ auf das Entwickler-Team und das Management an.
btw: Warum ich hier Management erwähne. Es gibt durchaus Entwickler, die es gut könnten aber vom Management aus Gewinnzielen heraus zu "Massive Feature Producing" gezwungen werden.
Also bitte auch keine Schimpftiraden auf die vielen schlechten Entwickler. Klar gibt's die auch. Aber im großen und ganzen sind es - zumindest in der Wirtschaft - eher die Managemet-Entscheidungen die schlechten Code prodzuieren. Wie gesagt, z.B. auch wenn man sich jede Woche umentscheidet, dass man jetzt doch lieber etwas anders haben möchte. Da braucht es nämlich meist Architekturänderungen. Für Refactoring gibt man den Entwicklern aber dann keine Zeit! Und beschwert sich später über die schlechten Entwickler, die so viele Bugs prodzuieren oder den Code nicht dokumentieren...
...das musste mal raus
Ich finde, ein sachliches "Die Bindings/Das Hosting Environment von JavaScript sind oft scheiße." hätte genügt.
SCNR
Lässt sich dies hier alles durch schlechtes Management erklären?
http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/
.... User Experiences.
Ja ja, schon recht.
Hast wohl in Deinem Berufsleben noch nicht genug PowerPoint Bullshit Bingo über Dich ergehen lassen müssen ;-)
(wenigstens hab' ich den Graugrinser diesmal nicht vergessen.)