HTML Was haltet ihr von diesem Code?

[Exterior]

50kb sind im Datentransfer zB. aber schon ziemlich viel, der Download braucht bei mr ungefähr 10Sekunden Upload meist ein Timeout bei der Größe ^^

Gehst du noch mit einem 56K-Modem ins Internet? O_o 10 Sekunden für 50 kB Daten-Download wäre ja mal extrem heftig. Oder verwechselst du da was?

JQuery halte ich heute für absolut kein muss mehr

"Muss" nicht, auf keinen Fall. Aber ich finde es eben schon ziemlich bequem, z. B. alle Objekte mit einem Aufruf auszublenden, statt mit einer Schleife arbeiten zu müssen.
Wobei ich sagen muss, dass ich durch meine viele Arbeit mit jQuery (wird eben auf Arbeit auch eingesetzt) auch wenig geschaut habe, wie sich Vanilla JS entwickelt hat. das "querySelectorAll" war mir zum Beispiel neu und ich habe gerade mal geschaut und gesehen, dass Vanilla inzwischen auch nativ eine foreach-Funktion für Arrays hat. Wusste ich noch gar nicht, weil ich durch die Arbeit seit 2012 oder so durchgängig mit jQuery arbeite. Sehr schön zu sehen, dass sich das so sinnvoll weiterentwickelt

Edit:
Und ich vertrete normalerweise auch die Einstellung, dass man erstmal die Grundlagen lernen sollte und dann mit Plugins und zusätzlichen Libs anfängt. Habe schon viele Azubis gesehen, die einfach zig verschiedene Libs zusammengekleistert hatten und dann gar nicht wussten, wo das Vanilla aufhört und die Funktionalität der Bibliotheken beginnt.

Also @Techniktype - askling hat recht, erstmal die Basics lernen. Wollte nur mal zeigen, was möglich wäre, aber anscheinend ist man heutzutage auch mit Vanilla ganz gut aufgestellt

 

[Techniktype]

Gehst du noch mit einem 56K-Modem ins Internet? O_o 10 Sekunden für 50 kB Daten-Download wäre ja mal extrem heftig. Oder verwechselst du da was?


"Muss" nicht, auf keinen Fall. Aber ich finde es eben schon ziemlich bequem, z. B. alle Objekte mit einem Aufruf auszublenden, statt mit einer Schleife arbeiten zu müssen.
Wobei ich sagen muss, dass ich durch meine viele Arbeit mit jQuery (wird eben auf Arbeit auch eingesetzt) auch wenig geschaut habe, wie sich Vanilla JS entwickelt hat. das "querySelectorAll" war mir zum Beispiel neu und ich habe gerade mal geschaut und gesehen, dass Vanilla inzwischen auch nativ eine foreach-Funktion für Arrays hat. Wusste ich noch gar nicht, weil ich durch die Arbeit seit 2012 oder so durchgängig mit jQuery arbeite. Sehr schön zu sehen, dass sich das so sinnvoll weiterentwickelt

Edit:
Und ich vertrete normalerweise auch die Einstellung, dass man erstmal die Grundlagen lernen sollte und dann mit Plugins und zusätzlichen Libs anfängt. Habe schon viele Azubis gesehen, die einfach zig verschiedene Libs zusammengekleistert hatten und dann gar nicht wussten, wo das Vanilla aufhört und die Funktionalität der Bibliotheken beginnt.

Also @Techniktype - askling hat recht, erstmal die Basics lernen. Wollte nur mal zeigen, was möglich wäre, aber anscheinend ist man heutzutage auch mit Vanilla ganz gut aufgestellt

Wie meinst du das erstmal die basics lernen? Ich arbeite mit Javascript "zwischendurch" über ein paar Jahre hinweg Naja vllt bin ich nicht gut aber ich wäre es gern

Und von Plugins nehme ich lieber Abstand. Das meiste kann ich nicht gebrauchen^^

Denkt ihr es ist noch zeitgemäß die Seite so zu programmieren das sie ohne Javascript voll funktionsfähig ist? Weil ja manche ihr Javascript deaktivieren.

Wie geht das eigentlich das man mit Javascript Datenbankverbindungen aufbaut? Verstehe ich das falsch oder würde der Client dann nicht alles sehen?

Ergänzung (25. September 2020)

spontan, das 'change' event sollte eigentlich reichen. das wird doch auch beim tippen gefeuert, oder was klappt damit nicht?

Das wird erst dann gefeuert wenn man den <Input> verlässt, was so ziemlich für alles wo ich etwas ähnliches nutze unpraktisch ist Ich bräuchte etwas was beim tippen gefeuert wird aber auch nicht zu oft

Ergänzung (25. September 2020)

Und naja nein, ich habe Internet über eine SIM-karte im Handy

 

[Exterior]

Wie meinst du das erstmal die basics lernen?

Dass man eben erstmal mit JS an sich umgehen lernt, bevor man sich mit den vielen JS-Bibliotheken, etwas zusammen zimmert, das man dann nicht versteht.

Denkt ihr es ist noch zeitgemäß die Seite so zu programmieren das sie ohne Javascript voll funktionsfähig ist? Weil ja manche ihr Javascript deaktivieren.

Kommt halt voll drauf an, was du mit deiner Seite so machen und erreichen möchtest. Man kann das machen, aber bei einigen Dingen muss man dann eben Abstriche machen.

Wie geht das eigentlich das man mit Javascript Datenbankverbindungen aufbaut?

Gar nicht, Javascript kann das nicht. Was du machen kannst, wäre ein Ajax-Request an ein Server-Script (PHP, Perl, Ruby, whatever), welches du mit Parametern fütterst. Das Script kann dann die Datenbank-Verbindung machen und auf dem Server die ganze Logik abhandeln und liefert dir dann eine Antwort ans Javascript zurück.

 

[Piktogramm]

Du meinst MySQL oder externe .html oder .txt Dateien?
Wie meinst du das man sollte es nicht beim Clienten verarbeiten Javascript anfragen an eine Datenbank, wie Ajax?

[...] jQuery
Ich weiß ehrlich gesagt nichtmal genau wozu es gut ist außer vereinfachter Code?

Daten sollte man (wenn sinnvoll) in Json oder XML Format ablegen. Das sind Textformate und im Großen und Ganzen ist es egal, welche Endung dann die Datei hat. Für Json und XML gibt es in Vanilla JavaScript und in den gängigen Bibliotheken sehr leistungsfähige Parser und das Handling ist vergleichsweise simpel.
Ein weiterer Vorteil: Es ist gängige Praxis und "jeder" versteht ohne größeren Aufwand was der Quelltext macht. Selbst wenn du nur allein an Software schreibst hilft es, den eigenen Code nach ein paar Wochen Pause selbst wieder zu verstehen

Datenbanken: Mit Datenbanken meine ich Datenbanken. MySQL wäre dabei mit das Letzte was ich wählen würde. Je nach Umfang wäre es eher Sqlite, Postgres oder MariaDB mit Präferenz für die ersten Beiden.

Es gibt aber glaube ich auch Tools die Variablen, Klassen und Funktionsnamen verkürzen. Mit Hand habe ich das mal versucht, lieber nicht nachmachen 😆 sehr Fehleranfällig und mühselig. Außerdem wird man um den Verstand gebracht wenn man nur noch a1, bf, c0d usw. sieht 😂

wenn es dir um kleine größe bei der übertragung geht, vom code der auf dem server lieg wo leute drauf zugreifen sollen, dann jagt man den eigentlich eh durch 'minifier' wenn man an der stelle optimieren möchte.

Minifier sind die Pest und vor allem unnötig.
Was die Menge der Datenübertragung angeht, so komprimieren die gängigen Webserver (für Apache, Nginx bin ich mir sicher, bei NodeJS erwarte ich es) Dateien vor der Übertagung sowieso. Nach der Kompression sollten minified JS und menschlich lesbares JS nahezu gleich groß sein. Einzig Kommentare sollten aus dem JS entfernt werden. Ähnliches gilt für HTML, CSS und alle anderen Textformate.
Auch für die Performance beim Clienten macht es keinen Unterschied. Das Javascript zu parsen ist auf modernen JS Engines das aller kleinste Problem.

Wobei CSS eine Ausnahme hat, wenn man das CSS verkleinen kann indem man sich überschneidende Eigenschaften entfernen kann, sollte man das tun. Dann hat es die Renderengine vom Browser etwas leichter. Beispiel: Anstatt jedem Block margin: 0.3em und color: 0xff1337 zu setzen sowas global anwenden. (Das ist aber ein Optimierungsschritt wenn man die letzte Millisekunde Rendertime optimieren will)

Denkt ihr es ist noch zeitgemäß die Seite so zu programmieren das sie ohne Javascript voll funktionsfähig ist? Weil ja manche ihr Javascript deaktivieren.
Wie geht das eigentlich das man mit Javascript Datenbankverbindungen aufbaut? Verstehe ich das falsch oder würde der Client dann nicht alles sehen?

Grundlegend:
Eine Seite sollte ohne JS beim Clienten funktionieren können, JS kann die Funktionalität jedoch deutlich erweitern. Ein großes Problem ist, dass viele Ressourcen für Anfänger dies nicht beachten und Funktionalität nachbauen, die die Browser bzw. HTML5 sowieso bereits mitbringen. Hier lohnt es immer nachzuschauen ob man sich das Leben nicht einfacher machen kann, wenn man nicht einfach aktuelle HTML Features nutzt. Beispiel: Lazyloading von Bildern/Videos. Das war lang nur mit JS möglich, ist mittlerweile aber Bestandteil von HTML und wird von allen relevanten Browsern unterstützt.

Javascript kann mit Datenbanken kommunizieren. Dazu muss es aber mit NodeJS laufen. Im Browser beim Clienten geht das nicht. Da muss man sich selbst eine Schnittstelle bauen oder bereits bestehende Bibliotheken nutzen. Eine wichtige Grundlage ist dabei sowieso, dass Clienten NIE direkten Zugriff auf die Datenbank bekommen sollten. Entsprechend sollten Datenbanken NIE direkt aus dem Internet erreichbar sein und jede Anwendung die berechtigt auf die Datenbank zugreift MUSS gegen SQL-Injection gehärtet sein. Selbst wenn du lernst, direkt nach dem ersten erfolgreichen Zugriff auf eine Datenbank durch deine Entwicklung, mach dich direkt daran das Problem von SQL-Injections zu verstehen und diesen aller ersten zugriff dagegen zu sichern. Ab da an nimmst du nur noch die sichere Variante!

 

[new Account()]

Minifier sind die Pest und vor allem unnötig.
Was die Menge der Datenübertragung angeht, so komprimieren die gängigen Webserver (für Apache, Nginx bin ich mir sicher, bei NodeJS erwarte ich es) Dateien vor der Übertagung sowieso.

Was ist da bitte die Pest? Begründung?

Nach der Kompression sollten minified JS und menschlich lesbares JS nahezu gleich groß sein.

Nahezu gleich groß: naja
https://stackoverflow.com/questions/807119/gzip-versus-minify#:~:text=Reasoning:,other hand, minification is lossy.
Das extra nehm ich gerne mit. Kostet nix

Auch für die Performance beim Clienten macht es keinen Unterschied. Das Javascript zu parsen ist auf modernen JS Engines das aller kleinste Problem.

Gemacht werden muss es trotzdem. Weniger Arbeit zum Parsen schadet erstmal nicht.

Treeshaking kann man sich auch mal anschauen

 

[Piktogramm]

@new Account()
Pest: Weil das JS unlesbar wird bei Vorteilen, die wenn überhaupt im Rauschen untergehen. Allenfalls zeigt es auf, dass da Personen ihr Handwerk nicht verstehen und/oder mit einem Wissensstand agieren der deutlich über 10Jahre alt ist..

Größe: Ok in dem Stackoverflow Thread wird gzip -9 genutzt. Kann man machen, versaut sich aber die Performance, da dann die Clienten recht viel CPU-Zeit aufs Entpacken werfen müssen. Tendenziell mehr als die Zeit die man bei der Übertragung gewinnt[1]. Wer -9 beim Server einsetzt ohne die komprimierte Datei zu cachen erlebt auch sein blaues Wunder.
Auch sollte man nicht vergessen, um welche Datenmenge es an dieser Stelle geht. Da kann man ein paar bis hundert kB Daten schinden. Mit jeder nicht optimierten Grafik, jeder eingebundenen externen Ressource, der Nichtnutzung von HTTP2 bzw. HTTP3 geht mehr verloren als durch nicht minimiertes JS.
Wo ich mitgehe ist Treeshaking um zu vermeiden, dass man Kram ausliefert, der gar nicht benötigt wird. Da wird man je nach Seite hunderte kB bis MB los, die nicht komprimiert, nicht übertragen und nicht geparst werden müssen.
Das die Parser etwas weniger zu tun haben, das stimmt in der Theorie. In der Praxis ist das Parsen einzelner Zeichen nichts was CPUs herausfordert. Alles was ernsthaft Rechenzeit benötigt kommt nach dem Parsen des Dokuments.

Datensatz ist selector.js von https://github.com/jquery/jquery

grep auf "matches"

$ time grep "matches" selector.js >/dev/null

real    0m0,004s
user    0m0,001s
sys     0m0,003s

Der Parser braucht zum starten und Dateiaufruf (Datei ist im Ram gecached) 0,003 Sekunden. Zum Parsen der ~46kB großen Datei an sich gehen ganze 0,001s drauf.

selector.js durch https://javascript-minifier.com/ optmiert, erneut grep

$ time grep "matches" selector_mini.js >/dev/null

real    0m0,004s
user    0m0,001s
sys     0m0,003s

Voll die relevante Optimierung
Test erfolgt auf einem AMD Athlon 5150 (4x 1,6GHz), der langsamer ist als der Unterbau der meisten Mittelklassesmartphones.

Ok, den Test kann man auch im Browser für reale Webanwendungen durchführen und sich den Flamechart anschauen. Da schwanken die Ergebnisse zwischen mehreren Läufen aber weit stärker als alles was sich an der Stelle optimieren lässt.

Insofern, spart euch minifier! Macht ne Leistungsanalyse was auf eurer Seite langsam läd und wo die JS Engine vom Browser Zeit vergeudet, aber verschwendet eure Zeit nicht mit Minifiern!
Treeshaking und die Reduktion der Komplexität von CSS ist in der Regel in Ordnung.

Gemacht werden muss es trotzdem.

Gemacht werden MUSS:
Funktionalität, Sicherheit, Barrierefreiheit.

[1] Selbst bei 1Mbit/s Bandbreite macht jedes 1kB nur 1/128s aus (~8ms). Moderne Kompression ist effizient, aber auch nicht kostenlos! Dabei sind die 1Mbit/s selbst im Hinterland Deutschlands mittlerweile recht pessimistisch.

Ergänzung (25. September 2020)

So weitere Spielereien,
Kompression: selector.js vs. selector_mini.js

Die komprimierte Datei wird am Schluss immer gelöscht, das Löschen wird nicht mit gemessen

$ time pigz -k -2 selector.js && rm selector.js.gz 

real    0m0,008s
user    0m0,004s
sys     0m0,004s
$ time pigz -k -2 selector.js && rm selector.js.gz 

real    0m0,005s
user    0m0,006s
sys     0m0,000s
$ time pigz -k -2 selector.js && rm selector.js.gz 

real    0m0,007s
user    0m0,003s
sys     0m0,004s
$ time pigz -k -2 selector.js && rm selector.js.gz 

real    0m0,007s
user    0m0,007s
sys     0m0,000s
$ time pigz -k -2 selector.js && rm selector.js.gz 

real    0m0,003s
user    0m0,000s
sys     0m0,003s
$ time pigz -k -2 selector.js && rm selector.js.gz 

real    0m0,006s
user    0m0,006s
sys     0m0,001s

minified

$ time pigz -k -2 selector_mini.js && rm selector_mini.js.gz 

real    0m0,004s
user    0m0,000s
sys     0m0,005s
$ time pigz -k -2 selector_mini.js && rm selector_mini.js.gz 

real    0m0,005s
user    0m0,005s
sys     0m0,000s
$ time pigz -k -2 selector_mini.js && rm selector_mini.js.gz 

real    0m0,003s
user    0m0,000s
sys     0m0,003s
$ time pigz -k -2 selector_mini.js && rm selector_mini.js.gz 

real    0m0,005s
user    0m0,001s
sys     0m0,005s
$ time pigz -k -2 selector_mini.js && rm selector_mini.js.gz 

real    0m0,005s
user    0m0,001s
sys     0m0,005s
$ time pigz -k -2 selector_mini.js && rm selector_mini.js.gz 

real    0m0,006s
user    0m0,004s
sys     0m0,003s

Die Unterschiede sind nichtig und kleiner als das Rauschen. Beim Test mit dem Parser oben müsste man auch häufiger testen, da gibt es eigentlich ein ähnliches Bild was die Streuung der Werte angeht. Das die Streuung noch viel größer ist, wenn so ein System mehr zu tun hat als auf meine SSH Session zu warten sollte klar sein.

 

[new Account()]

@new Account()
Pest: Weil das JS unlesbar wird bei Vorteilen, die wenn überhaupt im Rauschen untergehen. Allenfalls zeigt es auf, dass da Personen ihr Handwerk nicht verstehen und/oder mit einem Wissensstand agieren der deutlich über 10Jahre alt ist..

Manchmal ist das unlesbar werden sogar erwünscht.
Das ausgelieferte JS braucht auch wirklich keiner lesen - von daher ist dein einziger Einwand irrelevant.

Allenfalls zeigt es auf, dass da Personen ihr Handwerk nicht verstehen und/oder mit einem Wissensstand agieren der deutlich über 10Jahre alt ist..

Da müssen die Angular Entwickler ja ziemlich in der Zeit stehen geblieben sein 😁

Größe: Ok in dem Stackoverflow Thread wird gzip -9 genutzt. Kann man machen, versaut sich aber die Performance, da dann die Clienten recht viel CPU-Zeit aufs Entpacken werfen müssen.

Mit weniger Komprimierung wird der Unterschied nur größer.

Voll die relevante Optimierung

Weniger Arbeit zum Parsen schadet erstmal nicht.

Zumal grep und javascript parsing ja doch zwei komplett verschiedene Welten sind

[1] Selbst bei 1Mbit/s Bandbreite macht jedes 1kB nur 1/128s aus (~8ms). Moderne Kompression ist effizient, aber auch nicht kostenlos! Dabei sind die 1Mbit/s selbst im Hinterland Deutschlands mittlerweile recht pessimistisch.

Realistisch sind 32kbit/s in der Drosselung und/oder Edge

Wo ich mitgehe ist Treeshaking um zu vermeiden, dass man Kram ausliefert, der gar nicht benötigt wird.

Da kann man Variablen-Namen, Leerzeichen & Co genauso dazuzählen.

 

[Piktogramm]

"Unlesbarkeit ist erwünscht"
Das ist Ofuskation und ein Antipatern der Softwareentwicklung. Wer sich das JS in lesbar ansehen will zieht den Code durch entsprechende Entwicklungsumgebungen und hat gar kein Problem damit. Damit ist nichts gewonnen.

"einziger Einwand irrelevant"
Der Einwand ist nachwievor, minification bedeutet Aufwand für Entwickler. Dieser Aufwand ist in aller Regel nicht gerechtfertigt.

"Angular Entwickler hinter der Zeit"
Jain, der Quellcode von Angular ist vergleichsweise riesig, vor allem wenn man die Kommentare drinnen lässt (für das Entfernen dieser bin ich durchaus). Wenn ich eine Bibliothek anbieten würde, würde ich auch versuchen diese in einer Form anzubieten die die halbwegs gescheit läuft. Egal ob der Webserver und die Entwickler die die Bibliothek einbinden DAUs sind oder nicht.
Gescheite Entwicklungen die Angular nutzen werden ihren eigenen JS Code samt Angular durch einen Treeshaker laufen lassen und so tendenziell ohne minification ein besseres Ergebnis erhalten als Jene, die ohne Treeshaker das gesamte, minimierte Angular einbinden.
Ansonsten ist das "aber guck mal, die machen das auch" eine schlechte Idee. Wie überall auch halten sich in der IT viele Mythen und veraltetes Wissen. Minifiacation war vor Jahren der Hit, wurde durch die stetige Weiterentwicklung von Kompression, dem HTTP Protokoll und der JS Engines völlig überholt.

"weniger Kompression macht Unterschiede größer"
Da muss man schauen wie der Tradeoff zwischen Übertragungsdauer und CPU-Zeit bei Server und Client ausschaut ausschaut und ob es überhaupt lohnt an der Stelle zu optimieren. Wie gesagt, da kämpft man um >10ms Zeit. Da gibt es in der Regel andere Stellen, wo mehr Zeit flöten geht.

"Grep und JS Parser sind verschiedene Welten"
Nö, das Parsing läuft vergleichbar ab, erst das Interpretieren/Compilieren des geparsten Textes benötigt ernsthaft CPU-Zeit. Wobei es da dann wirklich egal, ob eine Variable "Knuddelpuff3000" lautet oder einfach "a", da es sowieso durch etwas Maschinenlesbares ersetzt wird.

"Realistisch sind 32kbit/s in der Drosselung und/oder Edge"
Bei der Bandbreite mit den entsprechenden Latenzen und dem zu erwartendem Packetloss muss man bereits beten, dass der TLS Handshake überhaupt klappt. Wer Clienten bedienen, wo diese Bandbreite ernsthaft relevant ist, sollte Seite grundsätzlich so aufbauen, dass möglichst gar kein JS und keine Medien ausgeliefert werden..

"Da kann man Variablen-Namen, Leerzeichen & Co genauso dazuzählen."
Das sind grundlegend verschiedene Dinge. Klassen, Methoden und funktionales JS müssen komplett durch den JS-Interpreter durchgeschleust werden. Das ist vom Aufwand her eine wirklich komplett andere Welt als beim initialem Parsen Füllzeichen zu verwerfen.
Ich empfehle dir mal diesen Artikel samt Video: https://v8.dev/blog/ignition-interpreter
Stand 2016 ist zwar auch schon wieder alt, aber es wird gut erklärt.

Wichtig ist u.a.

Füllzeichen werden beim Orangem Parser bereits ausgefiltert. Also sehr früh und vor allem sehr schnell (100MB/s bis xGB/s je nach CPU). Jede Klasse, jede Methode die mit ausgeliefert wird, aber nicht genutzt wird, muss diese Kette jedoch bis inkl. zum rotem Interpreter durchlaufen. Dabei sind die grünen Prozessschritte deutlich komplexer als der Parser.
Also ungenutzten Code ausliefern -> Bloat
Füllzeichen ausliefern -> Wayne

Edit: Das ist die vereinfachte Darstellung des Ablaufs eines Teils der V8 JS Engine. Das komplette Ding ist komplexer, es ändert aber nicht viel am Sachverhalt.

 

[new Account()]

"Unlesbarkeit ist erwünscht"
Das ist Ofuskation und ein Antipatern der Softwareentwicklung. Wer sich das JS in lesbar ansehen will zieht den Code durch entsprechende Entwicklungsumgebungen und hat gar kein Problem damit. Damit ist nichts gewonnen.

Warum sollte das ein Antipattern sein? Bin ich mal gespannt wie sich das negativ auswirken soll.
Ich möchte die IDE sehen, welche dann passende Variablennamen etc. dazudichtet 😉
Fazit: Definitiv was gewonnen.

"einziger Einwand irrelevant"
Der Einwand ist nachwievor, minification bedeutet Aufwand für Entwickler. Dieser Aufwand ist in aller Regel nicht gerechtfertigt.

Der Mehraufwand beschränkt sich i.d.R. auf "Buildscript um eine Zeile zu erweitern" oder nichts machen (vor allem, da das oft schon by default dabei ist, wenn man sowieso schon Kommentare etc. entfernt).

Gescheite Entwicklungen die Angular nutzen werden ihren eigenen JS Code samt Angular durch einen Treeshaker laufen lassen und so tendenziell ohne minification ein besseres Ergebnis erhalten als Jene, die ohne Treeshaker das gesamte, minimierte Angular einbinden.

Beides schließt sich nicht aus.
Am besten erst durch den Tree-Shaker, dann durch den Minifier.

Ansonsten ist das "aber guck mal, die machen das auch" eine schlechte Idee. Wie überall auch halten sich in der IT viele Mythen und veraltetes Wissen.

Ich weiß. Google ist ja dafür bekannt in der IT/Webentwicklung hinterherzuhinken.

Minifiacation war vor Jahren der Hit, wurde durch die stetige Weiterentwicklung von Kompression, dem HTTP Protokoll und der JS Engines völlig überholt.

Wie du gesehen hast, ist Kompression neben TreeShaking und Minifying lediglich ein weiterer Baustein. Beide machen unterschiedliche Dinge, und sparen daher beide.

Da muss man schauen wie der Tradeoff zwischen Übertragungsdauer und CPU-Zeit bei Server und Client ausschaut ausschaut und ob es überhaupt lohnt an der Stelle zu optimieren. Wie gesagt, da kämpft man um >10ms Zeit. Da gibt es in der Regel andere Stellen, wo mehr Zeit flöten geht.

The minified version of this sample code is 48% smaller. In some cases, minification can reduce file size by as much as 60%. For instance, there’s a 176 kb difference between the original and minified version of the JQuery JavaScript library.

https://www.imperva.com/learn/performance/minification/
Macht bei 32kbit/s 5,5 Sekunden aus.
Bei 64kbit/s 2,8 Sekunden. Beides sind übliche Drosselungsgeschwindigkeiten.
Wieviel sinds mit Kompression?

Bei der Bandbreite mit den entsprechenden Latenzen und dem zu erwartendem Packetloss muss man bereits beten, dass der TLS Handshake überhaupt klappt. Wer Clienten bedienen, wo diese Bandbreite ernsthaft relevant ist, sollte Seite grundsätzlich so aufbauen, dass möglichst gar kein JS und keine Medien ausgeliefert werden..

Mit ner Webseite/app bediene ich generell das ganze Internet und nicht nur Leute mit Breitband Internet. Die meisten sind mobil unterwegs. Damit macht man des veröffentlichte mit nahezu 0 Aufwand besser Zugreifbar und reduziert Frust bei den Usern.
Dass es ggf. wichtigere Stellschrauben gibt, rechtfertigt übrigens auch nicht, hier unnötig zu verschwenden.
Letztendlich beeinflusst es auch den PageRank bei Suchmaschinen.

Jede Klasse, jede Methode die mit ausgeliefert wird, aber nicht genutzt wird, muss diese Kette jedoch bis inkl. zum rotem Interpreter durchlaufen.

Hast du eventuell den Schritt "Dead Code Elimination" übseehen?

 

[Piktogramm]

Warum sollte das ein Antipattern sein? Bin ich mal gespannt wie sich das negativ auswirken soll.
Ich möchte die IDE sehen, welche dann passende Variablennamen etc. dazudichtet 😉
Fazit: Definitiv was gewonnen.

Ich bin in dem Umfeld Pentesting aktiv, so ein bisschen Obfuscation ist das was für Lacher und Witze in der Kaffeeküche sorgt[1]. Wenn irgendwer auch nur eine Minute auf sowas verschwendet hat anstatt auf sinnvolle Dinge, ist es Lächerlich. Wobei die Integration in die Buildautomatisierung eher länger dauert. In der Zeit wäre es klüger mal lieber noch einen Test zu schreiben oder den Bereicht vom letztem Pentest aufmerksamer zu lesen.
Das benennen von Variablen ist kein Ding. Die Namen der Variablen braucht ein Angreifer in der Regel nur für ein absolutes Minimum der Variablen. Wobei aus dem Inhalt der Variabel meist sowieso klar wird, welche Funktion die Dinger haben. Das Umbenennen der relevanten Variablen klappt dann auch im Browser (oder anderen Werkzeugen..)

[1] Der Posten "erhöhter Aufwand beim Testen" landet trotzdem auf der Rechnung

Beides schließt sich nicht aus.
Am besten erst durch den Tree-Shaker, dann durch den Minifier.

Tree Shaker bringen Performance, Minifier seit Jahren in der Regel nichts. 2 Minuten Yoga im Büro bringen für Qualität und Performance mehr als Minifier. Mach Yoga!

Wie du gesehen hast, ist Kompression neben TreeShaking und Minifying lediglich ein weiterer Baustein.

Wenn du schon bei Steinen bist. Irgendwann ist der Rohbau vom Haus fertig. Du kannst dann weiter Steine auf den Rohbau aufsetzen oder hinnein legen. Sinnvoller ist es aber mit dem Dachstuhl anzufangen, Fenster und Türen einzusetzen sowie sich um Gas, Wasser, Scheiße, Elektrik zu kümmern. Die Zusätzlichen Bausteine bringen dich nicht weiter

https://www.imperva.com/learn/performance/minification/
Macht bei 32kbit/s 5,5 Sekunden aus.

Ohne Kompression, ohne Vergleich zur Größe sonstiger Elemente der Webseite und mit ganz vielen Falschbehauptungen zur Funktion moderner JS Engines. Mal ein gescheiter Flamechart eines realen Webbrowser einer realen Seite zum Vergleich fehlt auch... Ansonsten, netter Werbeartikel, der verspricht, dass diese "total wichtige" Optimierung seitens des CDN Anbieters gleich mit erledigt wird.
Und vor allem, wenn 32kbit/s die Bandbreite des Zielpublikums ist, dann lass das Javascriptgerümpel ganz weg, sowie alle Bilder, Videos, Schriftarten etc. pp! In solchen Fällen sollte man sowas wie https://blog.fefe.de ausliefern (und im Gegensatz zu fefe HTTP2 nutzen!). Selbst mit GPRS ist DOM load da nach <3s fertig!

 

[new Account()]

Ich bin in dem Umfeld Pentesting aktiv, so ein bisschen Obfuscation ist das was für Lacher und Witze in der Kaffeeküche sorgt[1].

Schön. Ich glaube aber nicht, dass obfuscation notwendigerweise als Sicherheitsmaßnahme genutzt wird.
Und manchmal ist es auch schon ein ausreichend, wenn es nicht trivial verständlich ist.

Das benennen von Variablen ist kein Ding. Die Namen der Variablen braucht ein Angreifer in der Regel nur für ein absolutes Minimum der Variablen. Wobei aus dem Inhalt der Variabel meist sowieso klar wird, welche Funktion die Dinger haben.

Das klappt solange du nichts spannendes machst. Da kannst du dann richtig Geld darin versenken. Und alles was ich mache: einen Schalter umlegen
👍

Tree Shaker bringen Performance, Minifier seit Jahren in der Regel nichts.

WIe gesagt: Falsch. Die Dateigröße wird signifikant reduziert.

Ohne Kompression,

Zuvor wurde schon gezeigt, dass Kompression eben den Minifier nicht in Luft auflöst.

Und vor allem, wenn 32kbit/s die Bandbreite des Zielpublikums ist, dann lass das Javascriptgerümpel ganz weg

Auswirkungen hat man auch bei höheren Bandbreiten.
Und es summiert sich.
Und es schadet nicht die Hürden für alle zu reduzieren.

Deine Nichtreaktion auf den Rest, interpretiere ich mal als Zustimmung, und empfehle jedem beim Minifier nicht nur die Kommentare entfernen zu lassen.
Vielleicht ärgert man ja ein paar Pentester:

Pest: Weil das JS unlesbar wird

 

[Techniktype]

Dass man eben erstmal mit JS an sich umgehen lernt

Was muss man den können um als fortgeschritten zu gelten ?

Datenbanken. MySQL wäre dabei mit das Letzte was ich wählen würde. Je nach Umfang wäre es eher Sqlite, Postgres oder MariaDB mit Präferenz für die ersten Beiden.

Bisher habe ich nur mit MySQL gearbeitet, ist es so schlecht?

Beispiel: Anstatt jedem Block margin: 0.3em und color: 0xff1337 zu setzen sowas global anwenden.

Macht man das denn nicht sowieso?

einfach aktuelle HTML Features nutzt. Beispiel: Lazyloading von Bildern/Videos. Das war lang nur mit JS möglich, ist mittlerweile aber Bestandteil von HTML und wird von allen relevanten Browsern unterstützt.

Echt? Das wusste ich in der tat nicht, wie funktioniert es denn in HTML?

Treeshaking

Was ist denn das?

"Realistisch sind 32kbit/s in der Drosselung und/oder Edge"
Bei der Bandbreite mit den entsprechenden Latenzen und dem zu erwartendem Packetloss muss man bereits beten, dass der TLS Handshake überhaupt klappt. Wer Clienten bedienen, wo diese Bandbreite ernsthaft relevant ist, sollte Seite grundsätzlich so aufbauen, dass möglichst gar kein JS und keine Medien ausgeliefert werden..

Ja ich muss viele Seiten oft mehrmals aufrufen bis diese nutzbar sind. Aber ich meine wenn man der Bandbreite entgegen kommt dann hat das zumindest keinen Schaden?

Google ist ja dafür bekannt in der IT/Webentwicklung hinterherzuhinken.

Das heißt die Developertools von Google sind nicht zu empehlen? 🤔

"The minified version of this sample code is 48% smaller. In some cases, minification can reduce file size by as much as 60%. For instance, there’s a 176 kb difference between the original and minified version of the JQuery JavaScript library."
Macht bei 32kbit/s 5,5 Sekunden aus.
Bei 64kbit/s 2,8 Sekunden. Beides sind übliche Drosselungsgeschwindigkeiten.
Wieviel sinds mit Kompression?

Ich will ja kein Pessimist sein aber du musst deine Sekundenwerte noch um den Faktor 8 multiplizieren Ich wünschte mein Anbieter würde sich da auch mal um den Faktor 8 verrechnen - 8 mal Schnelleres Internet, Juhu! Außerdem wird durch den Datenverbrauch von anderen Apps und Betriebssystem niemals die 64kbit erreicht.

Und vor allem, wenn 32kbit/s die Bandbreite des Zielpublikums ist, dann lass das Javascriptgerümpel ganz weg, sowie alle Bilder, Videos, Schriftarten etc. pp! In solchen Fällen sollte man sowas wie https://blog.fefe.de ausliefern (und im Gegensatz zu fefe HTTP2 nutzen!)

Also ich bin schon froh wenn ein kleinwenig Style auf der Webseite ist. Wie wäre es mit einer dritten optimierten einstellung wie Datensparmodus die für "Steinzeitinternet" geeignet ist.

Bei CSSMinify bin ich mir nicht sicher, weil ich es nur einmal genutzt habe und da hat es mein Datei von 16kb auf 12kb geschrumpft. Aber ich wüsste auch nicht was es schaden soll.

 

[new Account()]

Was ist denn das?

Das Entfernen von ungenutzten Code.

Das heißt die Developertools von Google sind nicht zu empehlen? 🤔

Das war Sarkasmus

 

[Techniktype]

Das war Sarkasmus

Achso ich hatte mich schon gewundert

 

[askling]

Ich kann Piktogramms Abneigung gegen minifizieren nicht wirklich nachvolziehen.

Beim Entwickeln sieht man natürlich nie minifizierten Code. Für Audits liefert man einfach nicht minifizierten Code aus, bei Bedarf. Das läuft beim Deployment automatisch ab. Entfernt alle Kommentare und reduziert definitiv die Ladezeiten bei größeren Projekten durch praktisch 0% Mehraufwand. Es gibt nicht nur Webseiten wo JS bisschen als Zusatz verwendet wird, die aber eigentlich mit HTML auskommen würden.

Ich möchte auch nochmal den Kontext betonen. Das Thema minifizieren kam auf, weil gefragt wurde ob man nicht lieber extrem kurze Namen für Variablen im Source benutzen soll. Minifizieren sollte aufzeigen, dass sowas unsinnige Optimierungen bei (Hoch)-Sprachen wären.

Es gibt viele Webseiten oder besser Webapps die durch sehr große Funktionalität (kein Bloat durch Dependencies) eher um Umfang von 2-3 MB oder mehr JS Sourcen haben. Da macht sich das trotz Packern bemerkbar.

Minifizieren bringt natürlich keine Sicherheit. Macht ein Reverse-Engineering aber deutlich aufwendiger, trotz aller Beautifier usw. . Ob das einen Mehrwert bietet muss jeder selbst entscheiden.

 

[Piktogramm]

@askling
Ich habe etwas gegen "lass uns was tun auch wenn wir nicht wirklich wissen wieso". Die Begründungen für Minification sind schlichtweg überholt. In den meisten Fällen kann man auf andere Art und Weise in der Regel viel mehr herausholen. Aber lassen wir das, liebgewonnene Traditionen halten sich ja gern mal länger.

Was Seiten mit MB-weise JS daherkommen. Das das wirklich notwendig ist, ist äußerst selten und selbst wenn es notwendig ist, ist es in der Regel schlecht umgesetzt. Anstatt da nur die notwendigen Hauptfunktionen zu laden und alle nicht sofort notwendigen Zusatzfunktionen auf verschiedene JS Files aufzuteilen und via lazyload zu laden. Letzteres würde die Geschwindigkeit bis zum 1. Frame und ersten Interaktionsmöglichkeit auf Seiten enorm beschleunigen. Aber man liebt ja seine Bräuche und packt alles in monolitische JS Files, weil man nicht mitbekommen hat, dass dieses Brauchtum mit HTTP2 recht sinnlos geworden ist.
Ansonsten, wer heute anfängt eine Seite mit viel Funktionalität bauen zu wollen sollte anfangen sich mit Webassembly zu befassen.

Und Minification soll reverse Engineering komplizierter machen? Wirklich, da Mehraufwand ist mit entsprechender Erfahrung, Arbeitsabläufen und Werkzeugen nicht erheblich. An der Stelle sollte man nicht so irre sein den Code komplett lesen zu wollen, sondern klemmt sich einfach ans laufende Programm und sieht da recht genau was der Code tut. Den Code zu lesen und im Hirn nachzuvollziehen was der Code macht ist da oftmals selbst ohne Minification größer .

Was muss man den können um als fortgeschritten zu gelten ?

Das Wichtigste ist Eigenständigkeit und stetige Fortbildung. Letzteres bedingt auch, dass man den Entwicklungen in dem Bereich folgt und mal aller 1-2Jahre prüft ob das eigene, alte Wissen noch der Realität entspricht.
In deinem Fall wäre der erste Ansatz, anstatt bei jedem unbekanntem Begriff hier zu fragen mal selber zu suchen was du dazu findest.

Bisher habe ich nur mit MySQL gearbeitet, ist es so schlecht?

MySQL ist nicht schlecht. Es gibt aber besseres.

Echt? Das wusste ich in der tat nicht, wie funktioniert es denn in HTML?

siehe oben, eigenständig selber suchen:
https://duckduckgo.com/?t=canonical&q=html+lazy+loading&ia=web

Ja ich muss viele Seiten oft mehrmals aufrufen bis diese nutzbar sind. Aber ich meine wenn man der Bandbreite entgegen kommt dann hat das zumindest keinen Schaden?

Seiten so zu gestalten, dass sie die Erwartung moderner, interaktiver Webinhalte entspricht, Multimediainhalte liefert UND mit derart geringe Bandbreiten funktioniert ist sehr aufwendig (weit aufwendiger als das bisschen Minification). Aufwand bedeutet in der Regel Kosten und die Frage ist halt ob irgendwer diesen Aufwand tragen will für die paar Nutzer mit Steinzeitinternet.

Also ich bin schon froh wenn ein kleinwenig Style auf der Webseite ist. Wie wäre es mit einer dritten optimierten einstellung wie Datensparmodus die für "Steinzeitinternet" geeignet ist.

Style kannst du da einziehen, aber jeder Style bedeutet halt mehr Daten die zu übertragen sind (bis sie im Browsercache liegen).
Ansonsten, eine Anpassung einer modernen Webseite auf einen 32kbit/s Modus würde bedeuten, dass man praktisch die gesamte Seite reimplementieren muss und selektiv an alle Höhlenbewohner ausliefert. Das kannst du voll vergessen, dass sich den Aufwand irgendwer aufhalst

Beispiel blog.fefe.de mit einem CSS welches an "BILD" angelegt ist:
https://blog.fefe.de/?css=bild.css

Schaut gruslig aus, aber ignorieren wir das einfach mal. Das bisschen minimal Style (inkl. einem Bild) und schon ist die Seite 5kB "schwerer". In dem Fall sind das 33% Zuwachs. Vergleichen wir das mal:

-rw-rw-r-- 1 bob bob  13K Sep 26 16:14 bild.css
-rw-rw-r-- 1 bob bob 6,1K Sep 26 16:14 bild.css.br
-rw-rw-r-- 1 bob bob 5,9K Sep 26 16:14 bild.css.gz
-rw-rw-r-- 1 bob bob  12K Sep 26 16:18 bild_mini.css
-rw-rw-r-- 1 bob bob 6,0K Sep 26 16:18 bild_mini.css.br
-rw-rw-r-- 1 bob bob 5,8K Sep 26 16:18 bild_mini.css.gz

Eben jenes css File durch https://cssminifier.com/ minifiziert. Danach habe ich bild.css einmal mit gzip -k -11 bild.css und einmal mit brotli brotly -k -9 bild.css gejagt.

wir halten fest: Die Designentscheidung hat die zu übertragende Datenrate um ~5kB aufgebläht. Minification hat davon dann wieder ganze 0,1kB eingespaart. Also ganze 2 Promille. Die Minification hat also eine Verbesserung gemacht die im Rauschen der Latenzen im Internet verpufft. Die Designentscheidung hingegen hat die Situation um 33% verschlimmert.
Jetzt also nochmal, wo sollte man sinnvoll Zeit investieren (und sei es noch so wenig)?

Bei größeren Seiten ist es tendenziell ähnlich. Kannst es ja mal mit computerbase.de durchexerzieren. Wie groß da die Änderungen sind.

 

[andy_m4]

Ich bin in dem Umfeld Pentesting aktiv, so ein bisschen Obfuscation ist das was für Lacher und Witze in der Kaffeeküche sorgt[1].

Ich glaube ja, die Leute die Code-Obfuscation machen sind die gleichen, die auch auf ihrer Webseite den Rechtsklick sperren, damit keiner die Bilder kopieren kann. :-)
Die wollen halt nicht, das Du deren Code klaust bzw. besser gesagt: Das Du nicht merkst, das die den ihrerseits bei Stackoverflow und Co zusammengeklaut haben. :-)

Die Begründungen für Minification sind schlichtweg überholt.

Andererseits sind das halt low-hanging-fruits, wie man so schön sagt. Selbst wenn der Effekt Minimal ist, nehmen ihn viele mit weils halt kein Aufwand kostet, sondern eh Teil des Make/Deployment-Prozesses ist.

 

[askling]

@Piktogramm

Ich verstehe deinen Punkt schon. Und du hast ja recht dass oft nicht genug Hinterfragt wird. Aber ich finde du siehst das ein wenig im Tunnelblick auf negative Beispiele fixiert.

Dein Beispiel ist ein super kleine CSS. Kein Code aus einem größeren Project. Größere Webapps haben heute absolut den Umfang von dem was früher Desktop Anwendungen waren. Es ist nicht alle E-Comerce oder sozial Media, wo ich dir absolut zustimme und mich immer wieder frage warum muss das so viel Code und Libs haben.

Nicht jeder schreibt schlechten Code. Treeshaking und dynamisches Laden von Sourcen sind absoluter Standard!

Nicht jeder baut ein 100k Zeilen Sourcesfile. Es gibt schon vernünftige Architekturen, selbst bei JS.

HTTP2 wird nachladen einfacher und schneller machen, stimme ich dir auch zu.

Du siehst Debugging natürlich rein als Pentester. Ich stimme dir völlig zu das es keine Sicherheit bringt. Aber es hat Konsequenzen auf die wirtschatlichkeit den Code zu analysieren.

Webassembly ist super, habe ich schon benutzt. Wird aber JS nicht ablösen als Websprache. Man nutzt es eher zusätzlich. Oder beziehst du dich rein auf wasm, weil das die Ladenzeiten ja auch verringern kann?

Um mal ein Beispiel zu geben. Ich habe hier ein 50kb JS Soucefile mit viel Dokumentation, die ja auch dadurch entfernt werden.

• Minifiziert sind es 10kb.
• Gezipt sind es 10kb
• Minifiziert und gezipt sind es 4kb

Das finde ich nicht ganz unerheblich.

Es kommt also immer auf den Fall wie es zu bewerten ist.

 

[new Account()]

Um mal ein Beispiel zu geben. Ich habe hier ein 50kb JS Soucefile mit viel Dokumentation, die ja auch dadurch entfernt werden.

• Minifiziert sind es 10kb.
• Gezipt sind es 10kb
• Minifiziert und gezipt sind es 4kb

Das finde ich nicht ganz unerheblich.

Er will ja, dass du schon etwas minifying machst, aber nur Kommentare (welche bei mir ehrlich gesagt sowieso schon nur minimal vorhanden wären):

Einzig Kommentare sollten aus dem JS entfernt werden.
Ähnliches gilt für HTML, CSS und alle anderen Textformate.

Den Rest musst du weglassen, weil es den Code unlesbar macht:

Weil das JS unlesbar wird

In der Praxis heißt es dann beim Minfier die default Konfiguration zu ändern, damit Piktogramm den Code besser lesen kann.

 

[askling]

Das mit den Kommentaren habe ich tatsächlich überlesen! Danke für die Korrektur NewAccount().