Piktogramm
Admiral
- Registriert
- Okt. 2008
- Beiträge
- 9.192
@new Account()
Wenn ich schreibe, dass Kommentare entfernt werden SOLLEN und nicht müssen, dann solltest du da auch kein Muss draus machen. Ich bin da recht pedantisch was RFC2119 angeht
https://tools.ietf.org/html/rfc2119
oder im Deutschen: https://de.wikipedia.org/wiki/Muss-,_Soll-_und_Kann-Vorschrift
@askling
Das es riesige Webprojekte gibt und das es da sehr schnell sehr komplex wird, gehe ich ja mit. Das mein Beispiel von einer winzigen Seite stammt auch, wobei ich befürchte, dass große Seiten einfach als Beispiel zu komplex sind um aufzuzeigen was ich meine[1]. Vergleichen wir es mit deinem Projekt. Die 6kB Einsparung durch minification erreichst du bei einer Webseite mit welchem Gesamtumfang? Zudem, wie groß ist der Performancezugewinn beim Clienten, wenn man da mal die Entwicklertools der Browser drauf wirft? Sind alle anderen Ressourcen optimiert worden etc. pp.?
Minifiacation als Optimierung vorzuschlagen ist halt so ein Ding. Wenn da Entwickler mal ne simple ABC-Analyse fahren würden (https://de.wikipedia.org/wiki/ABC-Analyse), schafft auf die ganze Webanwendung betrachtet Minification es meist nicht Ansatzweise zur Kategorie B.
Ansonsten, zip? Also Deflate, nutze doch bitte gzip oder besser brotli! Wer Deflate nutzt verschenkt Performance die aller Voraussicht nach mit minification nicht zu kompensieren ist
Was Webassembly angeht, das erspart dem Clienten allerhand Rechenzeit anstatt JS in Bytecode zu wandeln direkt Bytecode zu bekommen. Zudem sollten gescheite Compiler auch gleich TreeShaking betreiben und nicht genutzte Funktionen sowie Variablen entsorgen. Richtig eingesetzt, lässt sich ordentlich Performance gewinnen.
Und bei den Kommentaren, der Hauptgrund die zu entfernen ist ein Sicherheitsding. Die Anzahl der Seiten wo irgendwas ausgeliefert ist, wo TODO: oder BUG: enthalten sind, sind erschreckend hoch. Zudem sollten Kommentare ja die Information enthalten, wieso der Code macht was er macht. Diese Begründung ist für das Reverseengeneering deutlich wertvoller als menschenlesbare Variablennamen[2]. Mir fällt wenig ein, wo Kommentare in einem Übermaß enthalten sind, dass es ernsthaft die Ladezeit oder gar die Laufzeit vom JS-Compiler verlängert.
Außer das Negativbeispiel Nextcloud wo jedes Plugin welches JS läd den gesamten Copyrighthinweis mitbringt und man so mehrmals GPL, APGL, BSD, MIT bei jedem Sideload ausliefert. Wobei da auch hinzu kommt, dass die .js-Files oft nicht vom Browser gecached werden, da die cachepolicy für den Allerwertesten ist. Wobei die Cachingpolicy schwerer wirkt.
[1] Design und Implemtierung haben in der Regel einen viel größeren Einfluss als Minification.
[2] Außer jemand verwendet sowas wie "masterpwd" als Variablennamen und gibt der Variable den entsprechenden Inhalt .
Wenn ich schreibe, dass Kommentare entfernt werden SOLLEN und nicht müssen, dann solltest du da auch kein Muss draus machen. Ich bin da recht pedantisch was RFC2119 angeht
https://tools.ietf.org/html/rfc2119
oder im Deutschen: https://de.wikipedia.org/wiki/Muss-,_Soll-_und_Kann-Vorschrift
@askling
Das es riesige Webprojekte gibt und das es da sehr schnell sehr komplex wird, gehe ich ja mit. Das mein Beispiel von einer winzigen Seite stammt auch, wobei ich befürchte, dass große Seiten einfach als Beispiel zu komplex sind um aufzuzeigen was ich meine[1]. Vergleichen wir es mit deinem Projekt. Die 6kB Einsparung durch minification erreichst du bei einer Webseite mit welchem Gesamtumfang? Zudem, wie groß ist der Performancezugewinn beim Clienten, wenn man da mal die Entwicklertools der Browser drauf wirft? Sind alle anderen Ressourcen optimiert worden etc. pp.?
Minifiacation als Optimierung vorzuschlagen ist halt so ein Ding. Wenn da Entwickler mal ne simple ABC-Analyse fahren würden (https://de.wikipedia.org/wiki/ABC-Analyse), schafft auf die ganze Webanwendung betrachtet Minification es meist nicht Ansatzweise zur Kategorie B.
Ansonsten, zip? Also Deflate, nutze doch bitte gzip oder besser brotli! Wer Deflate nutzt verschenkt Performance die aller Voraussicht nach mit minification nicht zu kompensieren ist
Was Webassembly angeht, das erspart dem Clienten allerhand Rechenzeit anstatt JS in Bytecode zu wandeln direkt Bytecode zu bekommen. Zudem sollten gescheite Compiler auch gleich TreeShaking betreiben und nicht genutzte Funktionen sowie Variablen entsorgen. Richtig eingesetzt, lässt sich ordentlich Performance gewinnen.
Und bei den Kommentaren, der Hauptgrund die zu entfernen ist ein Sicherheitsding. Die Anzahl der Seiten wo irgendwas ausgeliefert ist, wo TODO: oder BUG: enthalten sind, sind erschreckend hoch. Zudem sollten Kommentare ja die Information enthalten, wieso der Code macht was er macht. Diese Begründung ist für das Reverseengeneering deutlich wertvoller als menschenlesbare Variablennamen[2]. Mir fällt wenig ein, wo Kommentare in einem Übermaß enthalten sind, dass es ernsthaft die Ladezeit oder gar die Laufzeit vom JS-Compiler verlängert.
Außer das Negativbeispiel Nextcloud wo jedes Plugin welches JS läd den gesamten Copyrighthinweis mitbringt und man so mehrmals GPL, APGL, BSD, MIT bei jedem Sideload ausliefert. Wobei da auch hinzu kommt, dass die .js-Files oft nicht vom Browser gecached werden, da die cachepolicy für den Allerwertesten ist. Wobei die Cachingpolicy schwerer wirkt.
[1] Design und Implemtierung haben in der Regel einen viel größeren Einfluss als Minification.
[2] Außer jemand verwendet sowas wie "masterpwd" als Variablennamen und gibt der Variable den entsprechenden Inhalt .