WebsiteBaker Support (2.8.x) > Diskussion über WB (closed)

Diskussion rund um JQ, JS und alles Mögliche

<< < (2/11) > >>

Yetiie:
Ups ...


--- Quote ---JS- und CSS-Dateien jeweils zusammenzufassen ist kein Problem.. und auch bereits auf der ToDo. Beides in eine einzige Datei gibt Probleme ...

--- End quote ---

Ne, so war das nicht gemeint und ist auch nicht State off the Art bzw. so weit geht das dann doch nicht. Selbstverständlich ist gemeint: JS zu JS und SCC zu CSS ... zwei statt 15 Request ist immer noch eine gute Quote, da muss man nicht auf 1: 15 kommen  :-) Außerdem glaube ich würden bei CSS + JS zu Universal die Anwender streiken bzw. die Funktion nicht nutzen ...

Die Zahl 15 ist natürlich fiktiv und schwankt erheblich ;-)

Bin dann mal gespannt, wobei das Preprozessing ja nur ein Teil der Optimierung ist ...

Yetiie:

--- Quote ---was für den einen ein Non-Plus-Ultra ist, ist für den anderen Murks.
--- End quote ---

Absolut dacor ... darüber zu Diskutieren ob Google-Einbindung der richtige Weg ist genauso wie über den Einsatz von Frameworks zu diskutieren: sinnlos! Jeder geht den Weg so wie er es für richtig hält und das ist auch gut so. Und mal ist das eine besser, mal das andere.

Der Vorschlag ist daher auch die optionale Möglichkeit des Ladens vom Google-Server zu integrieren. Gleichzeitig bietet er gerade wegen der größeren Wahlfreiheit und des geringeren Pflegeaufwands mehr Flexibilität.




--- Quote --- Ich bin mir z.b. sicher, das es auf Schlag hunderte Postings geben wird, das dieses oder jenes Plugin nicht mehr läuft.
--- End quote ---

Das kann ich nicht nachvollziehen.

Ad1: Die Einbindung von Google wurde als optionale und nicht als Standard-Lösung vorgeschlagen. Module sollten also schon von daher keine Probleme bekommen es sei denn die Entwickler hier entscheiden, dass es Zeit ist auf eine aktuellere Sprachversion umzustellen wie das aktuell der Fall ist ...

Ad2: Kein Modul wird nicht laufen wenn eine JQ v1.7.1 vom Google-Server statt vom eigenen Server geladen wird. Das ist dem Modul total egal woher die selben Textzeilen stammen bzw. von wo sie referenziert sind, denn sie sollen ja nicht geladen werden, weil sie sind ja schon da, spricht der hoffende Ladezeitenoptimiere r   :wink:




--- Quote ---Der große Teil der aktiven Leute hier wird das handhaben können
--- End quote ---

Naja, - so gesehen: ja natürlich. Wobei der große Teil der aktiven Leute hier die das handhaben können und(!) das umsetzen möchten ... setzen das schon heute um. Einen Link im Template zu schreiben ist ja nun wirklich nicht schwer (mal abgesehen vom blöden Escapen s.o. *g)

Aber jedes moderne Angebot macht - wenn man es geschickt verpackt - ein CMS attraktiver. Und für die 'Fortgeschreitenden' so etwas ein klein Tick komfortabler zu machen ... ist ja nicht unbedingt verkehrt  :-)

jacobi22:

--- Quote ---Aber jedes moderne Angebot macht - wenn man es geschickt verpackt - ein CMS attraktiver. Und für die 'Fortgeschreitenden' so etwas ein klein Tick komfortabler zu machen ... ist ja nicht unbedingt verkehrt
--- End quote ---

da teilen sich unsere Meinungen.
Ich hab hier ein paar hundert User, die ein WB privat oder beruflich nutzen und 90% davon wissen garnicht, was JQuery ist und wollen es auch garnicht wissen. Es geht nicht mehr um "das einfachste CMS der Welt", sondern nur noch darum, es den Fortgeschrittenen einfacher zu machen. Was meinst du denn, wer sich dann schöne TWIG-Templates baut?  Das bist vielleicht du oder ich, ein paar Modul-Autoren wie cwsoft oder Stefek, aber keinesfalls die User, die z.b. im Forum fragen, wie sie denn eine Überschrift im Template XY größer machen können.

Ich neige ja dazu, eine Beitragstrennung zu beantragen, aber erklär mir doch mal, warum ein Fremdzugriff auf eine Google-Datei Ladezeitoptimierend er sein soll als der Zugriff auf die gleiche Datei am lokalem Server. Vielleicht bin ich ja doof und vielleicht sollt ich auch einpacken, weil das, was hier kommt, nichts mehr mit dem zu tun hat, wofür WB mal stand.

Die Projekte, die ich in diesem Jahr mit WB gemacht habe, nutze alle die aktuelle JQ 1.11, das wird zwar nicht über Google geladen, wäre aber auch nicht das Problem, solang ich das einbinde oder ich dem User mit Zeilennummer sage, wo er das machen muß. Nicht einer würde sich trauen, da selbst etwas zu ändern oder, wo auch immer, zu verstellen. Wer hat also den Nutzen? Der Fortgeschrittene, der am Ende 3 Dateien weniger bearbeiten muß.
Meinst du wirklich, du gewinnst einen neuen Benutzer, wenn du jetzt diese Option zur Auswahl der JQ-Quelle hättest?
Das als Pressemeldung wird genau so ein Hammer wie Bilder von mir, wo ich naggisch vorm Reichstag tanze  :wink:

Ein CMS lebt von der Vielseitigkeit im Einsatz, von der Anzahl der Module und Templates, aber nicht von einem Schalter im Backend

Yetiie:

--- Quote ---erklär mir doch mal, warum ein Fremdzugriff auf eine Google-Datei Ladezeitoptimierend er sein soll als der Zugriff auf die gleiche Datei am lokalem Server.
--- End quote ---

Naja, der erste Teil stand ja schon oben:

Das  wichtigste Zauberwort dazu heißt Caching. Moderne Browser Cachen die Dateien, die sie geladen haben. Wurde eine Datei (auch wenn sie von einer anderen Seite aus aufgerufen wurde) schon mal geladen spart sich der Browser die Mühe beim zweiten mal. Also: Hat der Surfer schon mal eine Seite aufgerufen bei der z.B. die spezielle JQ-Datei von Google aus geladen wurde und kommt auf die WB-Seite, die die selbe Datei verlangt ... ist sie schon da. Referenziert man die großen Frameworks auf die Google-Bibliothek ist die Wahrscheinlichlicke it recht hoch, dass sie schon von anderen Seiten gecacht ist ... naja die Menge machts. Ohne diesen Trick (auch das Cachen der Seiten des eigenen Webauftritts, weil auch dort Dateien auf der zweiten aufgerufenen Seite oder beim Wiederbesuch receicelt werden) wären die Lade-Gechwindigkeiten in den Browsern deutlich langsamer.

Das zweite Zauberwort heißt Hochverfügbarkeitss erver. Es ist sehr unwahrscheinlich, dass ein Server bei einem 0-8-15-Provider an die Übertragungsgeschwi ndigkeiten und Verfügbarkeiten der Google-Server heran kommt, zumindest was die üblichen (auch großen) Hoster von WB-Seiten betrifft. Die Hochverfügbarkeit gilt übrigens auch für andere Server wie die von MS, FB, Twitter, Amazon ... unter Beweis stellt das Googl laufend unter anderem Analytics oder Google-Schriften bei denen genau diese Technik die Grundlage bildet ... und dort nicht wirklich in Frage gestellt wird genauso wenig wie bei der Einbindung von FB-, Google-Werbenetzwerk oder Twitter-Codes. Das alles würde nicht funktionieren, würde die Technik nicht entsprechend überdurchschnittlic h performant funktionieren. Also: auch diesbezüglich schnellere Reaktion und schnellere Ladezeiten.

Eine interessante Infos dazu: Der Effekt dieser Hochverfügbarkeits-Server ist messbar. Amazon: zwei zehntel(!) langsamere Ladzeiten (wir reden vom Durchschnittswert) = Umsatzverluste je Std. im sechstelligen Bereich (kein Witz, von Amazon selbst gezielt reduziert und getestet). Für die meisten WB-Seiten möglichweise nicht relevant weil andere Liga und andere Aufgabenstellung. Aber es macht die von Dir erfragte Wirksamkeit der Spitzen-Technik auch von dieser Seite aus deutlich.





--- Quote --- Es geht nicht mehr um "das einfachste CMS der Welt", sondern nur noch darum, es den Fortgeschrittenen einfacher zu machen.
--- End quote ---

Bei dem Wunsch nach Einfachheit leigen wir auf einer Linie. Das ist aber kein Wiederspruch dazu, es gerade den Fortgeschrittenen schmackhaft zu machen. Denn sie erstellen die schönen Templates (egal ob mit oder ohne TWIG) ... und sind die Multiplikatoren. Und ich weiß nicht, ob die Attraktivität für diesen Personenkreis in der letzten Zeit zugenommen hat. Die Rückmeldungen und beobachtbaren Reaktionen häufen sich, das WB in dieser wichtigen Gruppe eine zunehmend geringere Rolle spielt.

Außerdem: So gesehen sieht die Zukunft von WB düster aus. Das Abschaffen von 'echo' oder - was ich heute zufällig gesehen habe - von 'Konstanten' wie die dem entgegen gestellte zunhemende Klasserities (sei sie nun notwendig oder nicht) ... was ich hier jetzt nicht generell kritisieren möchte und natürlich ein wenig überspitzt Formuliert ist ... geht genau in die von Dir bedauerte Richtung. Und in diesem Punkt teiel ich Deine Befürchtung ganz generell.





--- Quote ---Das als Pressemeldung wird genau so ein Hammer wie Bilder von mir, wo ich naggisch vorm Reichstag tanze 
--- End quote ---

Ich denke, da haben wir unterschiedliche Vorstellungen aber auch Erfahrungen in dem Bereich dieser Arbeit.  Lass uns das bitte mal beiseite schieben und einfach sagen: unterschiedliche Sichtweisen und Vorstellungen sind auch hier erlaubt. Allgemein und ohne groß oder allzuweit auseinander zu liegen denke ich kann man aber wohl sagen: Wünschenswert für WB wären sowohl (mehr) Themenfutter wie auch eine aktive(re) Betätigung auf diesem Gebiet, was WB tatsächlich(!!!) mit extrem hoher Wahrscheinlichkeit mehr Zuwachs bringen würde als eine neue Version oder besser programmierter Code  ;-)






--- Quote ---Die Projekte, die ich in diesem Jahr mit WB gemacht habe, nutze alle die aktuelle JQ 1.11,
--- End quote ---

Mmmh ... mein WB nutzt 1.7.1 wenn ich mich gerade nicht verguckt habe. Die meisten meiner Seiten würden mit 1.1 nicht laufen ... und einige Module hier haben doch trotz allem recht aktuelle JQ-Module integriert meine ich ... also 1.1 macht mich da irgendwie stutzig ... aber eine feurige Hand möchte ich dafür jetzt nicht riskieren ... und register_frontend ist mir speziell diesbezüglich tatsächlich nun auch wirklich egal, gerade deshalb, weil ich die Version nicht steuern kann, - fände eine Einsatzmöglichkeit in der oben beschriebenen Form aber durchaus reizvoll.





--- Quote ---Ich neige ja dazu, eine Beitragstrennung zu beantragen
--- End quote ---

Naja. Off-Topic ist das schon länger. Das stimmt.
Aber soweit ich verstanden habe war Deine Fragestellung heute früh schon gelöst, oder habe ich das falsch verstanden gehabt? Und die Entwicklung zum Thema JQ schneller Laden war ja eigentlich keine zwanghafte ...  ;-)

DarkViper:
Eine kleine Erinnerung so zwischendurch:
Vor (soweit mein Alzheimer mitspielt) ca. ein bis anderthalb Jahren hatte Google einen netten Systemausfall... und hunderttausende Websites waren über mehrere Stunden nicht mehr erreichbar....  weil alle vergeblich versucht haben JS von Google in ihren Head zu laden...  :-o :-o :-o
Was auf meinem Server liegt, wird ausgeliefert wenn meine Seite erreichbar ist.. unabhängig von fremden Infrastrukturen... und ohne Tracking. ;-)

Und Uwe, auch wenn auf OOP umgestellt wird... das ursprüngliche Ziel von WB bleibt mindestens solange erhalten, solang ich hier Code produziere. ;-)

Ältere werden lernen müssen... und Jüngere? Ich seh's an meinem Sohn. Der hat Probleme mit dem alten Spagetticode... dafür kombiniert er Klassen im Schlaf.

Manuela

Navigation

[0] Message Index

[#] Next page

[*] Previous page