Syntax-Highlighting in Browser-Textarea

[burli]

Eben, ob man jetzt eine Software an 20 Browser oder 3 Betriebssysteme anpasst ist wohl eindeutig. Die 3 Betriebssysteme sind mit der richtigen Software einfach. Aber eine relativ komplexe Sache wie eine IDE an verschiedene Browser anzupassen... viel Spaß. Das nervt ja bei relativ "normalen" Webseiten schon

[lunar]

@die anderen, die Browser-basierte Anwendungen nicht mögen: Niemand zwingt euch, das auch zu benutzen. Derartige Anwendungen sind in der Regeln geringer im Funktionsumfang, was häufig als Vorteil angesehen wird.

Ich persönlich sehe es nicht als Vorteil, wenn ein Webmailer weder HTTPS noch GnuPG bietet.

Der Browser ist in meinem Augen eben eine Plattform für Anwendungen. Noch nie war es so einfach, neue Anwendungen zu schreiben, zu verteilen und vielen Leuten zur Verfügung zu stellen, wie durch das Web und Webbrowser.

Bitte vermische nicht das Web als Plattform für Softwareverteilung mit dem Web als Plattform für die Software selbst!

Ich schätze das Internet für seine Kommunikationsmöglichkeiten und die Möglichkeiten, Code zu veröffentlichen und Code zu entwickeln, genauso wie du. Ein freies Projekt zu starten, ist dank SourceForge und Konsorten so einfach wie noch nie, zumal es mittlerweile auch tolle Software gibt, um Projekte auf eigenen Servern voranzutreiben.

Das alles hat aber nichts mit dem Web als Anwendungsplattform zu tun. Das ist keineswegs "leicht", weder bei der Entwicklung noch bei der Verteilung bzw. dem zur Verfügung stellen.

Um dein erstes Posting aufzugreifen: Es gibt eine unüberschaubare Anzahl von Entwicklungsumgebungen für den Desktop. Die Entwicklung solcher Programme ist denkbar einfach: Eric 4, eine der besten freien IDEs für Python, wird beispielsweise fast ausschließlich von einer einzigen Person entwickelt. Diese Produktivität erreicht man, weil moderne Frameworks viel Arbeit abnehmen, beispielsweise durch fertige Editor-Kompontenten wie QScintilla.

Eine solche IDE als Webanwendung ist für einen Entwickler nicht zu verwirklichen: Es existieren kaum fertige Komponenten, von vollwertigen GUI-Frameworks ganz zu schweigen. Zudem muss man sich um so viel mehr Dinge kümmern, wie Authentifizierung, Sicherheit, Session- und Workflow-Managment, alles Dinge, die bei einer Desktop-Anwendung von selbst kommen oder gar nicht notwenig sind.

Die Behauptung, es wäre "leicht", Webanwendungen von großer Komplexität zu entwickeln, ist schlicht falsch.

Selbst Firmen, die unendlich viel mehr Ressourcen darauf verwenden können, haben noch keine vernünftige IDE als Webanwendung fertiggebraucht. Von noch komplexeren Anwendungen wie DTP, CAD oder 3D-Modelling ganz zu schweigen...

Das halte ich für eine gute Sache. Entscheidend ist jedoch, dass keine Software installiert werden muss

Wo ist da das Problem? Installieren musst du eh, mindestens das OS und den Browser, da kommt es auf mehr auch nicht an Nicht jedes OS hat so schlechtes Paketmanagement wie Windows

nichts betriebssystemspezifisches getan werden muss

In Zeiten moderner GUI-Toolkits wie Qt4 oder wxWidgets, plattformübergreifender IDEs, Buildsysteme, Compiler und Interpreter und gleichzeitig mitunter gravierender Unterschiede zwischen DOM- und ECMA-Script-Implementierungen verschiedener Browser wirkt Plattformunabhängigkeit als Argument für Webanwendungen reichlich lächerlich.

Mit der Anwendung zusammen will ich ja auch meine Datenlagerung ins Netz verlagern. Zugriff auf die lokale Festplatte ist daher IMHO nicht zwingend notwendig. Gerade für eine IDE, wo ich meinen Quelltext sowieso schon in einer Versionsverwaltung irgendwo im Netz (sourceforge, google code, github usw.) lagere, sehe ich keine Notwendigkeit für den lokalen Zugriff.

Angesichts der Tatsache, dass die meisten Leute noch nicht mal begreifen, was es bedeutet, wenn beim Webmailen am öffentlichen Hotspot die Firefox-Adresszeile nicht gelb ist, ist die Vision einer umfassenden Speicherung von persönlichen Daten im Web einer eher erschreckende ...

Dabei ist Google ja nicht mal die größte Gefahr, die haben ja sogar ein wirtschaftliches Interesse daran, diese Daten zu schützen, immerhin sind sie deren Kapital. Ich fürchte vielmehr Arbeitgeber, Banken, Versicherungen usw., die an diesen Daten interessiert sind, und angesichts des mangelnden Bewusstseins für Sicherheit und Datenschutz leicht an diese Daten kommen, wenn sie es nur wollen ...

Man muss sich nur mal die aktuellen Nachrichten ansehen, um zu sehen, wie es um den Datenschutz in unserem Land bestellt ist ... ein Detektiv, der im Auftrag deiner Versicherung deine Daten an einem Hotspot mitliest, scheint da keine so unrealistische Vision mehr zu sein.

Edit: Quotes korrigiert

[burli]

Wo ist da das Problem? Installieren musst du eh, mindestens das OS und den Browser, da kommt es auf mehr auch nicht an Nicht jedes OS hat so schlechtes Paketmanagement wie Windows

Seit wann hat Windows ein Paketmanagement?

In Zeiten moderner GUI-Toolkits wie Qt4 oder wxWidgets, plattformübergreifender IDEs, Buildsysteme, Compiler und Interpreter und gleichzeitig mitunter gravierender Unterschiede zwischen DOM- und ECMA-Script-Implementierungen verschiedener Browser wirkt Plattformunabhängigkeit als Argument für Webanwendungen reichlich lächerlich.

Wie gesagt, bei Betriebssystemen hat man 3 wichtige Plattformen für die sich mittels Python oder sogar C/C++ und wxPy oder PyQt relativ leicht entwickeln lässt. Aber bei Browsern flucht man ja schon über die Unterschiede zwischen IE6 und IE7, von Firefox, Opera usw rede ich erst gar nicht. Wobei "normale" Webseiten für "nicht-MS-Browser", die sich weitestgehend an W3C halten, relativ einfach sind. Nur was sma da vorhat ist alles andere als "normal" für einen Webbrowser und gehört da IMHO einfach auch nicht hin. Und das Argument der Installation ist sowas von albern.

Für mich besteht ein Browser aus HTML, CSS, ein klein wenig JavaScript und, wenn absolut nicht darauf verzichtet werden kann, ein Mediaplayer. Und das ganze dient für was wozu es ursprünglich mal gedacht war: Webseiten anzeigen. JavaScript gehört, wie von Netscape ursprünglich gedacht, in eine Sandbox ohne irgendwelche Zugriffsmöglichkeiten auf den PC. Dank MS und deren Versuche JS "zum Nutzen der Anwender" zu erweitern gibts jetzt halt solche Möglichkeiten wie Viren zu installieren oder den Router zu modifizieren (Und welcher Schwachkopf hat sich eigentlich den Mist einfallen lassen JavaScript in PDF oder Flash Videos zu packen??? )

[Sr4l]

Einfach ausgedrückt.

Der Vorteil von Webanwendungen:
Sie laufen überall da wo ich Internet habe, ohne etwas zu installieren, nützlich weil ich das u.a. auch nicht kann bei Rechner von Arbeit, Schule, Freunden und Bekannten.

Nachteil: Man macht sich von der Internetanbindung und den Servern abhängig

Gegen eine Editor im Netz ist doch nichts zu sagen.
Ich denke da so an MS Exchange mit seinem Outlook (als Desktopprogramm) und Outlook Web Access. Solche Ansätze finde ich gut.

[sma]

Ich halte nochmal dagegen, es ist sowieso schon OT :)

Burli meint, drei Betriebssysteme zu unterstützen ist einfacher als 20 Browser. Meine Sicht ist eine andere. Neben dem IE (der mich persönlich gar nicht interessiert und nur wichtig ist, wenn man über Anwendungen für die Masse redet) sind IMHO noch Gecko und Webkit wichtig, wobei ich auf Webkit als letztlichen Sieger tippe, da diese Engine neben Apple von Nokia (und Trolltech), Sun, Adobe und Google unterstützt wird. Wir reden also von nur 3 Rendering-Engines bei denen Gecko und Webkit zudem noch sehr ähnlich weil standardkonform sind.

Wichtiger ist aber IMHO, dass alle drei für den User nur eine Plattform bilden - das Web. Schreibt man traditionelle GUI-Anwendungen, so muss man für Mac, Linux und Windows sehr spezielle und unterschiedliche Konventionen einhalten, damit sich die Anwendung nicht fremd und unvertraut anfühlt. Mac und Windows haben zum Beispiel unterschiedliche Konventionen, die die Schaltflächen eines Nachrichtenfensters benannt und angeordnet werden müssen.

Dies treibt meiner Erfahrung nach den Aufwand für cross-plattform-GUIs stärker in die Höhe als das Umschiffen von Browser-spezifischen Darstellungsproblemen.

Lunar hält das Web zwar für eine gute Plattform für die Anwendungsentwicklung, nicht jedoch für Anwendungen. Dazu möchte ich fragen, warum etwas zwar für Software-Entwickler gut sein darf, nicht aber auch für andere Anwender? Sourceforge ist eine Webanwendung für einen Anwendungsfall so wie es ein Tournierplanungsprogramm für eine andere Anwendergruppe sein könnte. Warum soll es dort keine webbasierte Lösung geben?

Das Argument, dass man eine Web-IDE nicht bauen kann, weil zu wenig Komponenten wie z.B. Scintilla existieren (Scintilla finde ich übrigens als beschränkt und wenig (in Python) erweiterbar und für ein Problem, warum fast all die selbstgeschriebenen IDEs Mittelmaß bleiben. Aber das ist ein anderes Thema) kann ich nicht akzeptieren, sondern nur als Appell auffassen, dann eben solche Komponenten zu schaffen.

Für Seaside baut übrigens gerade ein Entwickler von Cincom eine Web-IDE für Smalltalk - aber das mit dem einen Entwickler kann auch nicht das Maß sein. Wieviele Entwickler haben an Eclipse gearbeitet? Ich tippe auf 20 bis zur ersten Version. Inzwischen beschäftigt das Eclipse-Projekt hunderte und wächst und wächst ... bzgl. wuchert vor sich hin.

Dinge wie "Authentifizierung, Sicherheit, Session- und Workflow-Managment" erwarte ich eigentlich von einem guten Web-Rahmenwerk bereits. Mir fällt sofort wieder Seaside ein, aber es muss doch auch andere geben, die von diesen Themen abstrahieren. Zumindest die ersten drei werden doch auch von Django adressiert.

Ich habe meines Wissens nicht geschrieben, es sei leicht, solche Anwendungen zu bauen, sondern einfach (und einfach kann verdammt schwer sein) neue Anwendungen zu schreiben und zu verteilen. Dabei dachte ich insbesondere an die Google App Engine.

Zum Thema Installation: Ich denke dabei hauptsächlich an das übliche Szenario, wo es nicht erlaubt ist, irgendwelche neue Software zu installieren - wo man nicht einfach mal das GUI-Toolkit der Wahl und weitere Abhängigkeiten nachinstallieren kann (oder will). Ein Browser (in hoffentlich aktueller Version) ist in der Regel vorinstalliert. Bei uns in der Firma verbreiten sich Webanwendungen sofort - Software installieren dürfen "normale" Anwender außerhalb der Entwicklungsabteilung aber nicht. Da kann man nicht mal eben schnell ein "Goody" weiterreichen. Wenn die an einem EM-Tipp teilnehmen sollen, dann bietet sich eine Webanwendung an - die kann jeder sofort aufrufen.

Den Datenschutzaspekt möchte ich in dieser Diskussion ausklammern, da er IMHO nicht mit den Webanwendungen zu tun hat sondern in gleichem Maße auch für Desktop-Anwendungen gilt. Auch hier könnte ein Arbeitgeber, die USA, der Geheimdienst, usw. wirklich alles mitlesen, etwa in dem alle Tastendrücke und Mausbewegungen aufgezeichnet werden, indem die Datenkommunikation zwischen dem Desktop-Client und dem Server, die in beiden Fällen die eigentliche Arbeit macht, mitgeschnitten wird oder inidem Bildschirme abfotografiert werden. Es ist unabhängig von der konkreten Technologie, ob man dem System vertraut oder misstraut.

PDF kann übrigens inzwischen nicht nur JavaScript, sondern auch neuerdings Flash einbinden. Ich glaube, ein Traum von Adobe ist, dass PDF irgendwann man HTML ersetzt. Ansonsten ist Video IMHO etwas, das natürlich etwas wie Flash gehört, was ja das dröge textbasierte HTML um multimediale Fähigkeiten ersetzen sollte. Und ohne Video in Flash hätten wir jetzt nicht das Fernsehen der Zukunft - Youtube und co.

Mich freut aber, dass Sr4l meine Einschätzungen der Lage zu teilen scheint.

Übrigens, ich habe eine proof of concept mit einem Editor, der unter Safari und Firefox läuft (IE zu testen war mir zu mühsam, da ich zu dem Punkt kein Windows greifbar hatte) und wie geplant, die DOM-Knoten für einzelne Zeilen manipuliert und diese einzeln einfärbt. Was mir fehlt ist eine Selektion mittels Cursor+Shift-Tasten und das Einfärben über Zeilengrenzen hinweg. Sowas wie einen Emacs im Web könnte ich jetzt aber bauen - wäre nur noch Fleißarbeit für die verschiedenen Befehle (und den Lisp-Interpreter ;)

Beide fehlende Funktionen erfordern wohl, dass ich mir pro Zeile merke, mit welchem Zustand ich diese darzustellen beginne. Ich möchte nicht bei jedem Tastendruck immer den gesamten Text neu einfärben, in HTML verwandeln und darstellen sondern minimale Änderungen am DOM machen. Tippe ich etwa '"""' um einen mehrzeiligen String zu beginnen, soll ich dann den restlichen Text mit zum Ende als String färben, den String bis zum Zeilenende als Fehler färben, weil das Ende fehlt oder gar nichts färben? Der erste Fall wäre der langsamste, weil ich die größte Änderung hätte.

Stefan

[lunar]

Wir reden also von nur 3 Rendering-Engines bei denen Gecko und Webkit zudem noch sehr ähnlich weil standardkonform sind.

Wenn du es dir leisten kannst, die Opera-Engine außen vorzulassen, ist das deine Sache ...

Wenn du aber die Zahl der zu unterstützenden Engines limitierst, dann sollten wir für einen fairen Vergleich vielleicht auch die Zahl der zu unterstützenden Desktop-Plattformen limitieren?

Schreibt man traditionelle GUI-Anwendungen, so muss man für Mac, Linux und Windows sehr spezielle und unterschiedliche Konventionen einhalten, damit sich die Anwendung nicht fremd und unvertraut anfühlt. Mac und Windows haben zum Beispiel unterschiedliche Konventionen, die die Schaltflächen eines Nachrichtenfensters benannt und angeordnet werden müssen.

Nichts für ungut, aber hast du überhaupt schon mal mit einem modernen Framework Desktop-Anwendungen entwickelt? Ich bezweifele das, sonst wüsstest du, dass solche plattformspezifischen Dinge vom Framework übernommen werden. Qt4 beispielsweise passt die Positionen der Knöpfe entsprechend der Plattform an, und erkennt dabei sogar Gnome und KDE als unterschiedliche Plattformen. Auch behandelt es beispielsweise die Menüleiste entsprechend der Plattformkonventionen.

Btw, der Unterschied zwischen einer Webanwendung und einer plattformspezifischen Desktop-Anwendung ist nochmals um Welten größer als der zwischen Desktop-Anwendungen verschiedener Systeme. Plattformkonventionen sind kein geeignetes Argument gegen Desktop-Anwendungen, weil Webanwendungen diese in der Regel noch weniger einhalten (wie sollten sie auch?).

Lunar hält das Web zwar für eine gute Plattform für die Anwendungsentwicklung, nicht jedoch für Anwendungen. Dazu möchte ich fragen, warum etwas zwar für Software-Entwickler gut sein darf, nicht aber auch für andere Anwender? Sourceforge ist eine Webanwendung für einen Anwendungsfall so wie es ein Tournierplanungsprogramm für eine andere Anwendergruppe sein könnte. Warum soll es dort keine webbasierte Lösung geben?

Vielleicht weil ein CRUD-Ticket-Framework mit ein paar Mailinglisten, etc. nicht so komplex ist wie eine Desktop-Anwendung im Stil von Word oder eine IDE im Stil von Eclipse oder VS?

Dinge wie "Authentifizierung, Sicherheit, Session- und Workflow-Managment" erwarte ich eigentlich von einem guten Web-Rahmenwerk bereits.

Ein Framework erleichtert dir die Arbeit zwar, nimmt sie dir aber nicht ab. Workflow-Managment kommt in einer GUI von selbst, da man eine einzige Navigationsstruktur hat, die den Nutzer in entsprechende Wege zwingt und so Fehler verhindert.

Bei einer Webanwendung dagegen hat man zwei parallele Navigationsstrukturen, nämlich die der Anwendung selbst, und die des Browsers. Das führt entweder zu erhöhter Komplexität, weil man erkennen muss, wenn der Anwender innerhalb eines Ablaufs den Back-Button des Browsers betätigt, oder zu Limitierung einer Navigationsstruktur, was den Benutzer, der den "Back"-Button gewohnt ist, nur verwirrt. Auch muss man mit parallelen Requests des gleichen Nutzers zurecht kommen. Zwei Dinge, die bei der Webentwicklung viel Arbeit erfordern, um die Anwendung in konsistentem Zustand zu halten, bei Desktop-Anwendungen keine Probleme bereiten, da Desktop-Anwendungen eben nicht mit Parallelitäten zurecht kommen müssen.

Versuche, Webanwendungen im Framework in einen kontinuierlichen Ablauf zu zwängen, sind eher kläglich gescheitert.

Auch muss man als Webentwickler mit wesentlich mehr inkonsistenten Technologien zurecht kommen, während Desktop-Frameworks in der Regel homogen sind.

Du kannst schlecht abstreiten, dass Webentwicklung komplexer ist als Desktop-Entwicklung.

Wenn die an einem EM-Tipp teilnehmen sollen, dann bietet sich eine Webanwendung an - die kann jeder sofort aufrufen.

Ein EM-Tipp ist eine Sache, eine DTP-Anwendung oder eine IDE eine andere Sache.

[sma]

Oh, noch ein Nachtrag: 280Slides zeigt, was als Webanwendung möglich ist. Als ehemalige Objective-C-Entwickler haben die Autoren das Ding in Objective-J geschrieben, einem objektorientierten JavaScript-Dialekt, der ad-hoc im Client zu gewöhnlichem JavaScript kompiliert wird.

Hier ist ein Codebeispiel:

Code: Alles auswählen

- (void)themePanel:(ThemePanel)aThemePanel didEndWithReturnCode:(unsigned)aReturnCode
{
    if (aReturnCode == CPCancelButton)
        return;

    var documents = [self documents],
        count = [documents count];
        
    while (count--)
        [self removeDocument:documents[0]];
    
    [super newDocument:self];
}

Das Laufzeitsystem umfasst ungefähr 2000 Zeilen JavaScript-Code.

Stefan

[sma]

lunar, ich stimme dir zu, dass Webanwendungen im Vergleich zu Desktop-Anwendungen in der Regel primitiv und einfach sind. Mir war auch nicht bekannt, dass Qt z.B. Buttons tauscht und umbenennt (Was "Save" auf dem Mac heißt, soll "OK" unter Windows lauten). Meine letzte Desktop-Anwendung habe ich vor 4 Jahren geschrieben, davor aber viele Jahre mit Smalltalk und Java kommerzielle Desktop-Anwendungen gebaut. Dort mussten wir uns immer noch eine Schicht über das Rahmenwerk ziehen, um viele plattformspezifische Probleme allgemein zu lösen. Ich kenne jedoch auch die Zeit, als auch Desktop-Anwendungen primitiv waren und das textbasierte Fenstersystem Turbovision unter DOS als Neuerung gepriesen wurde.

Die Entwicklung hat IMHO gerade erst begonnen. Sie zu verlachen, kann riskant sein, denn "low-end disruptive technologies" können etablierte Technologien verdrängen, selbst wenn diese besser sind. Das klassische Beispiel sind Hydraulikbagger, die ehemals dominierende Kabelbagger verdrängt haben. Im Kampf ums Überleben wurden diese in immer kleinere Nischen verdrängt. Das selbe kann IMHO Desktop-Anwendungen passieren.

[quote=lunar]Vielleicht weil ein CRUD-Ticket-Framework mit ein paar Mailinglisten, etc. nicht so komplex ist wie eine Desktop-Anwendung im Stil von Word oder eine IDE im Stil von Eclipse oder VS?[/quote]
Word ist in der Tat recht komplex. Eine entsprechende WYSIWYG-Layout-Engine baut man nicht mal eben. Mein Gefühl sagt mir aber, dass HTML schon recht nah von einen Layout-Funktionen dran ist, sodass es eher das Problem eines Editors ist. Vielleicht kann hier Flash helfen. Hast du dir mal Buzzword von Adobe angeschaut? Das kommt Word schon recht nah. Das ganze grafische Drumherum mit Dialogen und Menüs halte ich nicht so für das Problem. Ich könnte mir vorstellen, das man ein Word 97 auch im Web realisieren kann. Es wäre für die Mehrzahl der Anwender wahrscheinlich ausreichend.

Eine IDE halte ich im Vergleich zu Word für deutlich einfacher. Die Eclipse-Jungs überlegen ja gerade aktiv, ob man für Eclipse 4 nicht eine Webvariante baut. Einen Prototyp - bei dem der Code-Editor mit Flex für Flash gebaut ist - gibt es schon. Das Eclipse Rich Ajax Platform Projekt kann bereits jetzt "instant" Webanwendungen nach dem normalen Java-Desktop-Pattern bauen und quasi automatisch webfähig machen (allerdings wohl ohne den Code-Editor).

[quote=lunar]Workflow-Managment kommt in einer GUI von selbst, da man eine einzige Navigationsstruktur hat, die den Nutzer in entsprechende Wege zwingt und so Fehler verhindert.

Bei einer Webanwendung dagegen hat man zwei parallele Navigationsstrukturen, nämlich die der Anwendung selbst, und die des Browsers. Das führt entweder zu erhöhter Komplexität, weil man erkennen muss, wenn der Anwender innerhalb eines Ablaufs den Back-Button des Browsers betätigt, oder zu Limitierung einer Navigationsstruktur, was den Benutzer, der den "Back"-Button gewohnt ist, nur verwirrt.[/quote]
Das ist alles richtig. Das von mir erwähnte Seaside erlaubt das normale ereignisgesteuerte Desktop-GUI-Anwendungsartige Muster auch für Webanwendungen zu benutzen und kümmert sich auch um den Back-Button - das macht gerade Seaside so einzigartig. Ist leider nicht Python, aber man könnte so etwas bauen, wenn man denn Continuations als Sprachmittel hätte.

Ansonsten hilft nur, entweder dem Benutzer den Back-Button abzutrainieren (ich komme ja auch in Word nicht auf die Idee, "back" drücken zu wollen und ignoriere auch 90% der anderen angebotenen Buttons) oder aber für die Navigation innerhalb von unabhängigen Teilen der Anwendung einzusetzen.

[quote=lunar]Auch muss man als Webentwickler mit wesentlich mehr inkonsistenten Technologien zurecht kommen, während Desktop-Frameworks in der Regel homogen sind.

Du kannst schlecht abstreiten, dass Webentwicklung komplexer ist als Desktop-Entwicklung.[/quote]
Das mit den verschiedenen Technologien ist richtig und das es komplexer ist, auch. Dennoch interessiert das den Anwender wenig und für ihn sind die Anwendungen leichter und das ist alles, was zählen soll.

Die Entwicklung einfacher zu machen muss ein Thema sein, welches den Anwender gar nicht zu interessieren hat und wo wir als Software-Entwickler einfach noch unsere Hausaufgaben machen müssen. Ein Rahmenwerk wie Qt ist ja auch nicht immer da gewesen, sondern über viele Jahre gewachsen. Hast du mal für Windows 3.0 pur direkt in C (noch vor MFC) Anwendungen entwickelt? Das war auch kein Vergnügen. Dagegen war zur selben Zeit Smalltalk der Himmel auf Erden.

Stefan

[lunar]

Workflow-Managment kommt in einer GUI von selbst, da man eine einzige Navigationsstruktur hat, die den Nutzer in entsprechende Wege zwingt und so Fehler verhindert.

Bei einer Webanwendung dagegen hat man zwei parallele Navigationsstrukturen, nämlich die der Anwendung selbst, und die des Browsers. Das führt entweder zu erhöhter Komplexität, weil man erkennen muss, wenn der Anwender innerhalb eines Ablaufs den Back-Button des Browsers betätigt, oder zu Limitierung einer Navigationsstruktur, was den Benutzer, der den "Back"-Button gewohnt ist, nur verwirrt.

Das ist alles richtig. Das von mir erwähnte Seaside erlaubt das normale ereignisgesteuerte Desktop-GUI-Anwendungsartige Muster auch für Webanwendungen zu benutzen und kümmert sich auch um den Back-Button - das macht gerade Seaside so einzigartig. Ist leider nicht Python, aber man könnte so etwas bauen, wenn man denn Continuations als Sprachmittel hätte.

Das löst nicht das Problem paralleler Requests.

Ansonsten hilft nur, entweder dem Benutzer den Back-Button abzutrainieren (ich komme ja auch in Word nicht auf die Idee, "back" drücken zu wollen und ignoriere auch 90% der anderen angebotenen Buttons)

Es geht selten gut, gegen den Benutzer anzuprogrammieren

Dennoch interessiert das den Anwender wenig und für ihn sind die Anwendungen leichter und das ist alles, was zählen soll.

Findest du? Zumindest ich persönlich sehe das anders, und mein Umfeld sagt mir, dass ich damit nicht alleine stehe

Ein Rahmenwerk wie Qt ist ja auch nicht immer da gewesen, sondern über viele Jahre gewachsen. Hast du mal für Windows 3.0 pur direkt in C (noch vor MFC) Anwendungen entwickelt?

Mir hat schon C++/MFC gereicht Soweit zurück kann ich gar nicht gehen

Wie wär's, wenn wir die Diskussion an dieser Stelle mal pausieren, jeder von uns legt einen Bookmark ab, und in fünf Jahren treffen wir uns wieder und schauen, was draus geworden ist?

Ich persönlich habe nämlich das Gefühl, dass wir beide eh auf unserer Meinung beharren werden, und keiner den anderen überzeugen können wird Warten wir also einfach ab, was die Zukunft bringt

[burli]

Burli meint, drei Betriebssysteme zu unterstützen ist einfacher als 20 Browser. Meine Sicht ist eine andere. Neben dem IE (der mich persönlich gar nicht interessiert und nur wichtig ist, wenn man über Anwendungen für die Masse redet) sind IMHO noch Gecko und Webkit wichtig, wobei ich auf Webkit als letztlichen Sieger tippe, da diese Engine neben Apple von Nokia (und Trolltech), Sun, Adobe und Google unterstützt wird. Wir reden also von nur 3 Rendering-Engines bei denen Gecko und Webkit zudem noch sehr ähnlich weil standardkonform sind.

wenn du sowas machen willst das sollte das schon konsequent sein. Dh auch IE. Aber da der IE6 noch sehr verbreitet ist musst du sowohl IE6 als auch IE7 berücksichtigen. Hast du schonmal eine Webseite programmiert?

Du kannst derzeit mindestens von IE6, IE7, Gecko, Webkit und Opera ausgehen. Viel Spaß beim Fluchen. Ich fluche jedenfalls schon bei normalen Webseiten mit HTML und CSS

[DasIch]

Oh, noch ein Nachtrag: 280Slides zeigt, was als Webanwendung möglich ist. Als ehemalige Objective-C-Entwickler haben die Autoren das Ding in Objective-J geschrieben, einem objektorientierten JavaScript-Dialekt, der ad-hoc im Client zu gewöhnlichem JavaScript kompiliert wird.

Damit will ich nicht arbeiten müssen. Ist ja unglaublich langsam und bis erstmal die Webseite geladen ist.
Dann kann man da natürlich kein Kontextmenü benutzen wie man es in Desktop Anwendugen kann. Bevor man da überhaupt nur irgendwas macht hat man schon keine Lust mehr.

[burli]

Oh, noch ein Nachtrag: 280Slides zeigt, was als Webanwendung möglich ist. Als ehemalige Objective-C-Entwickler haben die Autoren das Ding in Objective-J geschrieben, einem objektorientierten JavaScript-Dialekt, der ad-hoc im Client zu gewöhnlichem JavaScript kompiliert wird.

Damit will ich nicht arbeiten müssen. Ist ja unglaublich langsam und bis erstmal die Webseite geladen ist.
Dann kann man da natürlich kein Kontextmenü benutzen wie man es in Desktop Anwendugen kann. Bevor man da überhaupt nur irgendwas macht hat man schon keine Lust mehr.

Den Link hab ich gar nicht gesehen. Sowas gefällt dir? Ist ja grausig

[kbrust]

Dann kann man da natürlich kein Kontextmenü benutzen wie man es in Desktop Anwendugen kann.

Wieso "natürlich"? Die genannte Applikation hat das nicht implementiert, aber grundsätzlich gibt es da kein Hinderniss (Sieh z.B. den Webmailer von Yahoo. Funktioniert tadellos).

Was die gesamte Diskussion angeht:

Grundsätzlich kann ich mir eine Zukunft mit Webanwendungen vorstellen. Ich kann auch nicht ganz nachvollziehen das hier Argumente wie "Ist viel zu umständlich zu implementieren", "Es werden zuviele unterschiedliche Technologien benutzt" und "Sowas gehört einfach nicht in einen Browser" vorgebracht werden.

Ja, moderne Desktop-Toolkits sind weitaus mächtiger. Ja, zur Zeit können Webanwendungen diese nicht einfach verdrängen oder ersetzen. Aber man muss sich doch nur mal anschauen was für Quantensprünge in dem Bereich passiert sind - und das mit veraltetem "Werkzeug" das nie für diesen Zweck dedacht war.

Klar, zur Zeit ist es umständlich um die verschiedenen Fallstricke der unterschiedlichen Browser herum zu schippern. Aber es bessert sich. Die Standarisierung schreitet voran, selbst ein IE zieht da mit (IE 8 ist ja auch nicht mehr so fern). Es sind in den letzten Jahren duzende Javascript-Frameworks erschienen, die einem die Arbeit erleichtern und Funktionalität wie Drag&Drop in wenige Codezeilen packen lassen.

Ich schätze in 5 Jahren ist der Prozess noch nicht abgeschlossen. Aber innerhalb dieser Zeit wird sich einiges tun. Wer sagt, das zukünftige Webanwendungen in einem Browser wie wir ihn heute kennen bedient werden? Viel wahrscheinlicher ist das neue Plattformen entwickeln werden und man sich bei den dazugehörigen Frontends keine Gedanken mehr über einen "Zurück"-Button machen muss.

Werden klassische Desktop-Anwendungen verdrängt? We'll see. Vielleicht, vielleicht auch nicht. Aber das Distributionsmodell Webanwendung hat einfach zu viele Vorteile als das es einfach von der Bildfläche verschwindet.

[sma]

[quote=lunar]Wie wär's, wenn wir die Diskussion an dieser Stelle mal pausieren, jeder von uns legt einen Bookmark ab, und in fünf Jahren treffen wir uns wieder und schauen, was draus geworden ist?[/quote]
Guter Vorschlag :)

Aber ich glaube, dass das wir für einen Trend nicht 5 Jahre warten müssen...

[quote=burli]Du kannst derzeit mindestens von IE6, IE7, Gecko, Webkit und Opera ausgehen.[/quote]
Opera hat IMHO keine Marktbedeutung. Für Entwicklertools haben wir uns bislang auf IE7 und Firefox beschränkt - die Gecko-Variante lief aber ohne Änderungen auch mit Webkit. Da FF kostenlos für alle von uns unterstützten Plattformen verfügbar ist, wäre es sogar in unserem Fall denkbar gewesen, den IE zu ignorieren. Allerdings wäre es aufwendiger, dass zu verargumentieren als den IE mit zu unterstützen. Für die Zukunft könnte ich mir vorstellen, Adobe AIR zur Auslieferung zu benutzen, was bedeuten würde, das man nur noch Webkit unterstützen muss. Diesen "Luxus" hat aber nicht jeder.

Für einen Massenmarkt sollte man noch IE6 unterstützen, da die Verteilung IE6-IE7 immer noch etwa 1:1 ist. Die Entwicklung im standardkonformen Modus für die verschiedenen Browser finde ich nicht so schwer - es ist nur total lästig, das für die jeweiligen Betriebssysteme und Browser zu testen, da dies ein weitestgehend manueller Prozess ist - oder welches Testwerkzeug findet Darstellungsfehler im Boxmodell?

[quote=DasIch]280Slides: Damit will ich nicht arbeiten müssen. Ist ja unglaublich langsam und bis erstmal die Webseite geladen ist.[/quote]
Dauert bei mir etwa 4 Sekunden. Laut Firebug werden etwa 450 KB mit 151 Requests geladen - das meiste sind Bilder. Ich vermute jedoch, dass Firebug das Nachladen der ".j"-Dateien nicht registriert.

Und mir ist nicht klar, was an 280 Slides grausig sein soll.

Stefan

[BlackJack]

Ich habe keine Ahnung ob das "Programm" grausam ist, weil's bei mir nicht funtkioniert. Im Konqueror hängt's am Ladebalken und im Firefox zieht's nach dem laden plötzlich 100% CPU und nix geht mehr.

[mitsuhiko]

Burli meint, drei Betriebssysteme zu unterstützen ist einfacher als 20 Browser. Meine Sicht ist eine andere. Neben dem IE (der mich persönlich gar nicht interessiert und nur wichtig ist, wenn man über Anwendungen für die Masse redet) sind IMHO noch Gecko und Webkit wichtig, wobei ich auf Webkit als letztlichen Sieger tippe, da diese Engine neben Apple von Nokia (und Trolltech), Sun, Adobe und Google unterstützt wird. Wir reden also von nur 3 Rendering-Engines bei denen Gecko und Webkit zudem noch sehr ähnlich weil standardkonform sind.

[ ] du hast mal eine Webanwendung entwickelt.

Sowohl Firefox als auch Webkit sind voller Bugs und ich kenn keinen Bug der gleichzeitig in beiden Auftritt. Das Web ist eine Katastrophe und ich seh nicht ein warum man diese Technologie noch weiter in Gebiete tragen soll für die sie nicht geeignet ist.

Zuerst muss ein anderes Protokoll her, und dann JavaScript 2. Und danach können wir weiterreden. Bis dahin nutzt man JavaScript um Unfug zu machen