Ankündigung

Einklappen
Keine Ankündigung bisher.

JS / extJS on demand

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • JS / extJS on demand

    Hi zusammen,

    ich möchte gerne Javascript Komponenten für einzelne Views eingrenzen. Insbesondere die verschiedenen Teile des ExtJS Framworks um weniger nicht genutzen Code an den Browser zu übertragen.

    Hierzu fallen mit 2 Varianten ein:
    1. JS lädt die Komponenten bei bedarf einfach nach, dazu muss ich das JS einfach in einzelne Files aufteilen (load-on-demand methode)
    2. Ich definiere in meinem PHP Code welche JS-Komponenten ich beim aufgrufenen view brauche und lasse mir von PHP eine Datei generieren die den benötigten JS Code enthält (generate-on-demand methode)

    Was meint ihr bzw. wie würdet ihr vorgehen?

    Gruß
    cy


  • #2
    sorry, ausversehen falsches forum erwischt, bitte verschieben

    Kommentar


    • #3
      Mit On-Demand ist das bei JavaScript so eine Sache. Eingebundene Skripte werden nur dann zuverlässig geparst, wenn sie noch vor dem DOMDocumentReady-Event eingefügt werden. Ansonsten bleibt nur die Methode mit AJAX+eval().

      Themenmoderation:
      [→] Verschoben von HTML, Usability und Barrierefreiheit
      Refining Linux: “Performing Push Backups – Part 1: rdiff-backup

      Kommentar


      • #4
        Naja ich hab in einem aktuellen Projekt 1,7 MB JS-Code und bei dem relaunch des Projektes will ich davon wegkommen alles auf einmal zu laden. Also deiner Aussage nach sollte ich also eher die generate-on-demand methode nutzen?

        Kommentar


        • #5
          Würde ich vorschlagen. Dazu noch das JS minimieren (Spaces entfernen, dazu solltest du allerdings auch nach schließenden geschweiften Klammern Semikola setzen: };) und per GZIP komprimiert ausliefern. Dann solltest du nur noch wenige KB übertragen müssen.
          Refining Linux: “Performing Push Backups – Part 1: rdiff-backup

          Kommentar


          • #6
            Zitat von cycap Beitrag anzeigen
            Naja ich hab in einem aktuellen Projekt 1,7 MB JS-Code
            WTF ...?

            Sprichst du von reinem Code, oder auch Daten (JSON o.ä.)?
            Hast du das schon GZIP-komprimiert?


            Mit beiden Varianten, die du vorgeschlagen hast, gibt es Performance-Probleme.
            Bei 1) hast du zahlreiche HTTP-Requests mit entsprechendem Overhead. Bei einer normalen Website wäre das eher ein no-go - Suchmaschinen wollen ja zukünftig auch die Gesamtladezeit einer Seite ins Ranking einbeziehen (Stichworte Google PageSpeed, YSlow). Bei einer Web-Applikation wäre dieser Faktor eher zu vernachlässigen, da können dem Nutzer Wartezeiten eher zugemutet werden.
            Bei 2) verschenkst du leicht die Möglichkeiten des Caching. Du kannst zwar in deinem PHP-Script entsprechendes implementieren (Last-Modified, 304-Antwort, ggf. Expires) für Ressourcen, die dem Client bereits vorliegen. Das geht aber nur jeweils auf Ebene eines kompletten „JS-Pakets“ - wenn noch andere Komponenten benötigt werden, erzeugt dein PHP-Script wieder eine neue Ressource, die wieder komplett vom Client geladen werden muss. Es sei denn, du kombinierst das wiederum mit 1) - dann muss dein PHP-Script aber auch noch die Logik implementieren zum nachvollziehen, welche Komponenten der Client bereits vorliegen hat, und welche er noch separat nachladen muss.

            Kommentar


            • #7
              WTF ...?

              Sprichst du von reinem Code, oder auch Daten (JSON o.ä.)?
              Hast du das schon GZIP-komprimiert?
              ExtJS-Files + eigenen Code, minified, nicht komprimiert.

              Mit der GZIP komprimierung habe ich mich nicht weiter auseinander gesetzt nachdem ich gelesen hatte das der IE6 damit Probleme hat. Es handelt sich hier zwar um eine WebApplikation, also die Suchmaschinen sind mir egal, aber die Ladezeit ist dennoch ein wichtiger Punkt, da die App viel über GPRS/UMTS in Verbindung mit VPN genutzt wird.

              Kommentar


              • #8
                Zitat von cycap Beitrag anzeigen
                Mit der GZIP komprimierung habe ich mich nicht weiter auseinander gesetzt nachdem ich gelesen hatte das der IE6 damit Probleme hat.
                Man soll ja auch nicht ausschließlich eine GZIP-komprimierte Version anbieten, sondern als Alternative für Browser, die damit umgehen können.

                Beschäftige dich auf jeden Fall damit - gerade aus textbasierten Formaten kann GZIP idR. noch einiges „rausholen“.

                Kommentar


                • #9
                  nachdem ich gelesen hatte das der IE6 damit Probleme hat
                  Kann ich nicht bestätigen. FÜr refining-linux.org habe ich per .htaccess alles GZIP-komprimiert. Soweit ich weiß, wertet mod_deflate aber auch den Accept-Encoding-Header aus.
                  Refining Linux: “Performing Push Backups – Part 1: rdiff-backup

                  Kommentar


                  • #10
                    Hi cycap, habe grade ähnliches vor, vor allem wegen der Vielzahl an JS-Dateien (ne Menge jQuery-Plugins inklusive deren CSS-Dateien). Alles in allem schnell mal 20 Dateien.

                    Minified werden alle automatisch, falls in PHP eingestellt (gibt da eine PHP-Minify Klasse im Netz). GZIP hat einige Probleme gemacht, lohnt sich aber trotzdem auf jeden Fall.

                    Mein Ziel war es noch, da ich sowieso die ViewHelper im ZF benutze und damit eine Liste der benötigten JS-Dateien habe, das ganze "zusammenzufassen", also die Inhalte der JS-Dateien zu laden, daraus einen Schlüssel zu bilden und diesen als einiges <script> einzubinden.
                    "Mein Name ist Lohse, ich kaufe hier ein."

                    Kommentar

                    Lädt...
                    X