HTML Was haltet ihr von diesem Code?

@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 :D.
 
  • Gefällt mir
Reaktionen: kim88 und askling
Zip war einfach ein quick and dirty Vergleich. Ist klar das es nicht up to date ist. :-) Es geht hier aktuell um ca. 14 mb (eigener) Client Source-Code vor dem Build. Da nimmt man die Prozente gerne mit (auch wenn natürlich zusätzlich dynamisch geladen wird), vor allem um Traffic zu minimieren.

Natürlich ist nicht alles optimiert was geht, das dürften nur sehr sehr wenige Projekte in der Praxis erreichen. Aber klar, Performance Analysen werden gemacht und Bottlenecks optimiert.

Und danke für die Klarstellung mit Webassembly, ich war mir nicht sicher, ob wasm (Bytcode) an sich meinst, oder vor allem die Möglichkeit andere Sprachen zu nutzen. Beides ist dabei natürlich super.

Ich glaube am Ende sind haben wir gar keine groß andere Meinung, kommen nur von unterschiedlichen Ausgangspunkten.

Mein Ausgangspunkt war einfach einem Anfänger die Sorgen zu nehmen das es sich auf den Performance negativ auswirkt, wenn man in einer (Hoch-)Sprache zu lange Namen etc. benutzt. Genauso wie es nicht sinnvoll ist sich Kommentare etc. zu verkneifen um Traffic zu sparen.

Wenn relevant, dann optimiert man das mit Tools - eins davon kann Minification sein - nie im Code wo es um Lesbar- und Verständlichkeit geht, gerade wenn viele daran arbeiten.

Um mehr ging es eigentlich nicht. Das Minification, rein um Source selbst zu verkleinern, oft nicht sinnvoll ist habe ich nicht bestritten und du hast es auch klar gezeigt. Es ist einfach ein Tool. Mehr nicht. Einen Nachteil bei ausgeliefertem minifiziertem Code kann ich dabei trotzdem nicht sehen.

Manchmal ist es aber eine low hanging fruit die man gerne für praktisch keinen Aufwand (ein Schalter im deploy Script) mit nimmt.

Design und Implementierung ist mit Abstand das wichtigste, da stimme ich dir völlig zu.
 
Zuletzt bearbeitet von einem Moderator:
Zurück
Oben