andere Serversprachen neben PHP - Vorteile, Nachteile

[manni]

Hallo,

bisher war ich es gewohnt alle meine Serverskripte in PHP zu schreiben.

Gästebuch, Forum, etc.

Nun wollte ich mal fragen, was es sonst so gibt, wo die Vorteile liegen und wie es mit der Performance aussieht? cgi, perl,...?

Gruß

[Christian S.]

Hallo,

bisher war ich es gewohnt alle meine Serverskripte in PHP zu schreiben.

Gästebuch, Forum, etc.

Nun wollte ich mal fragen, was es sonst so gibt, wo die Vorteile liegen und wie es mit der Performance aussieht? cgi, perl,...?

Gruß

ASP.NET gibt es noch. altes ASP. Und JSP.
Perl natürlich. CGI ist keiner Sprache.

Ich entwickle beruflich viel unter ASP.NET. Hat den Vorteil, dass es ein mächtiges Framework (.NET) hintersich hat. und man kann sich die Sprache eigentlich aussuchen (ASP.NET an sich ist eigentlich auch keine Sprache). Man kann zB in VB.NET oder C# entwickeln, was durch seine objektorientierung sehr angenehm zu entwickeln ist, find ich...
Nachteil: es läuft nur auf Windows Servern. viele Anbieter haben aber Linux AFAIK.

Perl ist fürs Web veraltet, find ich. Da ist PHP besser. und mit JSP hab ich noch nicht viel mit gemacht..

Gruß
Christian

[Cheatah]

Hi,

Perl natürlich. CGI ist keiner Sprache.

nein, aber eine Technikdie ideal ist zur Nutzung mit verschiedensten Sprachen, darunter Perl, Python, Ruby, übrigens auch PHP, und selbst Bash ist unter manchen Umständen mehr als praxistauglich.

SSI sollte noch erwähnt werden; und damit hätten wir vermutlich das Wichtigste genannt. Zwar gibt es beliebig viele andere Sprachen (kennt jemand COPS?), aber die meisten davon sind eher selten empfehlenswert bzw. überhaupt nutzbar.

Perl ist fürs Web veraltet, find ich.

Ich mag zwar nicht wirklich widersprechen, werfe aber trotzdem der Form halber ein "kommt drauf an" ein ;-)

Da ist PHP besser. und mit JSP hab ich noch nicht viel mit gemacht..

JSP lohnt sich für größere Projekte. Dann, wenn PHP schwer handhabbar zu werden beginnt, fangen Java-Frameworks an, die Sache zu erleichtern.

Cheatah

[seth]

gudn tach!

Perl ist fürs Web veraltet, find ich.

aha, ich nicht.

Da ist PHP besser.

muhaha!

prost
seth

[Christian Seiler]

Hallo,

Nun wollte ich mal fragen, was es sonst so gibt, wo die Vorteile liegen und wie es mit der Performance aussieht? cgi, perl,...?

Naja, welche Programmiersprache man wählt ist in meinen Augen vor allem Geschmackssache (ok, gut, dann ist natürlich noch die Frage, ob man sich einen Webspace leisten kann, der diese Sprache bietet ;-)) - und "Vorteile/Nachteile" sind gerade bei Programmiersprachen eine sehr subjektive Angelegenheit. Was einige Leute als Vorteil ansehen, halten andere Leute für die dümmste Erfindung seit Daily-Soaps.

Die einzige Empfehlung, die ich Dir geben kann: Schau Dir einfach mal andere Programmiersprachen an - und bilde Dir selbst eine Meinung über diese.

Was es so bekannteres gibt, womit man Webanwendungen schreiben kann:

* PHP (kennst Du ja schon)
 * Perl (gibt's schon ewig, IMHO etwas gewöhnungsbedürftige Syntax, in den
         letzten Jahren ist's etwas am Abnehmen, dürftest Du aber neben
         PHP noch am häufigsten bei Webspaces finden. Es gibt *sehr* viele
         vorgefertigte Module im sogenannten CPAN.)
 * Python (ist in letzter Zeit etwas in Mode gekommen, ist eventuell etwas
           gewöhnungsbedürftig, stark objektorientiert, erlaubt aber auch
           prozedurales Programmieren, besitzt einige Syntax-Bestandteile,
           die aus funktionalen Programmiersprachen kommen)
 * Ruby (in letzter Zeit auch etwas in Mode gekommen, verwendet ähnlich wie
         Pascal oder Basic Syntax als ausgeschriebene Wörter, gibt ein
         (angeblich ;-)) tolles Framework für Webanwendungen namens
         "Ruby on Rails", kenne die Sprache ansonsten nicht näher)
 * Java (als Servlets; durch und durch objektorientiert, C-ähnliche Syntax,
         braucht einen Application-Server damit die Servlets performant
         laufen (als CGI *will* man Java nicht betreiben), ne Menge sehr
         großer Webanwendungen ("Enterprise"-Sachen) sind in Java, gibt
         sehr viele Middleware-Anbindungsmöglichkeiten)
 * ASP.NET (eigentlich keine Sprache, sondern ein Framework, das man meist
            mit VBScript oder C# betreibt, wo aber prinzipiell auch andere
            Sprachen möglich sind - ist von Microsoft, soll Java
            Konkurrenz machen; das Framework ist objektorientiert; C#
            hat eine Syntax ähnlich Java oder C++, VBScript lehnt sich an
            Visual Basic an)
 * C/C++ (man kann damit auch CGI-Programme schreiben; das SELFHTML Forum
          ist größtenteils in C geschrieben, allerdings muss man entweder
          erst einmal suchen, um Bibliotheken zu finden, die es einem
          ermöglichen, CGI komfortabel zu nutzen, oder man muss diese selbst
          schreiben; hier besteht auch eine erhöhte Sicherheitsgefahr
          durch Buffer Overflows, welche in anderen Sprachen (außer der
          Sprachkern selbst hat einen Bug) nicht auftreten können, weil
          diese keinen so hardwarenahen Zugriff auf den allozierten
          Speicher erlauben)
 * ColdFusion, Zope (das sind zwei *verschiedene* Application Server, die
                     es auch ermöglichen, Webanwendungen zu betreiben. Zu
                     beiden kann ich nichts näheres sagen, da ich sie nicht
                     kenne)

Die obige Liste dürfte etwa 99.999% aller Webanwendungen, die man im Internet antrifft, abdecken. Es gibt natürlich immer noch die Möglichkeit, CGI-Anwendungen in allen anderen möglichen Sprachen, die es so gibt, zu schreiben, wie z.B. Haskell, COBOL, Fortran o.ä. ;-) Brainfuck leider nicht, da man da keine Umgebungsvariablen auslesen kann, d.h. damit kaum etwas sinnvolles anstellen kann. ;-)

MEINE aktuelle Lieblingssprache ist Python - aber wie gesagt: Geschmäcker sind verschieden, kann sein, dass Dir Python gar nicht zusagt.

Viele Grüße,
Christian

[Arbeitsloser]

Hallo,

@christian: Toller Beitrag! -> fachlich hilfreich
Python ist auch meine Lieblingssprache (von den drei, vier, die ich kenne). Die Syntax ist sehr elegant, die Sprache und Installation ist benutzerfreundlich (all inclusive), Anbindung an C, OOP fester Bestandteil, die Leute nett. Die Ausführungsgeschwindigkeit ist schneller als die von Perl/PHP.

Einziger Nachteil*, wie schon gesagt, das junge Alter und daher nicht so viele Bibliotheken (Aber was kommt schon an CPAN ran...). Und gibt es da nicht auch so ein Problem mit utf-8? Kann aber sein, ich das mit einem Zope-Problem verwechsle...

Zu CGI gibt es noch Mod Python als Alternative, ebenfalls bessere Performance.

Gruß, der Arbeitslose

* selten, das "jung sein" heutzutage einen Nachteil darstellt...

[Christian Seiler]

Hallo,

[Python]
Und gibt es da nicht auch so ein Problem mit utf-8? Kann aber sein, ich das mit einem Zope-Problem verwechsle...

Zope kenne ich nur vom Namen her, allerdings kann ich sagen, dass Python *keinerlei* Probleme (die man sich nicht selbst macht ;)) hat mit unterschiedlichen Zeichenkodierungen und es die einzige Programmiersprache ist (die ich kenne), die das mit Unicode und so weiter ordentlich löst. Es gibt nämlich "normale Strings", die nichts anderes sind als Byte-Arrays, auf die String-Funktionen dann auch entsprechend wirken. Und es gibt "Unicode-Strings", die dann zeichenbasiert sind. Und man kann sehr leicht zwischen beiden hin- und herkonvertieren, Beispiel:

bytestr = "K\xc3\xa4se"  
bytestr2 = "K\xe4se"  
unistr = u"K\xe4se"  
print repr (unicode (bytestr, "UTF-8"))  
print repr (unicode (bytestr2, "ISO-8859-1"))  
print repr (unistr.encode ("UTF-8"))  
print repr (unistr.encode ("ISO-8859-1"))

bytestr ist hier eine Ansammlung von Bytes in UTF-8, bytestr2 ist eine Ansammlung von Bytes in Latin1, unistr eine Ansammlung von Unicodezeichen.

Die erste print-Zeile wandelt bytestr in einen Unicode-String um und gibt das aus (repr gibt zusätzlich noch aus, was man in Python schreiben müsste, um das gleiche Resultat zu erhalten). Die zweite print-Zeile wandelt bytestr in einen Unicode-String um (hier wird die andere Kodierung verwendet) und gibt ihn aus - kommt das gleiche bei raus in beiden Fällen und ist zufälligerweise ;-) identisch mit unistr.

Die dritte print-Zeile wandelt unistr in eine Byte-Folge in UTF-8 um und die vierte in eine in Latin1.

Einziger Nachteil von Unicode-Strings ist es, dass man diese nicht als Keys für Dictionaries (Hashes in Perl, assoziative Arrays in PHP) nutzen kann - aber dort kann man zumindest nach UTF-8 konvertieren, dann geht nix verloren (außer ein winziges bisschen Performance).

Viele Grüße,
Christian

[Christian Seiler]

Hallo,

Einziger Nachteil von Unicode-Strings ist es, dass man diese nicht als Keys für Dictionaries (Hashes in Perl, assoziative Arrays in PHP) nutzen kann - aber dort kann man zumindest nach UTF-8 konvertieren, dann geht nix verloren (außer ein winziges bisschen Performance).

Ok, das ziehe ich zurück, muss mal gucken, warum das bei mir vorher nicht ging...

Viele Grüße,
Christian

[Arbeitsloser]

Hallo,

Hübsches Beispiel.
Hab mal gegoogelt ( weil ich das immer noch nicht so recht kapiere ), und, auch wenns offtopic wird, einen hübschen Link zu dem Thema gefunden. Hach, solche Seiten liebe ich...

Gruß, der Arbeitslose

[rob]

Hi!

Nun wollte ich mal fragen, was es sonst so gibt, wo die Vorteile liegen und wie es mit der Performance aussieht? cgi, perl,...?

Jede Sprache hat ihre Vor- und Nachteile. Jede Sprache wurde ja gezielt für einen bestimmten Einsatzzweck entwickelt.
Und im Prinzip kann man, über das CGI, praktisch mit jeder Sprache arbeiten, sofern sie auf dem Server installiert ist.
Wenn dich die Vor- und Nachteile interessieren, dann empfehle ich, mal die Wikipedia zu besuchen und unter den einzelnen Sprachen nachzuschlagen.
Da findest du recht gute Artikel.

Und noch ein Nachtrag zu dem Posting von Christian S.:
Doch, es gibt auch Hoster, die mit Linux arbeiten und trotzdem ASP anbieten.
Chili!Soft bietet sein Chili!ASP an, welches auch unter Linux läuft.
Und mit MonoStack ist es auch möglich, ASP.Net unter Linux laufen zu lassen.
Dazu braucht man dann mono und das Apache-Modul mod_mono.
http://www.golem.de/0606/45796.html

Schöner Gruß,
rob

[manni]

Hallo,

Danke für eure zahlreichen Infos! Super!

Also ich habe mal irgendwo gelesen, dass cgi-Scripts langsam (-er als PHP) wären, da zuerst ein Interpreter geladen werden muss.

Heißt das, dass "normalerweise" Python als cgi-Script läuft?

Wie sieht es aus mit MySql-Datenbankanbindung unter Python?

Wo finde ich eurer Meinung nach die besten Tutorials für die verschiedenen Sprachen?

Gruß

P.S.: Muss mal gucken wie ich bei meinem sch*** Hoster herausfinde was er unterstützt.

[Christian Seiler]

Hallo,

Heißt das, dass "normalerweise" Python als cgi-Script läuft?

PHP, Perl und Python können als CGI-Script laufen. Das heißt: Beim Aufruf eines Scripts wird der Interpreter vollständig geladen und als separates Programm gestartet, der sich nach Scriptende wieder beendet. Aber eben diese 3 Sprachen können auch als Modul im Webserver laufen (mod_php, mod_perl, mod_python ;-)) - damit ist der Interpreter dann direkt geladen und man spart sich so etwas Zeit - mit dem Nachteil, dass bestimmte (komplexere) Dinge nicht gehen (das ist in allen drei Fällen so). Was wo installiert ist hängt stark vom Provider ab.

Wie sieht es aus mit MySql-Datenbankanbindung unter Python?

Die gibt es und sie funktioniert auch, wenn auch die Benutzung etwas anders ist, als in PHP.

Wo finde ich eurer Meinung nach die besten Tutorials für die verschiedenen Sprachen?

Zu Python kannst Du Dir http://wiki.python.org/moin/BeginnersGuide anschauen, da sind ne Menge Resourcen diesbezüglich verlinkt.

Viele Grüße,
Christian

[manni]

Hi,

Danke! Einfach Supi die Hilfe!

Aber ich bin wohl ein schwerer Patient ^^

Also mod_php ist bei meinem Provider geladen, das heißt dann, dass der php-Interpreter direkt geladen ist, richitg?

mod_pyhon ist nicht geladen, also wird für python der Interpreter seperat geladen? Und dann ist es schon langsam (-er als php) oder und kommt somit erstmal nicht in Frage?

Wie finde ich heraus, ob dann Python als cgi-script läuft bei meinem Provider?

Gruß

[Christian Seiler]

Hallo,

Also mod_php ist bei meinem Provider geladen, das heißt dann, dass der php-Interpreter direkt geladen ist, richitg?

Ja.

mod_pyhon ist nicht geladen, also wird für python der Interpreter seperat geladen?

Ja.

Und dann ist es schon langsam (-er als php) oder und kommt somit erstmal nicht in Frage?

Jain. Es kommt auch darauf an, was Du machst. Wenn Du nur Hello World oder das aktuelle Datum o.ä. ausgibst, dann ist PHP natürlich schneller. Bei komplexen Operationen, die sowieso etwas länger dauern (z.B. Datenbankabfragen) spielt die Startzeit bei PHP oder Python heute in der _Regel_ keine so sehr große Rolle mehr (im Gegensatz zu Java - *das* will man wirklich nicht als CGI betreiben ;-)), sprich: der Unterschied ist marginal. Zudem (hab's aber nicht nachgemessen, kann also komplett falsch sein) soll Python schneller als PHP sein, was die reine Codeausführung angeht -> viel Code könnte mit Python schneller gehen.

Wie finde ich heraus, ob dann Python als cgi-script läuft bei meinem Provider?

Fragen. Oder Du könntest in Dein cgi-bin/-Verzeichnis folgende Datei hochladen (nenne sie z.B. "hello.py") [1]:

#!/usr/bin/env python  
import sys  
sys.stdout.write ("Content-Type: text/plain; charset=ISO-8859-1\r\n\r\n")  
sys.stdout.write ("Hello World!\r\n")

(Alternativ auch #!/usr/bin/python falls obiges nicht geht - wenn beides fehlschlägt, kann es trotzdem sein, dass Python geht, nur anders aufgerufen werden muss)

Achja, ausführbar machen nicht vergessen, d.h. Dateirechte im FTP-Programm ändern (0755 oder so ähnlich ist eine gute Wahl).

Wenn Du kein cgi-bin hast und der Provider nicht explizit gesagt hat, dass CGI-Scripte in normalen Verzeichnissen gehen, dann dürfte Python bei Deinem Provider gar nicht funktionieren.

Viele Grüße,
Christian

[1} Achja, das obige Script ist wirklich nur ein Test-Script - bitte fange *nicht* an, nach dem Schema CGI-Scripte in Python zu programmieren, da gibt's eine Klasse für sowas. ;-)

[manni]

Hallo,

also das werde ich dann mal machen.

Was hat es mit dem Aufrufen von python auf sich?

Was macht die besagte Klasse genau? Und wo finde ich diese Klasse?

Gruß

[manni]

P.S.:Also sobald einfache Datenbankabfragen vorkommen, sollte das laden des Interpreters kaum eine Rolle spielen?
Wo könnte man einen Performance vergleich von Python zu PHP finden?

[Christian Seiler]

Hallo,

P.S.:Also sobald einfache Datenbankabfragen vorkommen, sollte das laden des Interpreters kaum eine Rolle spielen?

In der Regel: ja. Hängt aber auch stark vom System / den Optimierungen etc. usw. ab.

Wo könnte man einen Performance vergleich von Python zu PHP finden?

Naja, der einzige sinnvolle Vergleich ist es, eine gewünschte Testanwendung selbst zu schreiben und dann messen, wie lange die Antwortzeit über HTTP ist - *genau dann* erhälst Du nämlich die Werte, die für Deinen Server relevant sind, die dann auch Deine User spüren werden.

Wenn irgendjemand nun misst "Python ist auf einem 2 Ghz Quad-Itanium 2 mit 8 GiB RAM 15% schneller als PHP, wenn es um das Zeichnen der Mandelbrotmenge geht", dann ist die Aussage absolut nichtssagend bezüglich Deiner Webanwendung - denn die wird (nehme ich mal an ;-)) nicht die Mandelbrotmenge zeichnen wollen.

Zur Messung der Antwortzeit kannst Du z.B. die Firefox-Erweiterung Firebug verwenden, die man als Webentwickler sowieso installiert haben sollte. ;-)

Viele Grüße,
Christian

[Christian Seiler]

Hallo,

Was hat es mit dem Aufrufen von python auf sich?

Was genau meinst Du?

Was macht die besagte Klasse genau? Und wo finde ich diese Klasse?

Das Beispiel, das ich schrieb, war ein Mini-CGI-Script in Python, das sich gerade so an den CGI-Standard hält um etwas auszugeben. Ist natürlich suboptimal, wenn Du so Webanwendungen programmieren willst - daher ist es nur zum Testen gedacht gewesen.

Die Doku zur CGI-Bibliothek von Python findest Du hier: http://docs.python.org/lib/module-cgi.html

Allgemeine Doku hier: http://docs.python.org/

Viele Grüße,
Christian

[manni]

Hallo,

nochmal doof gefragt: Weiß jemand mehr über Ruby? Datenbankanbindungen, Funktionalität, etc?

Gruß

[nobody]

Hallo,

neben den qualifizierten guten Beiträgen muss ich mal noch ne dumme Frage meinerseits einbringen:

Ich nutze in PHP gerne die include-Funktion um Inhalte, die auf allen Seiten gleich sind in den verschiedenen HTML-Seiten nur mit
<?php
inlcude('navi');
?>
einbinden zu müssen und dann ganz normal mit dem Quelltext fortfahren zu können oder eben mit php-Code.

Wie sieht das ganze mit cgi-Scripten aus (Ruby, Python), die müssen ja normalerweise im cgi-Ordner liegen. Kann ich die auch einfach so in ne HTML-Datei einbinden?

Gruß

[Struppi]

Wie sieht das ganze mit cgi-Scripten aus (Ruby, Python), die müssen ja normalerweise im cgi-Ordner liegen. Kann ich die auch einfach so in ne HTML-Datei einbinden?

Im Prinzip nein.

Du sprichst hier einen der Vorteile von PHP an, es fühlt sich an wie HTML und du kannst die PHP Dateiein mit HTML Dateien vermischen auch die Ordnerstruktur ist die Gleiche.

Bei den anderen Sprachen gibt es diese Vermischung von HTML Code und Programmiercode so nicht (was bei grösseren Projekten auch nicht gewünscht ist, im gegenteil es wird dort als schlechter Stil angesehen), dort wirst du ein Templatesystem verwenden.

Du kannst natürlich auch in anderen Sprachen einzelne Skripte einbinden, bist aber nicht an ein CGI Verzeichniss gebunden, aber das macht man dort um Funktionalität einzubinden und nicht wegen der Ausgabe.

Struppi.

[nobody]

Hallo,

wie sieht so ein Template-System genau aus?

Also als Beispiel ich habe 3 Dateien.

domain.de/datei_1.html
domain.de/datei_2.html
domain.de/datei_3.html

In diesen ist überall der Anfang der HTML-Datei gleich, d.h, der head und der erste div im body, sowie der Schluss ist gleich, sprich Fußzeile. Nun soll nebenbei noch in jeder Datei jeweils ein anderes cgi-Script eine Ausgabe im Inhalts-Div ausgeben. Ist das möglich? Wenn ja wie sieht das aus?

Gruß

[Struppi]

wie sieht so ein Template-System genau aus?

Da gibt es viele unterschiedliche, bei wikipedia wird das gut erklärt.

Struppi.

[nobody]

Hey,

danke für den Link...eigentlich kann man sich ja sowas auch selber basteln...

Aber mal ne Frage, z.B. das Smarty ist ja in PHP heschrieben, wird dort dann einfach die Template-Datei eingelesen auf {VARIABLEN} untersucht und diese werden dann ersetzt und Ausgegeben?

Gruß

[Struppi]

danke für den Link...eigentlich kann man sich ja sowas auch selber basteln...

Klar kann man das.

Aber mal ne Frage, z.B. das Smarty ist ja in PHP heschrieben, wird dort dann einfach die Template-Datei eingelesen auf {VARIABLEN} untersucht und diese werden dann ersetzt und Ausgegeben?

So in etwa dürften die meisten Template Systeme funktionieren.

Struppi.

[nobody]

Das ist aber doch dann relativ langsam? Oder?

File auslesen, Variablen austauschen, ausgeben...

[Struppi]

Das ist aber doch dann relativ langsam? Oder?

File auslesen, Variablen austauschen, ausgeben...

Das du damit keine Echtzeitanwendungen programmierst ist klar, es geht um Übersicht, Wartbarkeit und evtl. Teamarbeit erleichtern. Aber letztlich werden sich diese Aktionen, bei heutigen Rechnern im Millisekundenbereich bewegen und der Vorteil gegenüber einem PHP skript, dass ja ebenfalls eingelesen, geparst, rennen  und ausgegeben werden muss, ist der Geschwindigkeitsnachteil noch geringer.

Struppi.

[kölir]

Bei den anderen Sprachen gibt es diese Vermischung von HTML Code und Programmiercode so nicht (was bei grösseren Projekten auch nicht gewünscht ist, im gegenteil es wird dort als schlechter Stil angesehen), dort wirst du ein Templatesystem verwenden.

Hi,

und wie sieht es dann Besipielsweise aus, wenn man in einem div, die Ausgabe eines cgi-Scripts haben möchte, ohne das in's HTML zu schireben?

<div>
und wie kommt dann hier die cgi-Ausgabe?
</div>

Gruß

[Siechfred]

<div>
und wie kommt dann hier die cgi-Ausgabe?
</div>

Mit Hilfe von Server Side Includes.

Siechfred

[Struppi]

und wie sieht es dann Besipielsweise aus, wenn man in einem div, die Ausgabe eines cgi-Scripts haben möchte, ohne das in's HTML zu schireben?

<div>
und wie kommt dann hier die cgi-Ausgabe?
</div>

In dem der Parameter der in dem DIV steht, durch das CGI gefüllt wird.

Struppi.

[David Tibbe]

Hallo zusammen,

Da es gerade um verschiedene Programmiersprachen und Webframeworks geht möchte ich auch noch den Exoten Seaside erwähnen.

Seaside ist ein in Smalltalk geschriebenes Webframework. Man benötigt auf dem Server also eine Smalltalk-VM, entweder Squeak oder Visual Works.

Das Besondere an Seaside ist, dass man nicht einzelne Seiten programmiert sondern Komponenten und Tasks.
Komponenten sind Teile einer Seite (oder auch eine ganze Seite). In ihnen wird zum einen das Aussehen der Komponente beschrieben (kein HTML-Code sondern durch programmatische Methodenaufrufe, die entsprechendes HTML erzeugen), zum anderen ihr Verhalten. Man muss sich nicht selbst um Formularausgaben kümmern, dies mach alles Seaside. Man kann nach der Übermittlung einfach auf entsprechende Variablen der Komponente Zugreifen und die Übermittelten Werte abfragen.
In Tasks können längere, komplexere Abläufe modelliert werden. Das alles in einer Methode; wenn Benutzerinteraktion notwendig ist wird an dieser Stelle quasi gewartet.

Wie auch die Tasks basieren die Sessions in Seaside auf Continuations. Im Bezug auf Sessions heißt das, dass zum Beispiel ein Druck auf den Zurück-Button tatsächlich auch ein Zurück im Kontrollfluss bewirkt und alle Änderungen rückgängig gemacht werden (Datenbank commits usw. sind natürlich nicht umkehrbar).

Cool ist auch die direkte Anbindung an Scriptaculous. Im Code der Komponente kann man also sagen: "Mache mir aus dieser Liste eine Sortable List" oder "Wenn dieser Wert geändert wird aktualisiere jenes Div".

Wie gesagt ist das ganze Framework in Smalltalk geschrieben, die Webseiten werden es folglich auch. Es ist wohl auch nicht sonderlich gut für große Seiten geeignet, es gibt noch einige Performance-Leaks.

Es ist aber mal ein anderer Weg, Webseiten zu erstellen. Ein Blick lohnt sich also.

Grüße
  David