Hi, findet man irgendwo die Einzeldateien die in der vendor.js enthalten sind, die gm_javascript.js.php lädt dieses Monster mit 1,5MB ja jedes mal neu ohne dabei den Browercache zu benutzen. lg
1. Was in der JSEngine steckt siehst du hier: https://developers.gambio.de/docs/3.1.1.0/jsdoc/ 2. das nix gecacht wird liegt nicht an Gambio! Hier eines meiner schlechtesten Beispiele im FireBug: 993,3 KB (384,9 KB aus dem Cache) da ist nix mit 1,5 MB 3. ein Link zur Baustelle wäre immer hilfreich, denn Glaskugeln hat keiner
Im Normalfall wird auch nicht die vendor.js sondern die vendor.min.js geladen, welche bedeutend kleiner sein sollte
Das verhalten beim Browsercache von gm_javascript.js.php ist aber auch bei Chrom so. Alles was gm_javascript zusammenholt sind ja ca. 1,7MB wenn die mins genommen werden und das muss bei jedem Seitenaufruf neu auf dem Server zusammengebaut werden und gepackt wenden. Und das selbst wenn die Daten nicht ausgeliefert werden. Aber letztendlich will ich ja nur wissen, welche Javaschriptdateien in der vendor.js zusammengeführt worden sind und das ist leider nicht in der Beschreibung beschrieben. Achso, die Baustelle ist noch zu stark eine Baustelle und daher Passwortgeschützt und nicht Online zu erreichen. lg
Hallo, folgende Pakete werden beim Erzeugen der vendor.js berücksichtigt: 'jquery', 'jquery-ui', 'jquery-migrate', 'momentjs', 'jquery-ui-daterangepicker', 'mustache.js', 'datatables', 'DateJS', 'babel', 'jquery-deparam', 'datetimepicker'
Ok, danke, das ist schon mal ganz gut. Jetzt fehlen mir nur noch die entsprechenden Javascriptdateien in der richtigen Version. Einige konnte ich zwar finden aber halt nicht alle.
Wir haben diese Libraries nicht einzeln. Die vendor.js wird vollautomatisch durch Bower (https://bower.io/) erzeugt.
Wenn ich das richtig verstehe hat man also nicht die original Sourcen sondern nur das, was nach einem Buildlauf hinten von Band fällte. Bekommt man denn irgendwie eine Gitzugang oder zumindest einen Export der jeweils aktuellen Version. lg
Die Sachen liegen auch nicht im Git, die werden während des Paketbaus von den Autoren heruntergeladen, zusammengematscht und kommen dann als ein fertiger Klotz heraus. Im Git wären natürlich die Scripte die den Bau erledigen, den man dann auf halbem Weg umbringen müsste, um dann quasi aus dem temporären Speicher die einzelnen Bibliotheken zu fischen, die man dann verwenden könnte... Du könntest dir das leichter aus der im Shop vorhandenen nicht minifizierten Version ausschneiden und einzeln verdengeln.
Respekt, mit einer Antwort um diese Uhrzeit hätte ich nicht gerechnet und habe den Fall schon auf die nächste Woche vertagt. Ok, das läuft dann ja so wie bei Java mit Maven/Ant wo man sich benötigte Komponenten einem zentralen Repository holt und seine Pakete baut. Die Einzelscripte aus der minifizierten Datei zu holen kann aber nicht die Lösung. Da würde ich doch hoffen das ich entweder einen Gitzugang, oder zumindest einen Export der aktuellen Quellen von Euch bekommen könnte. lg
Alle Javascripte sind in den Releaseversionen auch ohne Minifizierung da, die werden verwendet wenn man den Shop in den Entwicklermodus versetzt, das geht durch das erzeugen einer Datei namens ".dev-environment" im Hauptverzeichnis des Shops. Spätestens dann kannst du dir das in Gänze ansehen. Die gm_javascript werden wir in absehbarer Zeit auch nochmal etwas zerlegen, um den statischen Teil damit Browser-cachable zu machen, wir glauben auch das wäre ein Gewinn. Es gibt einen Teil der "Seitentypdynamisch" ist, der verhindert ein Caching bisher, und den Klotz hat soweit noch niemand zerlegt, es muss sich nur ein Slot freier Entwicklerzeit zwischen allen Projekten finden, der ist aktuell gerade Mangelware.
Hallo Wilken, das ist jetzt aber noch keine Antwort auf meine Frage ob man einen Git-Zugang oder einen Export des aktuellen Heads bekommen kann. lg
Das stimmt Mein Versuch war jetzt eher der, dich darauf hinzuweisen, dass alles was da an Javascript benutzt wird in den Releaseversionen auch da ist. Unverschlüsselt, unminifiziert und komplett debugbar, mehr geht nicht. Wenn du unsere Buildscripte benutzt, nachdem du dir eine composer/bower/gulp/nodejs/npm/ruby/compass/... Entwicklungsumgebung gebaut hast, solltest du im besten Fall auf die gleichen Bestandteile kommen wie im Paket schon drin sind. Mit einem Git Checkout wird es nicht mehr. Das hast du glaube ich so noch nicht bemerkt, das ist aber wichtig als Information. Wenn ich also versuche dich auf die von uns abgesegneten Versionen zu ziehen, weil eben alles da ist, gehts darum dass du dir keinen Zombie bauen solltest. Wenn du trotzdem einen Checkout haben willst, kriegst du einen, das kriegen wir schon hin. Ich glaube nur aus meiner technischen Warte heraus das bringt dir ziemlich sicher ziemlich exakt null. Jetzt entscheide
Aus meiner Sicht bekomme ich da doch schon etwas ganz anderes, wenn ich das Buildscript welches die vendor.js baut anpasse bekomme ich da ein völlig andere vendor.js raus. Ich habe zum testen mal die vendor.js komplett weggelassen und das zum testen in die head.html eingebaut Code: <script type="text/javascript" src="graved/script/jquery-3.1.0.min.js"></script> <script type="text/javascript" src="graved/script/jquery-migrate-3.0.0.min.js"></script> <link rel="stylesheet" type="text/css" href="graved/script/jquery-ui-themes-1.12.0/themes/smoothness/jquery-ui.min.css"/> <script type="text/javascript" src="graved/script/jquery-ui-1.12.0/jquery-ui.min.js"></script> <script type="text/javascript" src="JSEngine/build/compat.js"></script> <script type="text/javascript" src="JSEngine/build/jse.js"></script> Erstaunlicher weise funktioniert die Seite bei Firefox und Chrom bereits nur beim IE gibt es Probleme mit Ajax und sicherlich auch an Stellen die ich noch nicht getestet habe. Des weiteren baut sich die Seite wesentlich schneller auf. Aber um es kurz zu machen ich hätte gern einen Abzug der aktuellen Version. lg
Das kann so schon mal nicht hinhauen, weil du eine viel neuere JQuery Version verwendest als wir, da sind wir aktuell noch bei einer deutlich älteren. Die neueren sind nicht mit allen Skripten im Shop kompatibel, das knallt. Ich habe aktuell die Vermutung, dass wir Jquery aktualisieren sobald Eyecandy/Mobilecandy End of Life sind, dann ist das Schlachtfeld da deutlich übersichtlicher als jetzt. Einen Link für den Download eines Git Checkouts sende ich dir gleich per PN.
Nochmal danke für den Download, damit konnte ich ohne Probleme die vendor.js in alle ihre Einzelzeile zerlegen. Aber wofür wird denn eigentlich "babel" benötigt das Ding ist ja der größte Brocken in der vendor. lg
Wir schreiben unser Javascript inzwischen in ECMAScript6, das erheblich wartbarer und lesbarer als die Vorgänger ist. Einige sehr dumme und zurückgebliebene Browser können das aber nicht lesen, die beherrschen nur ECMAScript5 und würden Fehler werfen. Richtig, ich rede vom Internet Explorer Für den Moment ist es also so, dass wir beim Paketbau alles ECMAScript6 automatisch in ECMAScript5 übersetzen lassen, damit wir InternetExplorer Benutzer, die es immernoch nicht gemerkt haben, noch nicht aussperren. Das macht Babel.
So, meine vendor.js Aktion ist erst einmal abgeschlossen, jetzt sind es nur noch 60KB die nicht mehr aus dem Cache kommen. Der Seitenaufbau ist gefühlt doppelt so schnell wie vorher, da jetzt alle größeren Scripte parallel initialisiert werden und nicht mehr nacheinander. Da alle Scripte gezippt wurden werden beim ersten Aufruf der Seite auch nur noch ca 300KB geladen. Von babel wird wohl nur polyfill benötigt und konnte weggelassen werden, bisher haben alle Browser mit der Änderung funktioniert. Diese Zeilen habe ich in die head.html eingefügt. Code: <script type="text/javascript" src="JSEngine/build/vendor/jquery.min.js.gz" ></script> <script type="text/javascript" src="JSEngine/build/vendor/jquery-ui.min.js.gz" ></script> <!--script type="text/javascript" src="JSEngine/build/vendor/babel.min.js.gz" ></script--> <script type="text/javascript" src="JSEngine/build/vendor/datatables.min.js.gz" ></script> <script type="text/javascript" src="JSEngine/build/vendor/DateJS.min.js.gz" ></script> <script type="text/javascript" src="JSEngine/build/vendor/datetimepicker.min.js.gz" ></script> <script type="text/javascript" src="JSEngine/build/vendor/jquery-deparam.min.js.gz" ></script> <script type="text/javascript" src="JSEngine/build/vendor/jquery-ui-daterangepicker.min.js.gz" ></script> <script type="text/javascript" src="JSEngine/build/vendor/momentjs.min.js.gz" ></script> <script type="text/javascript" src="JSEngine/build/vendor/mustache.js.min.js.gz" ></script> <script type="text/javascript" src="JSEngine/build/jse.min.js.gz"></script> <script type="text/javascript" src="JSEngine/build/vendor/polyfill.min.js.gz" ></script>
Wir haben heute auch gerade eine experimentelle Änderung im 3.3 Zweig eingebaut, die ähnliche Ziele bei etwas anderer Herangehensweise verfolgt. In einem Blanko Standard Shop ohne Einbauten sinkt die nicht gecachte Datenmenge der gm_javascript mit aktivem Honeygrid damit auf 0. Das muss noch heil durchs Testing kommen, sollte ab 3.3 dann aber allen Spass machen.