nicht angemeldet
JavaScript Einrückungen entfernen / code beautifuler
Hallo Forum,
ich habe diverse Websites gefunden, wie man einen hässlichen, unformatierten, unübersichtlichen Code einfach und vor allem gut lesbar formatiert (z.B. http://jsbeautifier.org/).
Jetzt suche ich das selbe "Rückwärts". Warum? Weil ich bei umfangreichen JavaScript-Dateien so zum teil mehrere KB einsparen kann, dass reduziert den Trafic und soll dem JavaScript-Parser im Brower entlasten.
Mir ist schon klar, dass das eher als Fine-Tuning zu betrachten ist, jedoch glaube ich, dass es auch hierfür irgendwo Tools / Websites gibt - nur leider finde ich diese nicht.
Habt Ihr einen Link zu einer solchen Website / zu einem solchen Tool?
Lieben Gruß
Daniela Waranie
-
ich habe diverse Websites gefunden, wie man einen hässlichen, unformatierten, unübersichtlichen Code einfach und vor allem gut lesbar formatiert (z.B. http://jsbeautifier.org/).
Jetzt suche ich das selbe "Rückwärts". Warum? Weil ich bei umfangreichen JavaScript-Dateien so zum teil mehrere KB einsparen kann, dass reduziert den Trafic und soll dem JavaScript-Parser im Brower entlasten.Du willst also deine Whitespace Einrückung in Tabs umwandeln.
Nimm doch den Editor deiner Wahl.mfg Beat
--
><o(((°> ><o(((°>
<°)))o>< ><o(((°>o
Der Valigator leibt diese Fische
-
Hallo Beat,
Du willst also deine Whitespace Einrückung in Tabs umwandeln.
Nimm doch den Editor deiner Wahl.nein, ich will alle Überflüssigen Zeichen entfernen lassen. Also: Zeilenumbrüche, Leerzeilen, Leerzeichen und Tabs. Ich könnte mir auch vorstellen, dass Variablenamen, eigene Funktionsnamen und eigene Objektnamen durch einen einzigen Buchstaben ersetzt werden (ggf. auch durch 2 oder 3 Zeichen, wenn der Code sehr umfangreich ist).
Quasi ein "Code Uglyfier" statt eines "Code Beautifier"
Lieben Gruß
Daniela Waranie-
Hallo Beat,
Du willst also deine Whitespace Einrückung in Tabs umwandeln.
Nimm doch den Editor deiner Wahl.
nein, ich will alle Überflüssigen Zeichen entfernen lassen. Also: Zeilenumbrüche, Leerzeilen, Leerzeichen und Tabs. Ich könnte mir auch vorstellen, dass Variablenamen, eigene Funktionsnamen und eigene Objektnamen durch einen einzigen Buchstaben ersetzt werden (ggf. auch durch 2 oder 3 Zeichen, wenn der Code sehr umfangreich ist).Quasi ein "Code Uglyfier" statt eines "Code Beautifier"
Kann ich schon nachvollziehen. Ich habe eher allgemeine Bedenken, die sich auf jede Art von Kompression von Code beziehen.
Nimm an, du lieferst deine komprimierte Version vom Server aus.
Deine Urversion hast du im Safe.Nun bekommst du einen Fehler (selbst festgestellt oder berichtet). Deine Analyse bezieht sich auf den komprimierten Code. Der Fehler ist irgendwo in Zeile 1. Wo aber zum Teufel ist nun der Fehler in der unkomprimierten Version?
Deshalb tendiere ich dazu, Linefeeds als Debugging-Tool zu behalten.mfg Beat
--
><o(((°> ><o(((°>
<°)))o>< ><o(((°>o
Der Valigator leibt diese Fische-
Moin,
Deshalb tendiere ich dazu, Linefeeds als Debugging-Tool zu behalten.
Und ich tendiere dazu auf den extra KB zu scheissen und meinen Code so zu lassen. Inklusive der Kommentare und der Leerzeilen vor und nach Bloecken oder auch einzelnen Befehlen.
Meine Meinung:
Code gehoert nicht gepackt. Er gehoert sinvoll geschrieben.
--
"Die Diebesgilde beklagte sich darueber, dass Mumm in aller Oeffentlichkeit behauptet hatte, hinter den meisten Diebstaehlen steckten Diebe."
- T. Pratchett-
Code gehoert nicht gepackt. Er gehoert sinvoll geschrieben.
Da besteht kein Widerspruch.
Mathias
-
Nabend!
»» Code gehoert nicht gepackt. Er gehoert sinvoll geschrieben.
Da besteht kein Widerspruch.
Hab'sch nich behauptet.
--
"Die Diebesgilde beklagte sich darueber, dass Mumm in aller Oeffentlichkeit behauptet hatte, hinter den meisten Diebstaehlen steckten Diebe."
- T. Pratchett-
-
Moin.
Und wieso gehört er nicht gepackt?
Das Argument ist hier, dass Fehler im Produktivsystem nur schwer zu verfolgen sind. Kann man darauf verzichten, spricht nichts gegen das Packen des Codes.
Es sind übrigens auch Zwischenlösungen möglich: Beispielweise kann man alle Kommentare und unnützen Whitespace entfernen, aber die Zeilenumbrüche und Variablennamen intakt lassen. Das reduziert zwar den Geschwindigkeitsgewinn, lässt dafür aber sinnvolle Fehlermeldungen zu.
Die Frage ist aber, ob sich das Packen wirklich lohnt, da in vielen Fällen nicht das Parsen des Skriptcodes der Flaschenhals sein dürfte (ich lasse mich da aber von Messungen gern eines besseren belehren).
Christoph
-
Wir reden über den hypothetischen Fall, dass ein Fehler im Produktivsystem reproduziert werden kann, aber nicht im Entwicklungssystem. Wenn das der Fall ist, dann sollten beide zunächst (abgesehen vom gepackten JS-Code) so angeglichen werden, dass der Fehlerfall auch im Entwicklungssystem auftritt. Wenn das nicht weiterhilft, dann bringt auch nicht-gepackter JS-Code nichts, es sei denn, der Fehler liegt in der Komprimierung selbst.
Insofern halte ich den Fall für sehr unwahrscheinlich und wenn der Fehler nicht durch die Komprimierung kommt, ist auch nicht damit geholfen, dass man beim Produktivsystem unkomprimierten Code verwendet.
Es sind übrigens auch Zwischenlösungen möglich: Beispielweise kann man alle Kommentare und unnützen Whitespace entfernen, aber die Zeilenumbrüche und Variablennamen intakt lassen. Das reduziert zwar den Geschwindigkeitsgewinn, lässt dafür aber sinnvolle Fehlermeldungen zu.
Man ist ja nicht komplett »blind« bei bem Debuggen von Minified-Code. Wenn man den eigenen Code kennt, kann man mit Fehlermeldungen und Stack-Traces durchaus etwas anfangen. Es muss ja nur reichen, den Fehler zu lokalisieren. Wenn man ordentlich strukturierten Code schreibt, ist das auch kein Problem. Außerdem sind die wenigsten Scripte nach dem Minifying komplett unleserlich. Umbenannt werden bloß lokale Variablen, es bleiben meist genug »öffentliche« Eigenschaft und Methoden übrig, sodass der Zusammenhang weiterhin erkennbar ist.
Die Frage ist aber, ob sich das Packen wirklich lohnt, da in vielen Fällen nicht das Parsen des Skriptcodes der Flaschenhals sein dürfte (ich lasse mich da aber von Messungen gern eines besseren belehren).
Natürlich gibt es keinen großen Unterschied zwischen einem GZip-komprimierten Script mit nur wenig gekürztem Code und einem ebenfalls GZip-komprimierten Script mit vollständig gekürztem Code.
Mathias
-
Hi!
Die Frage ist aber, ob sich das Packen wirklich lohnt, da in vielen Fällen nicht das Parsen des Skriptcodes der Flaschenhals sein dürfte (ich lasse mich da aber von Messungen gern eines besseren belehren).
le signed.
Als Minimalbeispiel erwaehne ich mal den komischen Liebestest, der hier grad irgendwo verlinkt wurde. Sicher kann man solchen Code jeglicher Whitespaces berauben und wild Variablen namen ala a, b, c verteilen. Besser wird er dadurch aber nicht.
Dazu kommt natuerlich meine persoenliche Einstellung: Wen ich mir den Code im Browser anschaue, dann will ich den auch lesen koennen. Fertig. Das kann natuerlich an meiner gewoehnlichen Programmierumgebung liegen. Mag sein, dass sowas ausser mitm IE6 kein Problem mehr ist. Aber mit dem muss ich nunmal arbeiten. Und da brauche ich nunmal lesbaren Code. Is so oft schon schwierig genug den wirklichen Fehler zu finden. Da muss nur mal ne geschweift Klammer floeten gehen und schon wirds fies.
Vielleicht sind Codepacker ja nur etwas fuer Leute die den Luxus ausgefeilter Programmierumgebungen geniessen. Fuer mich, ausgestattet mit IE6 und Notepad, ist lesbarer Code (auch im Browser) vorrangig.
--
"Die Diebesgilde beklagte sich darueber, dass Mumm in aller Oeffentlichkeit behauptet hatte, hinter den meisten Diebstaehlen steckten Diebe."
- T. Pratchett-
Wen ich mir den Code im Browser anschaue, dann will ich den auch lesen koennen.
Wieso? Willst du den Code auf fremden Seiten lesen?
Okay, dieser Wunsch sei dir unbelassen, aber du kannst doch vom Seitenautor nicht verlangen, dass er den Code, der eigentlich nur schnellstmöglich zum Browser übertragen und ausgeführt werden soll, fürinteressierte JavaScript-Entwickler lesbar ist.
Manche komprimieren den Code auch, weil sie ihr »Intellectual Property« schützen wollen und die Interna nicht offensichtlich sein sollen.Mag sein, dass sowas ausser mitm IE6 kein Problem mehr ist. Aber mit dem muss ich nunmal arbeiten. Und da brauche ich nunmal lesbaren Code.
Was hat das mit IE 6 zu tun?
Offenbar drehen wir uns im Kreis und du gehst überhaupt nicht auf den Stand der Diskussion ein. Niemand hat vor, obsfuscated Code zu debuggen, und niemand hat das hier empfohlen. Insofern weicht deine Meinung gar nicht von denen ab, die Bundling und Minifying in der PRODUKTIVumgebung nutzen.
Mathias
-
Hoi!
Was hat das mit IE 6 zu tun?
Ganz vielleicht koennte es ja irgendein schoenes Plugin geben, das einem den Code netter aufbereitet, oder sonsteine detailierte Info liefert, die einem sagt, wo der Fehler zu suchen ist.
Offenbar drehen wir uns im Kreis und du gehst überhaupt nicht auf den Stand der Diskussion ein. Niemand hat vor, obsfuscated Code zu debuggen, und niemand hat das hier empfohlen. Insofern weicht deine Meinung gar nicht von denen ab, die Bundling und Minifying in der PRODUKTIVumgebung nutzen.
Doch klar. Du setzt schaeinbar nur voraus, dass du Code besitzt, der lesbar ist, wenn jemand zu Dir kommt und sagt: 'Ey, da isn Fehler auf der Seite mach den mal weg.'
--
"Die Diebesgilde beklagte sich darueber, dass Mumm in aller Oeffentlichkeit behauptet hatte, hinter den meisten Diebstaehlen steckten Diebe."
- T. Pratchett-
wenn jemand zu Dir kommt und sagt: 'Ey, da isn Fehler auf der Seite mach den mal weg.'
Das ist tatsächlich ein Argument. Mit IE-6-Fehlermeldungen von Benutzern kann man bei Minified-Code noch weniger anfangen als es überhaupt schon der Fall ist. Andererseits ist es meiner Erfahrung nach selten der Fall, dass Fehler überhaupt nicht lokalisiert werden kann. Ich habe auch an komplexen JS-Anwendungen für den IE 6 gearbeitet. Mit ungefährer JS-Fehlermeldung, die einem »Bezeichner has no properties« oder eine Codezeile gibt, kann man natürlich mehr anfangen als mit »a has no properties« und Zeile 1. In der Regel treten Fehler aber bei spezifischen Aktionen auf, sodass man den verantwortlichen Code finden kann auch ohne die Fehlermeldung zu sehen. Letztlich gibts auch für den IE 6 JS-Debugger, die einem auch bei Minified-Code helfen, sofern nicht ALLES weggekapselt ist und die Bezeichner entsprechend verfremdet wurden.
Mathias
-
Moin!
Letztlich gibts auch für den IE 6 JS-Debugger, die einem auch bei Minified-Code helfen, sofern nicht ALLES weggekapselt ist und die Bezeichner entsprechend verfremdet wurden.
Aber die sind nicht standardmaessig dabei. Deshalb hilft mir das nix. (weder darf, noch kann ich hier was installieren)
Ich hatte vor einiger Zeit mal nen Kollegen, der war sein eigener Packer. Der hat von vornherein Code komprimiert und funktionen wie xxx(), Variablen wi a, z, ... erstellt. (War die Districtsume jetzt a oder z? Kommentare gabs ja auch keine. Kommentare sind uneffizient) Einrueckungen bei Schleifen, Funktionen, etc... Bloss nicht! Das ist doch sinnlose Platzverschwendung! Naja. Soviele Funktionen gabs auch nicht. Spaghetticode war angesagt. Das war nicht schoen zu debuggen. (Ist es immer noch nicht...)
Ach: Objektorientiert programmieren ist uebrigens auch nicht effizient. Viel zuviel Code und viel zu langsam.
Nuja. er hat uns dann aus Gruenden verlassen, die hier nicht Thema sind. Seitdem mag der Code zwar ne Sekunde laenger brauchen, ist aber les- und wartbar.
Als kurze Anmerkung sei hier aber noch erwaehnt, dass wir in Acces eine Kalenderwochenbestimmung hatten. Nachdem Er weg war, hab ich herausgefunden, dass sein Code nichtmal richtig funktioniert hat. Er hatte ueber 90 Zeilen, die er jedes Jahr angepasst hat, weil es sehr statisch war. Mein Ersatzcode war 7 Zeilen lang und passt, solange sich an den Regeln zu den Kalenderwochen nichts aendert. Aber Sein Code hatte immerhin extrem wenig Zeichen, die nicht direkt Code waren. Sehr kompakt. Sowas meinte ich mit meinem Kommentar. (Code gehoert nicht gepackt. Er gehoert sinnvoll geschrieben.)
Code zu packen ist einfach das letzte ueber das ich mir dabei Gedanken mache. Das kann man getrost weglassen. Oft ist z.b. die eigentliche Frage: 'Brauch ich dieses ueberladene Framework ueberhaupt?' oder 'Wo koennte ich noch etwas besser machen?'
Ich hab jedenfalls noch nie ein Framework benutzt. Darf ich hier auch nicht. Und mein Code ist sicherlich noch lang nicht perfekt. Dafuer muessen immer viel zu viele Sachen 'on the fly' hingerotzt werden. Also schraub ich lieber da rum, wenn etwas zu lange dauert.
--
"Die Diebesgilde beklagte sich darueber, dass Mumm in aller Oeffentlichkeit behauptet hatte, hinter den meisten Diebstaehlen steckten Diebe."
- T. Pratchett
-
-
-
-
-
-
-
-
-
-
Deine Analyse bezieht sich auf den komprimierten Code.
Wieso sollte sie?
Mathias
-
-
-
-
Moin.
Jetzt suche ich das selbe "Rückwärts". Warum? Weil ich bei umfangreichen JavaScript-Dateien so zum teil mehrere KB einsparen kann, dass reduziert den Trafic und soll dem JavaScript-Parser im Brower entlasten.
Nennt sich minifier und gibt's z.B. von Crockford und Yahoo.
Ich würde dir raten, darauf zu verzichten: Lege einfach zusätzlich zu der ungepackten Version eine (statisch) gzip komprimierte Version ab und lass content negotiation ihr Werk tun.
Die Zusätzliche Verkleinerung des Quelltexts wird die Übertragungszeit nicht signifikant verbessern, allerdings hast du recht dass, es das Parsen beschleunigt:
Messungen (archive.org) ergeben für folgende Bibliotheken eine Zeitersparnis von:
dojo-1.0.1 : 30%
jquery-1.2.1: 20%
prototype-1.6.0: 10%
protoculous-1.0.2: 3%gegenüber der rein gzip-komprimierten Variante.
Christoph
-
Hallo Christoph,
Ich würde dir raten, darauf zu verzichten: Lege einfach zusätzlich zu der ungepackten Version eine (statisch) gzip komprimierte Version ab und lass content negotiation ihr Werk tun.
Der Vorteil beim Parsen ist mir wichtig. GZIP will ich sowieso "on Top" verwenden.
Weiß jedoch noch nicht, ob ich die GZIP-Version der statischen Datei manuell erstellen kann und nur in einer bestimmten Dateinamen-Konvention auf meinem Apache ablegen muss. Geht das so einfach?
Muss ich im Apache ein Modul instalieren/einbinden, damit dieser GZIP unterstützt?
Muss ich für Content Negotiation ebenfalls ein Modul installieren / einbinden?
Werden statische Dateien bei jedem Request mit einer on-the-fly erstellten gzip-Version beantwortet oder wird die gzip-Version gecached?
Kann man die komprimierung auf einen anderen Server auslagern?Lieben Gruß
Daniela Waranie-
Moin.
Muss ich im Apache ein Modul instalieren/einbinden, damit dieser GZIP unterstützt?
Muss ich für Content Negotiation ebenfalls ein Modul installieren / einbinden?
Werden statische Dateien bei jedem Request mit einer on-the-fly erstellten gzip-Version beantwortet oder wird die gzip-Version gecached?Das sollte jemand beantworten, der sich mit Serverkonfiguration etwas besser auskennt als ich.
Aber laut Google geht es nur mit Apache oder aber über mod_gzip.
Christoph
-
-
-
Hoi.
http://code.google.com/p/minify/
Nen richtigen Performanceschub erreichst Du durch das Zusammenlegen meherer JS Dateien zu einer Ressource. Genau das leistet das Teil.
Grüße