„Google hat gerade HTML erfunden“

[Robert B.]

Moin,

so fasst jemand auf Twitter den AMP-Blogeintrag Faster AMP on the origin: AMP + SSR = ⚡ zusammen. Googles Plan: einen Teil der Seite ohne den AMP-Code bereits auf dem Server rendern. Erkenntnis: bis zu 50% Performance-Gewinn. Mit den Worten von Florens Verschelde:

What if, instead of building the DOM in JavaScript in the browser, you could serialize the DOM in a text format that the browser could parse immediately on page load?

Das klingt verheißungsvoll – vor allem wenn ich mir anschaue, wie lange der AMP-unterstütze AMP-Blogbeitrag bei mir lädt, bis etwas angezeigt wird: Laut Screencast satte 8 Sekunden, wenn man mit µMatrix externe Ressourcen blockiert. Das A in AMP steht doch nicht für accelerated, oder? 😉

Viele Grüße
Robert

[Emil]

Moin,

What if, instead of building the DOM in JavaScript in the browser, you could serialize the DOM in a text format that the browser could parse immediately on page load?

DOM in a Text Format serialisiert ist HTML.

MFG

[Gunnar Bittersmann]

@@Emil

What if, instead of building the DOM in JavaScript in the browser, you could serialize the DOM in a text format that the browser could parse immediately on page load?

DOM in a Text Format serialisiert ist HTML.

Glückwunsch, du hast die Ironie (nicht) bemerkt.

LLAP 🖖

[Emil]

@@Emil

What if, instead of building the DOM in JavaScript in the browser, you could serialize the DOM in a text format that the browser could parse immediately on page load?

DOM in a Text Format serialisiert ist HTML.

Glückwunsch, du hast die Ironie (nicht) bemerkt.

Ist das hier ein Ironieforum? Ich bekomme immer mehr den Eindruck. Plusminus anstelle Fachkompetenz. Weiter so!

PS: Stiftung WT hat festgestellt, daß ein stilles Mineralwasser keine Kohlensäure enthält.

[Gunnar Bittersmann]

@@Emil

Ist das hier ein Ironieforum?

Ein Mitdenk-Forum. Die Energie des Verstehens.

LLAP 🖖

[Emil]

Ist das hier ein Ironieforum?

Ein Mitdenk-Forum. Die Energie des Verstehens.

Verstehe. Das zeigen ja die vielen Beiträge hier. Und hauptächlich deren Bewertungen. Da kann man sich so einiges dabei denken. MFG

[robertroth]

Lieber Rolf,

Da kann man sich so einiges dabei denken.

Das solltest Du. Fürwahr!

Spirituelle Grüße
Euer Robert

[Der Martin]

Hallo,

PS: Stiftung WT hat festgestellt, daß ein stilles Mineralwasser keine Kohlensäure enthält.

<loriot>Ach. Ach was.</loriot>

Was ist eigentlich, wenn ein Vibrator bei der Stiftung Warentest mit "befriedigend" bewertet wird? Besser kann's doch nicht laufen ...

So long,
 Martin

[Emil]

Hallo,

Was ist eigentlich, wenn ein Vibrator bei der Stiftung Warentest mit "befriedigend" bewertet wird? Besser kann's doch nicht laufen ...

Nee, na !? LOL 😉

Hab schon überlegt, ein Dankeschreiben an mein Radio zu verfassen. Wenn die mich diesen Sommer nicht ständig daran erinnert hätten was zu trinken, ich wäre wohl verdurstet.

MFG

[TS]

Hello,

Was ist eigentlich, wenn ein Vibrator bei der Stiftung Warentest mit "befriedigend" bewertet wird? Besser kann's doch nicht laufen ...

Nee, na !? LOL 😉

Hab schon überlegt, ein Dankeschreiben an mein Radio zu verfassen. Wenn die mich diesen Sommer nicht ständig daran erinnert hätten was zu trinken, ich wäre wohl verdurstet.

Wie jetzt? Gab es bei Dir etwa noch Wasser?

Glück Auf
Tom vom Berg

[Emil]

Wie jetzt? Gab es bei Dir etwa noch Wasser?

Der Rhein hat dieses Jahr bis jetzt einen sehr ausgeglichenen Pegel. Was jedoch fehlt, sind die Niederschläge im Winter, was viele Bäume nicht verkraften. Eine ähnliche Situation hatten wir schonmal in den 80er Jahren.

Vom Inselsberg bis zum Brocken waren ist historisch gesehen stets die Winter die den Großteil der Niederschläge brachten, ich hab noch Karten da sind für den Brocken 2000 mm Niederschlag/Jahr angegeben und da hatte ich auch schonmal 3 m Schnee unter den Füßen.

Unsere Wälder jedenfalls sehen auch in den Niederungen derzeit nicht gerade gut aus. Selbst im Odenwald sterben 100jährige Buchen, das ist erschreckend.

MFG

[Rolf B]

Hallo Robert,

ich bin jetzt tatsächlich unsicher, ob die Idee Unsinn ist oder nicht.

Das Anliegen ist ja, dynamisch gerenderte Seiten zu beschleunigen, d.h. die Ladezeit von JS-Monstern wie REACT zu eliminieren. Wenn dann noch ein langsamer Client hinzukommt, ist auch das Rendering nicht das flinkeste - auch wenn React mit seinem virtuellen DOM sich Mühe gibt, das zu optimieren.

Wenn ich aber einen schnellen Server habe, wo React oder Angular oder ähnliche Brocken eh schon lokal vorliegen, und dann nur das DiffDOM in einem kompakten Format übertrage, mag das Ergebnis schon recht flink sein.

Die Frage, die wie üblich bleibt, ist: cui bono? Google ist nicht die Heilsarmee.

Rolf

[Emil]

Hi @Rolf B

HTML ist das Ergebnis einer mit textlichen Mitteln serialisierten Datenstruktur (DOM). Und daß Serializer die zeichenorientiert arbeiten ineffizient sind gegenüber Serializern die byteorientiert arbeiten ist allgemein bekannt.

Die Objekte des DOM nicht als HTML zu übertragen sondern als Binärdatei würde einen erheblichen Performanceschub bringen und außerdem viel weniger Bandbreite benötigen. MFG

[Gunnar Bittersmann]

@@Emil

Die Objekte des DOM nicht als HTML zu übertragen sondern als Binärdatei würde einen erheblichen Performanceschub bringen und außerdem viel weniger Bandbreite benötigen.

Zum einen glaube ich nicht an „erheblich“. Zum anderen ist es ein Riesenvorteil von HTML (und SVG u.a. XML), ein Textformat und kein Binärformat zu sein.

Und Text zu verarbeiten heißt Zeichen zu verarbeiten, nicht Bytes.

LLAP 🖖

[Der Martin]

Hallo,

Die Objekte des DOM nicht als HTML zu übertragen sondern als Binärdatei würde einen erheblichen Performanceschub bringen und außerdem viel weniger Bandbreite benötigen.

Zum einen glaube ich nicht an „erheblich“. Zum anderen ist es ein Riesenvorteil von HTML (und SVG u.a. XML), ein Textformat und kein Binärformat zu sein.

ACK. Und die Einsparung von Bandbreite dürfte auch eher gering ausfallen, zumal -wie eben festgestellt- HTML ein Textformat ist, das sich sehr gut komprimieren lässt (gzip-Übertragung).

Und Text zu verarbeiten heißt Zeichen zu verarbeiten, nicht Bytes.

Die Zeichen werden auch irgendwie wieder durch Bytes repräsentiert, aber das geht jetzt in Richtung Erbsenzählerei. Insofern: Ja, richtig, es sind Zeichen.

So long,
 Martin

[Gunnar Bittersmann]

@@Der Martin

das sich sehr gut komprimieren lässt (gzip-Übertragung).

gzip, seriously? Brotli, Zopfli.

Die Zeichen werden auch irgendwie wieder durch Bytes repräsentiert

Ja, Aber auf diese untere Ebene sollte man sich überhaupt nicht begeben. Das ist es ja, was Hotti immer wieder falsch macht.

LLAP 🖖

[Rolf B]

Hallo Gunnar,

vermutlich denkt er an sowas wie \x37\x01\x03\x66\x6f\x6f statt <section class="foo"> (mit einer wilden Zuordnung von \x37=section und \x01=class, \x03 ist die Länge des Textes "foo".

Problem ist nur, dass man dann ein standardisiertes Mapping von Element- und Attributnamen zu Binärcodes braucht und neue Elemente/Attribute über ein Extension-Verfahren implementieren muss.

Ach nein, es geht eleganter. Der Server liefert zu Beginn eine kompakte Liste von Elementen und Binärcodes für diese Elemente, so dass man keine zentrale, genormte Registry braucht. Optimalerweise gibt es Einbyte- und Zweibyte Codes, so dass man die häufiger verwendeten Namen kleiner codieren kann.

grübel, wo hab ich dieses déjà vu nur schon gesehen?

Rolf

[Christian Kruse]

Hallo Rolf,

Ach nein, es geht eleganter. Der Server liefert zu Beginn eine kompakte Liste von Elementen und Binärcodes für diese Elemente, so dass man keine zentrale, genormte Registry braucht. Optimalerweise gibt es Einbyte- und Zweibyte Codes, so dass man die häufiger verwendeten Namen kleiner codieren kann.

grübel, wo hab ich dieses déjà vu nur schon gesehen?

😂 made my day

LG,
CK

[Der Martin]

das sich sehr gut komprimieren lässt (gzip-Übertragung).

gzip, seriously? Brotli, Zopfli.

Häh? (oder schriftlich: Wie bitte?)

Nix verstehn,
 Martin

[Christian Kruse]

Hallo Martin,

das sich sehr gut komprimieren lässt (gzip-Übertragung).

gzip, seriously? Brotli, Zopfli.

Häh? (oder schriftlich: Wie bitte?)

Brotli, Zopfli.

LG,
CK

[Gunnar Bittersmann]

@@Christian Kruse

Häh? (oder schriftlich: Wie bitte?)

Brotli, Zopfli.

Wollt schon sagen: Fragen, die mit „Häh?“ beginnen, sind prädestiniert dafür, der Wikipedia gestellt zu werden. 😉

LLAP 🖖

[Rolf B]

Hallo Gunnar,

wobei Brotli und Zopfli nichts wesentlich anderes als gzip machen (Deflate mit LZ77 und Huffman), aber besser. Für einen vordefinierten Wert von „besser“...

Rolf

[Emil]

Es ist ein Trugschluß, daß Komprimierung die Performance verbessert. Das Gegenteil ist der Fall weil zuerst der Text wiederhergstellt werden muss und erst danach geparst werden kann, das sind schonmal 2 eigene Prozesse.

Ein Serializer auf Byteebene hingegen beginnt ab dem ersten angekommen Byte mit der Wiederherstellung der Daten ohne die ganze Datei erst in den Hauptspeicher lesen zu müssen.

MFG

[Rolf B]

Hallo Emipl,

Ein Serializer auf Byteebene hingegen beginnt ab dem ersten angekommen Byte

Äh, Du meinst sicher Deserializer 😉. Und die grundsätzlichen Probleme mit einem Binärformat hatte ich ja in meinem deja-vu Beitrag von 15:21 erwähnt...

Zum ZIP-Format: Ich bin nicht ganz sicher, aber ich meine, dass GZIP streamingfähig ist. D.h. nachdem Du ein paar hundert Bytes empfangen hast, kannst Du schon so viel auspacken, dass Du im zweiten Thread mit dem Aufbau des DOM anfangen kannst (bzw. im gleichen Thread, während der I/O-Buffer sich wieder füllt). Erstmal das komplette ZIP empfangen und dann erst auspacken ist sicherlich so ineffizient wie Du beschreibst, aber der von Dir geschilderte Effekt sollte sich durch geschickte Programmierung kompensieren lassen.

Serverseitig wird man beim ersten GZIPpen etwas mehr Vorlauf brauchen, weil es das LZ-Fenster gibt. Bei GZIP sind das 32K. Der Engpass ist aber typischerweise die Leitung, nicht der Server, so dass das nicht so ins Gewicht fallen dürfte, und bei statischen Ressourcen cached der Server das GZIP-Ergebnis ja auch.

Rolf

[Gunnar Bittersmann]

@@Rolf B

Zum ZIP-Format: Ich bin nicht ganz sicher, aber ich meine, dass GZIP streamingfähig ist. D.h. nachdem Du ein paar hundert Bytes empfangen hast, kannst Du schon so viel auspacken, dass Du im zweiten Thread mit dem Aufbau des DOM anfangen kannst

Ja, muss ja. Mit dem Rendern von Webseiten wird schon begonnen, bevor das gesamte HTML vorliegt.

(Dass das Rendern durch das Laden von CSS oder JavaScript geblockt wird, steht auf einem anderen Blatt.)

LLAP 🖖

[Robert B.]

Moin Emil,

Es ist ein Trugschluß, daß Komprimierung die Performance verbessert. Das Gegenteil ist der Fall weil zuerst der Text wiederhergstellt werden muss und erst danach geparst werden kann, das sind schonmal 2 eigene Prozesse.

Es ist ein Trugschluss, das ganze Szenario nur an einer Stelle anstatt von Anfang zu Ende zu betrachten. Man muss schauen, an welcher Stelle der Flaschenhals auftritt und ob man ggf. parallelisieren kann.

Ein Serializer auf Byteebene hingegen beginnt ab dem ersten angekommen Byte mit der Wiederherstellung der Daten ohne die ganze Datei erst in den Hauptspeicher lesen zu müssen.

Meines Wissens und meiner Erfahrung nach kann man selbst hier noch Performance gewinnen, indem man so viele Byte auf einmal verarbeitet, wie die Prozessorarchitektur vorsieht; sprich auf einem 64-Bit-Rechner ist das Verarbeiten von 8 Byte in einem Schritt 8-mal schneller als die Verarbeitung von 8 mal 1 Byte.

Viele Grüße
Robert

[Emil]

Die Objekte des DOM nicht als HTML zu übertragen sondern als Binärdatei würde einen erheblichen Performanceschub bringen und außerdem viel weniger Bandbreite benötigen.

Zum einen glaube ich nicht an „erheblich“.

Doch. Das lässt sich auch leicht nachweisen, Faktor 20 hab ich mal ermittelt.

Zum anderen ist es ein Riesenvorteil von HTML (und SVG u.a. XML), ein Textformat und kein Binärformat zu sein.

Natürlich. Niemand hat vor, Binärdateien händisch zu bearbeiten. Erst ein spezieller Deployprozess macht aus Textdateien maschinenlesbaren und performanten Bytecode.

MFG

[Felix Riesterer]

Lieber Rolf Rost,

Die Objekte des DOM nicht als HTML zu übertragen sondern als Binärdatei würde einen erheblichen Performanceschub bringen und außerdem viel weniger Bandbreite benötigen.

das ist vielleicht ein Vorteil, der aber jede Menge an Nachteilen mit sich bringt. Diese wiegen nicht nur meiner Meinung nach schwerer, als Dein Performance- und Bandbreiten-Vorteil. Die Nachteile, die mir sofort einfallen sind diese:

• Daten nicht mehr menschenlesbar
• Abwärtskompatibilität nur schwer realisierbar
• Festlegung auf einen Algorithmus, wie diese Daten auszuwerten sind (Stichwort Referenzimplementierung)

Vielleicht findet jemand anderes noch mehr?

Liebe Grüße

Felix Riesterer

[TS]

Hello,

des Pudels Kern steckt doch ganz woamders.

JavaScript ist doch für statische Seiten ohnehin nur dann sinnvoll, wenn clientspezifische Daten notwendig sind für den Bildaufbau, wenn man sich erheblichen Traffic sparen will (animierte Elemente), wenn nur einzelne Inhalte auf Useraktion nachgeladen werden sollen (AJAX).

Wenn man nun also alles wieder am Server vorausberechnen will, kann man auf JS, AJAX & Co. auch gleich verzichten. Und schlussendlich landen wir dann bei hochkomprimierten Bildern. Dann kann HTML auch wegfallen. Screenreader adé.

Fragte ich nicht neulich erst, wie lange HTML noch leben wird? ☆höhöhö☆

Glück Auf
Tom vom Berg

[Gunnar Bittersmann]

@@TS

JavaScript ist doch für statische Seiten ohnehin nur dann sinnvoll, wenn clientspezifische Daten notwendig sind für den Bildaufbau, wenn man sich erheblichen Traffic sparen will (animierte Elemente), wenn nur einzelne Inhalte auf Useraktion nachgeladen werden sollen (AJAX).

JavaScript ist erforderlich, wenn man

• einen sticky header umsetzen will
• ein Dropdown-Menü umsetzen will
• eine Box mit etlichem Textinhalt verlinken will
• …

LLAP 🖖

[Robert B.]

Hallo Gunnar,

JavaScript ist erforderlich, wenn man

• einen sticky header umsetzen will

Was ist hier der Unterschied zu position: sticky?

• ein Dropdown-Menü umsetzen will

Was fehlt beim CSS-Beispiel?

• eine Box mit etlichem Textinhalt verlinken will

???

Viele Grüße
Robert

[Gunnar Bittersmann]

@@Robert B.

JavaScript ist erforderlich, wenn man

• einen sticky header umsetzen will

Was ist hier der Unterschied zu position: sticky?

Das allein genügt nicht.

Beispiel 1: ohne JavaScript • mit JavaScript

Beispiel 2: ohne JavaScript • mit JavaScript

• ein Dropdown-Menü umsetzen will

Was fehlt beim CSS-Beispiel?

Die gute Bedienbarkeit. Guten Appetit!

• eine Box mit etlichem Textinhalt verlinken will

???

ganze Box verlinken

LLAP 🖖

[Robert B.]

Moin Gunnar,

danke für die Beispiele.

Das allein genügt nicht.

Beispiel 1: ohne JavaScript • mit JavaScript

Beispiel 2: ohne JavaScript • mit JavaScript

Ich sehe vom Handling her in beiden Beispielen keinen Unterschied. Was sollte man denn sehen?

• eine Box mit etlichem Textinhalt verlinken will

???

ganze Box verlinken

Achso, ein Insider (hatte den Thread nicht auf dem Schirm).

Es sind jedenfalls Beispiele, in denen Googles Hack(TM) nicht unbedingt einen Vorteil bringt, wenn ich das sehe.

Viele Grüße
Robert

[Gunnar Bittersmann]

@@Robert B.

Beispiel 1: ohne JavaScript • mit JavaScript

Beispiel 2: ohne JavaScript • mit JavaScript

Ich sehe vom Handling her in beiden Beispielen keinen Unterschied. Was sollte man denn sehen?

Im Beispiel 1 bleiben fokussierte Links bei Tastaturbedienung (mit Tab-Taste von Link zu Link) ohne JS unsichtbar unter dem Header bzw. Footer verschwunden. Das JavaScript scrollt diese bei Bedarf in den sichtbaren Bereich.

Im Beispiel 2 ist ohne JS nach Auswahl im Menü die Überschrift des jeweiligen Artikels unter dem Header verborgen.

Es sind jedenfalls Beispiele, in denen Googles Hack(TM) nicht unbedingt einen Vorteil bringt, wenn ich das sehe.

Das hatte nichts mit dem ursprünglichen Thema zu tun, sondern bezog sich auf TS’ „JavaScript ist doch nur …“.

LLAP 🖖

[robertroth]

Liebe Mitdenker, liebe Wissende, liebe Neugierige,

JavaScript ist doch für statische Seiten ohnehin nur dann sinnvoll, wenn clientspezifische Daten notwendig sind für den Bildaufbau, wenn man sich erheblichen Traffic sparen will (animierte Elemente), wenn nur einzelne Inhalte auf Useraktion nachgeladen werden sollen (AJAX).

JavaScript ist erforderlich, wenn man

• einen sticky header umsetzen will

also keine total statische Seite

• ein Dropdown-Menü umsetzen will

also keine total statische Seite

• eine Box mit etlichem Textinhalt verlinken will

also keine total statische Seite

• …

Spirituelle Grüße
Euer Robert

[Auge]

Hallo

JavaScript ist erforderlich, wenn man

• einen sticky header umsetzen will

also keine total statische Seite

Wie kommst du darauf?

• ein Dropdown-Menü umsetzen will

also keine total statische Seite

Wie kommst du darauf?

• eine Box mit etlichem Textinhalt verlinken will

also keine total statische Seite

Wie kommst du darauf?

Bedienst du dich vielleicht einer etwas abseitigen Definition für eine „statische Seite“?

Eine statische Seite ist eine Seite, die vom Server so ausgeliefert wird, wie sie nachher im Browser angezeigt werden soll. Dabei kann die Seite als HTML-Dokument fix und fertig auf dem Server liegen oder dynamisch mit einer serverseitigen Technik eben dort zusammengepröckelt werden. Wichtig für die Definition ist, dass die Seite im Browser nicht durch nachladen neuer/anderer Teile (üblicherweise per JS) verändert wird. Nach der Definition, die du hier benutzt, könnte auch die Einbindung eines animierten GIFs (ein dynamisches Element) dazu führen, die Seite als nicht statisch zu bezeichnen.

Tschö, Auge

[TS]

Hello,

jede (bedingte) Änderung am Document odef dessen Darstellung, die der Client nach Auslieferung noch vornimmt, insbesondere nach/durch Benutzereinwirkung, entziehen dieser den Anspruch, als statisch zu gelten!

Dies findet vermulich spätestens bei der Wahl von Device, Browser, Schrifttyp usw. seine Grenze.

Selbst die Umschaltung durch "responsive Design" ist da schon fragwürdig.

Stell Dir einfach den Richter im Prozess vor, der den Zeugen danach fragt, was er genau gesehen hat.

Glück Auf
Tom vom Berg

[Auge]

Hallo

jede (bedingte) Änderung am Document odef dessen Darstellung, die der Client nach Auslieferung noch vornimmt, insbesondere nach/durch Benutzereinwirkung, entziehen dieser den Anspruch, als statisch zu gelten!

Demnach sind auch Seiten, die keine Größenangaben zu den in ihnen eingebundenen Bildern haben, dynamisch, da sich das Layout im oder, bei langsamer oder stockender Internetverbindung, auch nach dem offensichtlichen Ende des Ladeprozesses teilweise gravierend ändert.

Deine Definition greift meiner Meinung nach zu kurz. Seitenelemente wie eine mehrstufen Navigation, die rein clientseitig auf- und zugeklappt wird, ohne dafür neue Inhalte vom Server nachzuladen, machen zwar die Ansicht der Seite dynamisch (es gibt veränderliche Elemente, die aber alle bereits mit dem Laden der Seite vorhanden sind), machen die Seite an sich (nach meiner Definition) aber nicht zu einer dynamischen Seite.

Dieses Forum ist ein gutes Beispiel für dynamische Seiten. Es beinhaltet dynamische Seiten, weil auch in bereits geladende Seiten neue Inhalte nachgeladen werden (neue Beiträge werden in den Threadbaum eingeblendet, die Tatsache, dass jemand auf einen eigenen Beitrag geantwortet hat, wird mit einem dynamischen, neuen Element „verkündet“, u.s.w.).

Selbst die Umschaltung durch "responsive Design" ist da schon fragwürdig.

Das ist, außer bei denen, die ein Design testen, auf dem jeweiligen Gerät wegen des responsiven Designs höchst selten dynamisch. Bestenfalls noch dann, wenn die Größe des Browserfenster auf dem Desktop verändert wird oder wenn man auf dem Smartphone vom Portrait- zum Landscape-Modus wechselt. Ansonsten ändert sich da normalerweise nichts.

Tschö, Auge

[TS]

Hello,

ich bin kein Richter.

Ich kenne nur aus mehreren Fällen von Kunden/Freunden die einhellige Auslegung:

Ist das Ergebnis verlässlich reproduzierbar, wird es als Beweis anerkannt, ändert sich im Kern von außen nicht reproduzierbar (ständig) etwas, wird es nicht anerkannt. Die Grauzonen sind verschieden groß, verschieden grau jnd manchmal auch überraschend bunt. Dein Einwurf mit den Bildern kann da also durchaus übel zutreffen.

Das ist ebenso, wie auf hoher See. Ist die Sandbank plötzlich verschwunden, kann man nicht mehr darauf auflaufen und umgekehrt.

Glück Auf
Tom vom Berg

[Auge]

Hallo

Ich kenne nur aus mehreren Fällen von Kunden/Freunden die einhellige Auslegung:

Ist das Ergebnis verlässlich reproduzierbar, wird es als Beweis anerkannt, ändert sich im Kern von außen nicht reproduzierbar (ständig) etwas, wird es nicht anerkannt.

Meine Definition, dass eine Seite als dynamisch gilt, wenn in der geladenen Seite neue Inhalte vom Server nachgeladen werden, ist gelinde gesagt unvollständig. Natürlich gehören Seiten, die auf dem Server zusammengebaut werden, normalerweise ebenfalls zu den dynamischen Seiten, schließlich wird in den allermeisten Fällen wechselnder Inhalt in die Seiten eingebaut. Damit ist der Zustand der Seite natürlich auch nicht reproduzierbar, weil die Seite normalerweise zu verschiedenen Zeiten verschiedene Inhalte enthält (Foren, Nachrichtenportale, etc.).

Die Grauzonen sind verschieden groß, verschieden grau jnd manchmal auch überraschend bunt. Dein Einwurf mit den Bildern kann da also durchaus übel zutreffen.

Vorausgesetzt es handelt sich um ein statisches Dokument, ändert sich der Inhalt dieses HTML-Dokuments nicht, auch wenn Teile einer Navigation rein clientseitig mit CSS und/oder JS ein- oder ausgeblendet werden, ohne dass dabei Teile vom Server nachgeladen werden. Die Navigation ist in diesem Fall von vornherein Bestandteil des DOM und ist, wenn technisch sauber umgesetzt, immer erreichbar.

Wie soetwas vor Gericht gewertet wird, steht auf einem anderen Blatt und war hier bisher nicht Bestandteil der Diskussion.

Tschö, Auge

[marctrix]

Hej Auge,

Ist das Ergebnis verlässlich reproduzierbar, wird es als Beweis anerkannt, ändert sich im Kern von außen nicht reproduzierbar (ständig) etwas, wird es nicht anerkannt.

Meine Definition, dass eine Seite als dynamisch gilt, wenn in der geladenen Seite neue Inhalte vom Server nachgeladen werden, ist gelinde gesagt unvollständig. Natürlich gehören Seiten, die auf dem Server zusammengebaut werden, normalerweise ebenfalls zu den dynamischen Seiten,

So kenne ich auch die Abgrenzung statisch/dynamisch.

Statisch: ein HTML-Dokument.

Dynamisch: "etwas" verändert die Seite.

Der Hinweis von @TS in Bezug auf Responsivität, die allein mit CSS umgesetzt wird, hat etwas für sich.

Und einemitgleiferte JS-Datei, die nichts vom Server nachlädt, aber eine Klasse o.ä. einfügt, damit ein Drop-Down-Menü funktioniert, würde ich jetzt nicht als Ausschlusskriterium sehen wollen. Auch kein JS, das lediglich Größen misst von Kästen o.ä. und das dem CSS zugänglich macht. Ist ja nichts anderes, was man anders auch mit CSS erreicht, wenn man vx oder ähnliches verwendet.

Ja, die Welt wird komplexer und die Grauzonen wachsen.

You know nothing, John Snow!

Marc

[Gunnar Bittersmann]

@@TS

jede (bedingte) Änderung am Document odef dessen Darstellung, die der Client nach Auslieferung noch vornimmt, insbesondere nach/durch Benutzereinwirkung, entziehen dieser den Anspruch, als statisch zu gelten!

Aha. Wenn sich beim Überfahren eines Links der Mauscursor ändert, ist das also eine Änderung am Dokument. Ergo: Es gibt überhaupt keine statischen Webseiten. Wieder was gelernt. Nicht.

LLAP 🖖

[Tabellenkalk]

Hallo,

Wenn sich beim Überfahren eines Links der Mauscursor ändert,

onMouseMove.SetMouseXY(0,0);

Gruß
Kalk

[Der Martin]

Hallöchen,

onMouseMove.SetMouseXY(0,0);

sehr schön! ;-)

Sie haben die Position des Mauszeigers verändert.
Windows muss neu gestartet werden, damit die Änderung wirksam wird.

*scnr*,
 Martin

[Gunnar Bittersmann]

@@robertroth

also keine total statische Seite

Ob eine Seite statisch ist oder nicht, hängt an ihrem Inhalt, nicht an dessen Darstellung.

Und selbst bei der Darstellung sind sticky header und verlinkte Box statisch; allenfalls ein Dropdown-Menü hat was Dynamisches an sich.

LLAP 🖖

[Robert B.]

Hallo Tom,

man kann natürlich auch HTML als serialisiertes DOM im Sinne des Blogartikels auffassen 😉

Viele Grüße
Robert

[Felix Riesterer]

Lieber TS,

Wenn man nun also alles wieder am Server vorausberechnen will, kann man auf JS, AJAX & Co. auch gleich verzichten.

sehr richtig. Das war "des Pudels Kern" hinter den verlinkten Ausgangsquellen.

Und schlussendlich landen wir dann bei hochkomprimierten Bildern. Dann kann HTML auch wegfallen. Screenreader adé.

Dass Du immer gleich übertreiben musst. kopfschüttel

Liebe Grüße

Felix Riesterer

[TS]

Hello, mein lieber Felix,

Wenn man nun also alles wieder am Server vorausberechnen will, kann man auf JS, AJAX & Co. auch gleich verzichten.

sehr richtig. Das war "des Pudels Kern" hinter den verlinkten Ausgangsquellen.

Und schlussendlich landen wir dann bei hochkomprimierten Bildern. Dann kann HTML auch wegfallen. Screenreader adé.

Dass Du immer gleich übertreiben musst. kopfschüttel

Und außerdem dies?

Während einer Anhörung zu dem Gesetzentwurf verriet Senator John Rockefeller die wahre Absicht, die hinter dem Gesetzentwurf steckte, als er sagte: „…ob es nicht besser gewesen wäre, wenn wir das Internet nie erfunden hätten…“,  

;-P

Glück Auf
Tom vom Berg

[Robert B.]

Hallo Rolf,

die Idee ist Teile von Seiten, die ich bereits vorausberechnen kann, sozusagen zu „cachen“, d.h. auf dem Server zu rendern. Der zitierte Kritikpunkt zielt genau darauf ab, dass es seit Anfang der 1990er bereits ein sehr ausgereiftes Datenformat zur Serialisierung des DOM gibt: nämlich HTML. Man könnte daher seine serverseitige Logik gleich verwenden HTML zu erzeugen. Der Performance-Nachteil so mancher „moderner“ Webanwendung kommt doch genau daher, dass das UI tatsächlich „programmiert wird“ − aber nicht in HTML, sondern wirklich JavaScript mit megabyte-weise Frameworks obendrauf.

Viele Grüße
Robert

[TS]

Hello,

[•••] aber nicht in HTML, sondern wirklich JavaScript mit megabyte-weise Frameworks obendrauf.

und da könnte man alternativ auch die wirklich guten nehmen, und den Browsern deren Funktionen (Klassen, Methoden) als OS-Erweiterung einpflanzen. So ähnlich ist es doch auch schon mit JQuery zuzrück zu "New Vanilla" gelaufen. Der Extranutzen von JQuery ist doch inzwischen fast vollständig JS-Basisbestandteil.

Das hätte dann zur Folge, dass die Funktionalität dort bleiben würde, wo sie auch Anwendung finden soll: auf dem Client. Und die clientabhängigen Eigenschaften und Daten müssen dann nicht dem Server bekannt gemacht werden und können dann auch nicht dort gesammelt und verdichtet werden.

Glück Auf
Tom vom Berg

[Felix Riesterer]

Lieber TS,

und da könnte man alternativ auch die wirklich guten nehmen,

welche da Deiner Meinung nach wären...?

und den Browsern deren Funktionen (Klassen, Methoden) als OS-Erweiterung einpflanzen.

Da freut sich der Hacker, wenn zusätzliche Komplexität eingebaut wird, denn da kann man so schön exploiten.

So ähnlich ist es doch auch schon mit JQuery zuzrück zu "New Vanilla" gelaufen. Der Extranutzen von JQuery ist doch inzwischen fast vollständig JS-Basisbestandteil.

Du bedenkst aber schon, dass computing-Leistung auf dem Client so richtig teuer ist, weil mobile Hardware unter allen Umständen Strom sparen möchte, der Server im Rechenzentrum aber nicht.

Das hätte dann zur Folge, dass die Funktionalität dort bleiben würde, wo sie auch Anwendung finden soll: auf dem Client.

Das Konzept der graceful degradation und des progressive enhancement sollten hier ebenfalls greifen und dem Server die Last überlassen, ein Dokument zu serialisieren, welches dann mit minimalem(!!!) Aufwand auf der Clientseite eventuell noch ein bisschen angepasst werden soll.

Und die clientabhängigen Eigenschaften und Daten müssen dann nicht dem Server bekannt gemacht werden und können dann auch nicht dort gesammelt und verdichtet werden.

AWP hat unter Garantie (meine Meinung) auch die Absicht, Nutzerverhalten zu protokollieren. Darum der Hype. Ich fasse das nicht mit der Beißzange an und ärgere mich jedes Mal, wenn mein Desktop-Browser eine Seite lädt und ich dabei einige Sekunden warten muss, bis nach beendetem Ladevorgang endlich etwas auf dem Bildschirm erscheint!

Liebe Grüße

Felix Riesterer

[robertroth]

Lieber Felix,

und da könnte man alternativ auch die wirklich guten nehmen,

welche da Deiner Meinung nach wären...?

und den Browsern deren Funktionen (Klassen, Methoden) als OS-Erweiterung einpflanzen.

Da freut sich der Hacker, wenn zusätzliche Komplexität eingebaut wird, denn da kann man so schön exploiten.

Und wenn die ständig neuen JS-Bibliotheken nachgeladen werden, haben die Hacker keine Ansatzpunkte?

Spirituelle Grüße
Euer Robert

[Felix Riesterer]

Lieber robertroth,

Und wenn die ständig neuen JS-Bibliotheken nachgeladen werden, haben die Hacker keine Ansatzpunkte?

was weiß ich schon. Meine Bibliotheken halten sich in sehr engen Grenzen. Auch ich arbeite daran, möglichst kein jQuery mehr einzusetzen, welches ich damals dachte, zur Modernisierung meines Projektes einsetzen zu müssen.

Liebe Grüße

Felix Riesterer

[marctrix]

Hej TS,

Das hätte dann zur Folge, dass die Funktionalität dort bleiben würde, wo sie auch Anwendung finden soll: auf dem Client.

Das wäre ein Anwendungsfall für eine native App IMHO. Die wird dann auch in einer Sprache geschrieben, die hoffentlich effizienter ist als JS…

Und selbst dann kann es sinnvoll sein, den/einen Server mitarbeiten zu lassen (siehe Posting von @Felix Riesterer)

Marc

[robertroth]

Liebe Mitdenker, liebe Wissende, liebe Neugierige,

ich bin jetzt tatsächlich unsicher, ob die Idee Unsinn ist oder nicht.

Das Anliegen ist ja, dynamisch gerenderte Seiten zu beschleunigen, d.h. die Ladezeit von JS-Monstern wie REACT zu eliminieren. Wenn dann noch ein langsamer Client hinzukommt, ist auch das Rendering nicht das flinkeste - auch wenn React mit seinem virtuellen DOM sich Mühe gibt, das zu optimieren.

Für mich besteht da immer nur die Frage: welche Daten des Users muss ich stattdessen zuvor an den Server senden, damit der die Arbeit machen kann?

Spirituelle Grüße
Euer Robert