Hallo alle

Angenommen, ich muss eine Tabelle mit 100 Zeilen ausgeben, dann sähe der Quelltext etwa so aus:

Dies erzeugt einen ziemlich grossen Quelltext, welcher einerseits vom Server hochgeladen muss und andererseits vom Client wieder runtergeladen werden muss.

Wäre es eine gute Idee, statt dessen folgenden Code zu benutzen?

Nun gut, in diesem Beispiel sieht es nicht wirklich nach weniger Code aus im 2. Codelisting, aber wenn da noch Verzierungen, Schnickschnack etc. hinzukommen würden für das Design könnte man da garantiert einiges an Code sparen!
Voraussetzung wäre halt einfach, dass JavaScript aktiviert wäre, aber wenn dies für die restliche Applikation sowieso vonnöten wäre, dann wäre das ja in dem Sinne schon gegeben.

Was haltet ihr von dieser Technik? Sie würde sehr viel Uploadbandweite und Downloadbandweite beim Benutzer sparen! Was spricht evtl. dagegen?

Liebe Grüsse
Josh

Wieso nicht <div> benutzen und die ganzen Verzierungen im CSS definieren ? Wenn sich Verzierungen wiederholen kann man ja auch schon eine Menge Code ersparen.

Gegen JS spricht ja das übliche:
Kein JS aktiviert.
Suchmaschinen verstehen es nicht...
Na ja... Es ist einfach suboptimal.

CSS ist viel besser und bringt ein Vielfaches an Flexibilität. Eine gute Anleitung vorrausgesetzt. (Gutes Buch wie: CSS Praxis).

Ich würde auf jeden Fall vermeiden, dass JS Pflicht ist, um die Seite anzuschauen. JS sollte immer nur zur Unterstützung und Verzierung sein, also ablaufende Timer und andere Spielereien, die aber nicht zwingend nötig sind.
Wenn du sagst, dass die Seite sowieso JS braucht, würde ich dort erstmal optimieren
Dann lieber mit GZIP vom Server packen lassen und versenden...

@ kolibali:

Je nach Anforderung sind das sicher Killerkriterien. Aber CSS kann sehr mühsam sein, wenn es z.B. um dynamische Masse geht etc.

Ein weiterer Vorteil von JS: man kann es in externe Dateien auslagern und vom Browser cachen lassen, womit wieder viel Bandweite gespart werden kann.

@ Mike:

Vielleicht sollte ich meine Ansprüche etwas präzisieren.
Ich arbeite mit Templates, und somit kann ich jederzeit Templates für Ottonormalverbraucher erstellen und einsetzen, welche *jeder* Browser versteht.
Wenn ich aber etwas mehr herausholen möchte aus einer Applikation, so könnte ich einen optimierten Templateskin anbieten, welcher JS benötigt, dafür aber oben genannte Vorteile bringt.
Standard wäre natürlich der Ottonormalverbraucherskin, welcher auch von SuMas gut gelesen werden kann.

Mhm hast du dir mal angesehen wie viel du dir wirklich sparst?
Ohne whitespace ist das nicht so viel:

Ansonsten hilft vielleicht output buffering mit gzip, unter PHP mit ob_gzhandler eine feine Sache, nehme aber mal das du das auch unter Java irgendwie findest.

Tipp für die Leseratten:
„Speed up your Site“, lohnt sich wirklich, selbst wenn man die meisten Tricks kennt motviert es wieder zu Optimieren.
(Ich glaub zu dem Buch habe ich hier mal sogar ein kurzes review gepostet, konnte es aber nicht finden...).

[Ayom Edit: Ja hast Du. Hier: http://www.ayom.com/topic-5489.html]

Wie gesagt, wenn da noch z.B. verschiedene Formatierungen, CSS, Links etc. für jeden Eintrag hinzukommen, dann können das richtige Bandwürmer werden.
Brauche ich für jeden Eintrag z.B. noch Links à la

<a href="xxx.php?session=asdfasdfasf&show=names&action=delete&id=110">Löschen</a>
<a href="xxx.php?session=asdfasdfasf&show=names&action=rename&id=110">Umbenennen</a>
<a href="xxx.php?session=asdfasdfasf&show=names&action=edit&id=110">Editieren</a>

dann brauche ich nur die ID zusätzlich im Funktionsaufruf zu übergeben, und statt 100x obigen Code benötige ich ihn nur 1x.

Was ist denn dynamische Masse?

Wenn eine dynamisch erzeugte große "Code-Masse" da ist und du die Masse dann wieder zurückfährst, indem du Javascript-Schleifen einführst, ist bei mir die Frage ob du die Masse nicht gleich verhindern kannst?

Entweder das intelligente bandbreiten-schonende Design steckt im Javascript oder im CSS.
Die Wartbarkeit sinkt jedenfalls bei der Javascript-Version, wenn du nicht mit einer sehr guten Dokumentation gegensteuerst.

Ich bin der Meinung, dass man Komprimierung dem Protokoll überlassen sollte und wie oben genannt einfach die Zip-Komprimierung im Server anmachen sollte.

Damit meine ich z.B. Höhe / Breite von Tabellen, welche nicht fix sind, also z.B. nach unten gestreckt werden.

Danke für die Meinung. Im Allgemeinen bin ich auch vollkommen dieser Meinung, doch es geht mir darum, ein Bisschen zu experimentieren mit neuen Techniken.

Das mit den Whitespaces rauslöschen schaut zuwar im notepad gut aus, bringt aber effektiv nicht sehr viel.

Wenn das Kriterium die Daten sind, die vom Server zum Client geladen werden, solltest Du Dir mal AJAX anschauen.

http://www.adaptivepath.com/publications/e...ives/000385.php

Du kannst aus der DB ein xml-File generieren und diese mit AJAX in's html file laden.
das heisst, du ladest keine "table"-tags, keine "div" tags oder ähnliches im html-file sondern nur der Teil des HTML-Files der das layout definiert, und das xml-file mit den Daten separat. Das XML kannst du mit dynamisch mit JS und CSS in's HTML schreiben.

Ich habe dies schon in ein einigen projekten eingesetzt!

Bei einem Page-Request werden nurnoch die Daten geladen also keine Bilder, keine scripts und kein html-gerüst.

Mehr kann man mit den heutigen technologien nicht optimieren.

Googlemaps zum beispiel arbeitet mit dieser Technologie.

Gruss

Spaceman007

Ajax ist DIE Zukunft für Webapplikationen (!=Infoseiten)

Beispiele:
Google Mail (praktisch kein Refresh der ganzen Seite)
Google Suggest
http://map.search.ch
http://www.ceiton.net/winlike/73_sample_xmlhttprequest.html

Mehr Infos zu Ajax gibts bei Wikipedia

Wieso sollte man die ganze Page neu laden um ein Suchresultat andersrum zu sortieren?
Und ja, es ist zeit Javascript vorauszusetzen. Wer heute noch ohne JS durchs Netz tuckert ist auf der Suche nacht TEXT, wer Applikationen will, soll JS einschalten.

Gruss Sandro

Ps: Josh, du hast quasi AJAX erfunden. Bist bloss nicht der Erste...

Mich schreckt diese Technik eher ab. Heutzutage sind Bandbreiten nicht mehr so ein Problem wie vor Jahren, und die allermeiste Bandbreite wird für Bilder (oder Animationen, Flash etc.) verbraucht. Vor zehn Jahren wär ich begeistert über diese Erfindung

Der effektive HTML-Source einer Seite ist meistens sehr klein. Wenn er zu aufgeblasen ist, dann darum, weil nicht sauber mit CSS gearbeitet wird und/oder weil CSS und Javascript nicht in separate Dateien ausgelagert sind. Im Idealfall hat jede Zelle einer Tabelle genau einen CSS-Tag und fertig, keine weiteren Font- oder Rahmen- oder sonstigen Formatierungen in einer Zelle. Die langen Links gehören (zu einer Applikation) halt einfach irgendwie dazu; man könnte sie mit Javascript etwas verkürzen (im Stil vom Dotnet-Postback-Prinzip, ich weiss nicht obs bei PHP etwas ähnliches gibt, aber sonst gibts ja rewrite).

Mit der erwähnten Technik wird ein Teil der Darstellungslogik vom Server auf den Client verlegt. Und gerade bei der Darstellung gibts immer noch Browserunterschiede, deshalb find ich es heikel, dies dem Client zu überlassen.

So lange Tabellen werden ja mehrheitlich zum Anzeigen und/oder Bearbeiten von Daten verwendet. Aus Benutzersicht ist eine zu lange Tabelle aber nicht sehr bequem, er muss dann zuviel scrollen und verliert schnell die Übersicht, weil die Titelzeile verschwindet. Besser wäre, die Daten in mehreren blätterbaren Seiten darzustellen, z.B. 25 Records pro Seite. Damit wäre automatisch auch der HTML-Source pro Seite verkleinert.

Griessli
Irene

Man bedenke, dass die Mehrheit der Internetnutzer immernoch mit 56k unterwegs ist. Außerdem erhöht sich durch die Verwendung dieser Technik die Schnelligkeit der Software.

Dies kann ich leider nicht nachvollziehen. Der generierte Code ist immernoch exakt derselbe.

Zur AJAX-Technik empfehle ich folgendes Tutorial: http://www.teencoderz.com/forums2/articles...rticle&artid=39

Außerdem lassen sich mit Hilfe von AJAX innovative Funktionen entwickeln, wie (bereits von Sandro genannt) Google Suggest. Ich plane so etwas ebenfalls für meine (themen-spezialisierte) Suchmaschine.

siehe auch:
http://www.drweb.de/programmierung/ajax.shtml