Vorteile von Nicht-Web-Applikationen?

[Artchi]

;fricky schrieb:

nee, das passiert fast automatisch. bei firefox z.b. geht das ziemlich stressfrei.

Ach, guck an?! Der Richclient namens Firefox aktualisiert sich stressfrei. Warum soll das nicht mit jedem anderen Richclient gehen? Den Update-Mechanismus kannst du auf jede andere zu installierende Software anwenden.

[byto]

Artchi schrieb:

Und Webstandards bleiben 20 Jahre auf dem selben Stand? Oder warum gibts immer neue Browserversionen und neue Plug-ins/Add-ons für Browser? Wir arbeiten alle mit HTML 1.0, ohne Flash, ohne SVG, ohne XYZ. Und das W3C arbeitet nicht an neuen Standards?

Wenn ich z.B. einen Webclient mit GWT implementiere, dann liefert mir der GWT Compiler verschiedene browserspezifische Kompilate. Unter anderem ist da ein Kompilat dabei, das die Anwendung fehlerfrei im Internet Explorer 6 darstellt - ein Browser, der 2001 rauskam und dessen Support nächstes Jahr ausläuft.

Und jetzt willst Du mir erzählen, meine Webanwendung benötigt eine aktuelle Browserversion? Das ist einfach Blödsinn. Aber ich verstehe Deine Argumentation sowieso nicht. Natürlich sollte ein Browser mit der Zeit auch aktualisiert werden. Aber es ist nun mal ein Unterschied, ob ich eine Anwendung aktualisieren muss oder 1000. Zumal die Softwarequalität eines Browsers idR wohl deutlich höher ist als die Qualität einer Individualsoftware.

Wieviele Unittests gibts denn in Deinem Richclient Projekt, die die Softwarequalität sicherstellen? Und wieviele Unittests meinst Du, gibt es für aktuelle Browser?

[Zeus]

Die Diskussion ist sinnlos, weil es für Richclient genau so eine Platfrom gibst, wie für das Web, aka .NET/Java (Inklusive ClickOnce Deployment und JavaWebStart).

[;fricky]

Artchi schrieb:

;fricky schrieb:

nee, das passiert fast automatisch. bei firefox z.b. geht das ziemlich stressfrei.

Ach, guck an?! Der Richclient namens Firefox aktualisiert sich stressfrei. Warum soll das nicht mit jedem anderen Richclient gehen? Den Update-Mechanismus kannst du auf jede andere zu installierende Software anwenden.

von wegen. die installationsprozedur des FF haben dir andere schon abgenommen. den gibts z.b. für verschiedene OS. und wenn's nicht der FF sein soll, dann nimmste eben 'nautilus' oder sonstwas, geht ebenso. bei 'nem monolithischen softwareklotz, haste zig verschiedene binaries (vorausgesetzt du programmierst in C, C++ oder einer ähnlichen nicht-VM umgebung und nicht-portablen sprache(in bezug auf betriebssysteme)) und musst für jedes OS einen eigenen installer haben. das ist weit weniger lustig, als eine serverbasierte software zu schreiben, die über standardisierte protokolle und netze von fast jedem ort der welt aus benutzt werden kann. und updates sind auch viel einfacher, die einfach auf den server geschoben werden und jeder hat gleich die neueste version. klar hat sowas auch nachteile, die hier alle schon aufgelistet wurden, aber in manchen situationen ist client/server-basierte software einfach eine tolle sache. ich bin z.b. grundsätzlich für eine trennung von funktionalität und GUI und zwar so, dass netzwerktaugliche schnittstellen verwendet werden, d.h. client und server können, müssen aber nicht, entweder auf demselben rechner oder sonstwo laufen.

[u_ser-l]

Grundproblem ist wohl, daß html vom Ansatz her nicht primär für Interaktivität, sondern zur statischen Darstellung geschaffen wurde, und das zu einer Zeit, zu der die heutige Funktionsfülle des web wohl nicht abzusehen war. Das wird im zunehmend interaktiven web zunehmend problematisch.

Außerdem erscheint das Technologie-Gemisch von html, js, php, css usw. formal überkomplex angesichts der in der Regel eher einfachen Aufgaben bei der Darstellung durchschnittlicher Websites.

Möglicher Ausweg wäre, auf html & friends zu verzichten und voll auf javascript zu setzen, auf mächtige in javascript implementierte Oberflächen, gutes Beispiel: 'lively kernel'.

[volkard]

u_ser-l schrieb:

Außerdem erscheint das Technologie-Gemisch von html, js, php, css usw. formal überkomplex angesichts der in der Regel eher einfachen Aufgaben bei der Darstellung durchschnittlicher Websites.

Möglicher Ausweg wäre, auf html & friends zu verzichten und voll auf javascript zu setzen, auf mächtige in javascript implementierte Oberflächen, gutes Beispiel: 'lively kernel'.

Gibts da nicht auch was von Microsoft?
http://silverlight.net/

[;fricky]

u_ser-l schrieb:

Möglicher Ausweg wäre, auf html & friends zu verzichten und voll auf javascript zu setzen, auf mächtige in javascript implementierte Oberflächen...

nimmste java-applets. die gibts auch schon länger als 10 jahre.

[u_ser-l]

warum, meinst du wohl, heißt es lively kernel? Weil die Anwendungen zur Laufzeit änderbar sind, dank der dynamischen Eigenschaften von javascript.

[u_ser-l]

außerdem ist einer der Vorzüge gerade, daß keine plugins nötig sind, nur javascript und svg benutzt wird - Ziel ist ja u.a. die Anzahl der verwendeten Technologien zu reduzieren. silverlight oder java applets sehe ich da nicht.

[;fricky]

u_ser-l schrieb:

außerdem ist einer der Vorzüge gerade, daß keine plugins nötig sind...

nö, aber es geht nur richtig mit safari, bei anderen browsern zickt irgendwas. mit'm IE siehts auch eher schlecht aus.
http://research.sun.com/projects/lively/#supported
da würde ich doch lieber applets nehmen, geht mit fast jedem browser, brauchst nur'n jRE zu installieren.

[u_ser-l]

nur ein jre ...

nochmal: eines der Ziele von lively kernel ist, daß keine besonderen environments benötigt werden. Fallen applets also schon mal weg.

Wie willst du Anwendungen zur Laufzeit ändern auf statisch typisierter Grundlage ? Fallen applets schon zweimal weg.

[;fricky]

u_ser-l schrieb:

nochmal: eines der Ziele von lively kernel ist, daß keine besonderen environments benötigt werden.

dann haben sie ihr ziel verfehlt, weils ja mit den meisten browsern nicht vernünftig geht.

u_ser-l schrieb:

Wie willst du Anwendungen zur Laufzeit ändern auf statisch typisierter Grundlage ?

wer will das? ich jedenfalls nicht.

[hustbaer]

u_ser-l schrieb:

außerdem ist einer der Vorzüge gerade, daß keine plugins nötig sind, nur javascript und svg benutzt wird - Ziel ist ja u.a. die Anzahl der verwendeten Technologien zu reduzieren.

Sun Labs schrieb:

In general, one of our goals has been to leverage existing technologies as much as possible.

Liest sich nicht so.

Sun Labs schrieb:

IMPORTANT! The Lively Kernel requires SVG support and does not run on Microsoft Internet Explorer without extensions. An experimental Microsoft Internet Explorer port, requiring an additional web browser plug-in, is available here

und tschüss

[u_ser-l]

lively kernel ist - wie zahlreiche andere Projekte der vergangenen 4 Jahrzehnte aus dem Umfeld der Smalltalk-Entwickler - seiner Zeit voraus. Akzeptanzprobleme beim mainstream: wen wundert's. Wen stört's.

[;fricky]

u_ser-l schrieb:

lively kernel ist - wie zahlreiche andere Projekte der vergangenen 4 Jahrzehnte aus dem Umfeld der Smalltalk-Entwickler - seiner Zeit voraus.

ach was, überhaupt nicht. es ist nicht mehr als eine studie, um die grenzen von JavaScript auszuloten, noch nicht mal vom prinzip her ist es eine tolle idee. solange der 'lively kernel' nur in einem browser läuft, in zwei anderen nur bedingt und im stinknormelen IE garnicht, ist er praktisch unbrauchbar.

[hustbaer]

ACK.

Liest sich auch irgendwie so wie "wir machen sowas wie Java, nur ohne VM, und schlechter, und dass Windows & IE von vielen Leuten verwendet wird ist ein Gerücht". Toll. Wie innovativ. Wie wegweisend.

*kicher*

[u_ser-l]

;fricky schrieb:

u_ser-l schrieb:

Wie willst du Anwendungen zur Laufzeit ändern auf statisch typisierter Grundlage ?

wer will das? ich jedenfalls nicht.

Ich schon. Das wäre viel einfacher als Anwendungssoftware über etliche configs zu customizen - der Anwender könnte sie einfach zur Laufzeit umprogrammieren.

Programmierung durch Manipulation und Formung von Objekten in einem dynamischen Laufzeitsystem wird gängige Methode in der Computerwelt der Zukunft sein. Die Welt ist noch nicht so weit, wie die seit Jahrzehnten anhaltende Ablehnung von Systemen wie Smalltalk beweist.

Der heute praktizierte Entwicklungzyklus edit-compile-run-edit-compile ... stammt aus der Computerwelt der 1950er Jahre. Ebenso wie file-basierte Quelltextverwaltung und statische Typisierung.

Um so etwas zu begreifen, muß man aber auch mal über den Tellerrand schauen wollen. Und können.

[u_ser-l]

hustbaer schrieb:

ACK.

Liest sich auch irgendwie so wie "wir machen sowas wie Java, nur ohne VM, und schlechter, und dass Windows & IE von vielen Leuten verwendet wird ist ein Gerücht". Toll. Wie innovativ. Wie wegweisend.

*kicher*

perfekt.

[hustbaer]

u_ser-l schrieb:

Programmierung durch Manipulation und Formung von Objekten in einem dynamischen Laufzeitsystem wird gängige Methode in der Computerwelt der Zukunft sein.

Ja, klar.
Macht überhaupt keine Probleme bei der Wartung wenn man nicht weiss was diverse User zur Laufzeit alles am Programm ändern.

[u_ser-l]

du verstehst nicht. Das Programm als solches wird zunehmend devaluiert werden und zu einer Sammlung von zusammengehörigen Klassen werden. In Smalltalk wird Software seit eh und je in Form von Klassenbeschreibungen abgespeichert ("fileout") oder kompletten Objektwelten ("image").

Mit einer Sammlung von angelieferten Klassen kann der Anwender machen, was er will. Umprogrammieren, mit eigenen Klassen mischen, Objekte anlegen. Compilierung als separaten Vorgang (auch so ein Unikum aus den 1950er Jahren) gibt es dann nicht mehr, genauer: jede Methode wird dann compiliert, wenn sie in die Objektwelt eingefügt wird.