Vorteile von Nicht-Web-Applikationen?
-
@Artchi: Aber ist es nicht letzten Endes für den durchschnittlichen Benutzer (nicht für uns erzwungene Profi-Anwender, weil wir nunmal jeden Tag mit dem Ding intensiv arbeiten) egal wie sich das anfühlt, weil er nach x Tagen darauf eingearbeitet ist? (solange die Bedienung nicht gänzlich jeglichem Usus entgegenarbeitet). Die Masse kauft doch einen Apple nicht, weil der ein für Sie angenehmeres Bedienkonzept hat sondern weil der angeblich besser ist, der derzeit "in" und "cool" ist und als Burner-Argument gibt es "keine Viren für Macs". Also zählt ein soclhes Argument doch eher nur bei "applications for professionals" (Begriff:
)MfG SideWinder
-
Meiner bescheidenen Meinung nach eignen sich Web-Anwendungen primaer wenn es darum geht das a) mehrere Anwender zusammen arbeiten sollen und b) man die Daten mobil verfuegbar haben will/muss. Wobei es immer gilt, es sollte immer moeglich sein die Daten auch auf seinen Recher zu holen und sie offline bearbeiten. Das funktioniert bei Email sehr gut mit IMAP und mit dezentralen VCS wie git oder mercurial.
Leider denken viele dass man nur eine Web-App haben muss und man alles online erledigen kann. Vielleicht in 15 Jahren, aber das Internet z.Z. ist einfach nicht dazu gedacht. Eine Web-App, wie ein Forum, online Shop, Facebook oder eine Wiki sind beliebt und funktionieren gut, weil offline macht es wenig bis keinen Sinn sie zu benutzen. Fuer andere Anwendungen ist es einfach nur idiotisch sie als nur-online Version anzubieten (wie z.B. Office, ein Betriebsystem oder andere diese "Cloud"-Computing-Sachen). Wenn man mit mehreren Leuten an einem Office-Dokument arbeiten muss, wieso muss ich den Text im Browser eintippen? Wieso uebernimmt die Cloud-App nicht das Synchronisieren und das Verteilen und ich kann immernoch mein lieblings-Word-Processor benutzen? Geht z.B. mit ODF und Git sehr gut, weil ODF ein XML-Dokument ist (wenn man es nicht komprimiert).
-
Ich glaube es wurde noch nicht genannt:
- Verfügbarkeit ist bei Fat Clients zumindest bei mir höher. Sei es, weil aus irgendwelchen Gründen meine INet-Anbindung mal nicht richtig will oder auf dem Server Wartungsarbeiten ausgeführt werden. Text-Dokumente, die kein aufwändiges Layout brauchen, schreibe ich gerne in Buzzword; letztens war kurz vor einem wichtigen Abgabe-Termin der Server down, das war echt fies.
- Verantwortung: Wenn für deine Web-App auf dem Server Kundendaten/Nutzerdaten gespeichert werden, musst du wirklich sichergehen, dass sie nicht in falsche Hände geraten können.
Und ich schätze, dass Web-Applikationen in der Regel Wartungs-intensiver sind. Ein Windows-Binary z.B. überlebt im Idealfall 3 oder 4 OS-Upgrades ohne große Anpassung.
-
Irgendwie verwunderts wenig, dass in einem C++ Forum eher Skepsis ggü. modernen Webtechnologien herrscht.
-
byto schrieb:
Irgendwie verwunderts wenig, dass in einem C++ Forum eher Skepsis ggü. modernen Webtechnologien herrscht.
Unglaublich wie die Leute die Kurve von Hat-Nichts-Mit-C++-zutun zum C++-und-seine-User-sind-eh-Loser bekommen.
-
Wobei es natürlich totaler Quatsch ist, das C++ und seine User generell was gegen Web-Apps haben. Wo man doch sogar mit C++ AJAX-Anwendungen programmieren kann:
http://www.webtoolkit.eu/wtDieses Beispiel, ein Git-Explorer ist damit programmiert:
http://www.webtoolkit.eu/wt/examples/gitmodel/gitview.wtWidgets-Examples:
http://www.webtoolkit.eu/widgets
-
Bulli schrieb:
Wo man doch sogar mit C++ AJAX-Anwendungen programmieren kann:
Das ist eher die Ausnahme. in der Regel wird C++ im Webbereich nicht verwendet.
-
general bacardi schrieb:
Bulli schrieb:
Wo man doch sogar mit C++ AJAX-Anwendungen programmieren kann:
Das ist eher die Ausnahme. in der Regel wird C++ im Webbereich nicht verwendet.
Hat Bulli behauptet, das hauptsächlich C++ für Web-Apps eingesetzt wird?
Lediglich die Möglichkeit aufgeführt, das es technisch geht und wenn man wollte, eine Lib nutzen könnte.Es wurde aber auf jeden Fall widerlegt, das C++-User generell was gegen "moderne" Web-Technologien haben. Wobei das modern auch nicht stimmt, wie mir ein Java-Web-Kollege erzählt hat. AJAX gibt es schon ewig und gehört zum alten Eisen, ist halt nur jetzt hipp geworden, weil die Leitungen beim Kunden und Server schneller geworden sind.
-
Artchi schrieb:
general bacardi schrieb:
Bulli schrieb:
Wo man doch sogar mit C++ AJAX-Anwendungen programmieren kann:
Das ist eher die Ausnahme. in der Regel wird C++ im Webbereich nicht verwendet.
Hat Bulli behauptet, das hauptsächlich C++ für Web-Apps eingesetzt wird?
Habe ich behauptet, dass jemand das behauptet hat?
-
Bulli schrieb:
byto schrieb:
Irgendwie verwunderts wenig, dass in einem C++ Forum eher Skepsis ggü. modernen Webtechnologien herrscht.
Unglaublich wie die Leute die Kurve von Hat-Nichts-Mit-C++-zutun zum C++-und-seine-User-sind-eh-Loser bekommen.
Interessante Wertung aus einer sonst recht neutralen Schlussfolgerung meinerseits.
Fakt ist, dass C++ im Webbereich eher eine untergeordnete Rolle spielt. Ergo arbeiten wahrscheinlich die wenigsten C++ Entwickler in Webprojekten. Und dass man eher dem aufgeschlossen ist, was man täglich erlebt, ist ja nicht verwunderlich.
-
byto schrieb:
Fakt ist, dass C++ im Webbereich eher eine untergeordnete Rolle spielt. Ergo arbeiten wahrscheinlich die wenigsten C++ Entwickler in Webprojekten. Und dass man eher dem aufgeschlossen ist, was man täglich erlebt, ist ja nicht verwunderlich.
Ehm, wie jetzt? Also C++-Progger benutzen/erleben keine Web-Apps?
Sorry, aber das ist blödsinn! Ich denke schon, das C++-Progger auch täglich Web-Apps nutzen.Laut deiner Schlußfolgerung, dürften PHP-Progger keine Erlebnisse mit C++-Programmen haben.
-
Artchi schrieb:
Laut deiner Schlußfolgerung, dürften PHP-Progger keine Erlebnisse mit C++-Programmen haben.
Das wird ja immer Verrückter. Was bist DU denn für ein seltsamer troll
-
byto schrieb:
Interessante Wertung aus einer sonst recht neutralen Schlussfolgerung meinerseits.
Bis zu deinem Posting hat keiner C++ ins Spiel gebracht. Wie man das eingeworfene "C++-Programmierer" als neutral einstufen kann, zeigt, das es nur wieder um einen C++-Flamewar geht. Lass es doch einfach und bleib beim Thema Web-Apps!
-
general bacardi schrieb:
Artchi schrieb:
Laut deiner Schlußfolgerung, dürften PHP-Progger keine Erlebnisse mit C++-Programmen haben.
Das wird ja immer Verrückter. Was bist DU denn für ein seltsamer troll
Danke für die Bestätigung der hirnrissigen Logic von byto.
Ich habe einfach nur die Begriffe ausgetauscht, um mal zu zeigen was wieder abgeht.Geht es in diesem Thread um Web-Apps oder um C++? Eben!
-
Artchi schrieb:
general bacardi schrieb:
Artchi schrieb:
Laut deiner Schlußfolgerung, dürften PHP-Progger keine Erlebnisse mit C++-Programmen haben.
Das wird ja immer Verrückter. Was bist DU denn für ein seltsamer troll
Danke für die Bestätigung der hirnrissigen Logic von byto.
Ich habe einfach nur die Begriffe ausgetauscht, um mal zu zeigen was wieder abgeht.Geht es in diesem Thread um Web-Apps oder um C++? Eben!
Kommt darauf an ob du die Allgemeinheit fragst, oder fricky
-
Back to topic: Web-Apps vs. Client-Apps. ganz ohne C++ und Flames
Mir sind in letzter Zeit mehrere Applikationen über den Weg gelaufen die den Zwischenweg gehen bzw. beides möglich machen: Ein sauberer geschichteter Aufbau, bei dem mehrere Transportschichten eingebaut sind. Diese können je nach Bedarf ausgetauscht werden. Entweder als lokale "Durchreiche", wo die beiden angrenzenden Schichten direkt zusammengelinkt werden, oder als Webservice, per http als Java-Thin-Client, ganz wie mans braucht. So kann ein und dasselbe Programm als Monolith auf einem einzelnen Rechner laufen oder mit einem Thin Client als Webapp gestartet werden, während die Dialogsteuerung, Fachlogik und ggf. Persistenzschichten auf ein oder mehreren Servern liegen, oder eben als fat client wo Dialogsteuerung und eventuell auch Fachlogik mit auf Clientseite sind.
Ich denke, dass die Möglichkeiten mannigfaltig sind und die Entscheidung, wie flexibel das System sein soll sich ausschließlich am Einsatzgebiet orientieren sollte.
-
pumuckl schrieb:
Mir sind in letzter Zeit mehrere Applikationen über den Weg gelaufen die den Zwischenweg gehen bzw. beides möglich machen: Ein sauberer geschichteter Aufbau, bei dem mehrere Transportschichten eingebaut sind. Diese können je nach Bedarf ausgetauscht werden. Entweder als lokale "Durchreiche", wo die beiden angrenzenden Schichten direkt zusammengelinkt werden, oder als Webservice, per http als Java-Thin-Client, ganz wie mans braucht. So kann ein und dasselbe Programm als Monolith auf einem einzelnen Rechner laufen oder mit einem Thin Client als Webapp gestartet werden, während die Dialogsteuerung, Fachlogik und ggf. Persistenzschichten auf ein oder mehreren Servern liegen, oder eben als fat client wo Dialogsteuerung und eventuell auch Fachlogik mit auf Clientseite sind.
Ich denke, dass die Möglichkeiten mannigfaltig sind und die Entscheidung, wie flexibel das System sein soll sich ausschließlich am Einsatzgebiet orientieren sollte.Das stimmt. Man sollte größere Anwendungen vielleicht immer so schreiben, daß einezelen Komponenten über Schnittstellen kommunizierem, die lokal als auch über Netze möglich sind. Das X-Window System ist ein bekanntes Beispiel für diese Strategie
-
Artchi schrieb:
byto schrieb:
Fakt ist, dass C++ im Webbereich eher eine untergeordnete Rolle spielt. Ergo arbeiten wahrscheinlich die wenigsten C++ Entwickler in Webprojekten. Und dass man eher dem aufgeschlossen ist, was man täglich erlebt, ist ja nicht verwunderlich.
Ehm, wie jetzt? Also C++-Progger benutzen/erleben keine Web-Apps?
Sorry, aber das ist blödsinn! Ich denke schon, das C++-Progger auch täglich Web-Apps nutzen.Interessante Zerhackstückelung meines Beitrags. Dass ich mich auf die Arbeit bezog, hast Du aber schon gemerkt oder? Falls nein, habe ich die entsprechende Textstelle mal für Dich markiert. Evtl. fällt das Verstehen des Gelesenen dann leichter.
-----
Man hat doch heutzutage häufig die Wahl zwischen einem Richclient oder einem Webclient als Frontend (sieht man ja schon am Thema dieses Threads). Wenn ich nun als Programmierer täglich Richclients implementiere, dann werde ich wohl Richclients aufgeschlossener gegenüber stehen als Webclients. Umgekehrt gilt das gleiche.
C++ Anwendungen (falls grafisches Frontend vorhanden) werden idR als Richclient entwickelt. Daher ist das bisherige Fazit dieses Threads nicht verwunderlich.
Und mal unter uns: Webthemen werden in diesem Board unter Spezialitäten -> Webzeugs abgestempelt. Wer erwartet da bitte eine ernsthafte Diskussion zum Thema Webclients?
-
general bacardi schrieb:
Das stimmt. Man sollte größere Anwendungen vielleicht immer so schreiben, daß einezelen Komponenten über Schnittstellen kommunizierem, die lokal als auch über Netze möglich sind. Das X-Window System ist ein bekanntes Beispiel für diese Strategie
In der Java-Welt lässt sich sowas sehr elegant mit dem Spring Framework erreichen. Wir haben beispielsweise verschiedene Dienste implementiert, die Daten aus einer DB bereitstellen oder bestimmte Berechnungen machen. Manche Dienste laufen automatisiert als Jobs zu bestimmten Zeiten ab. Die Dienste sind ganz einfache POJOs.
Mit Hilfe von Spring können wir die Dienste nun beliebig bereitstellen. Wir benutzen einen Webserver, der die Dienste über HTTP bereitstellt. Ohne den Sourcecode zu ändern, könnten wir die Dienste aber auch über ein anderes Verbindungsprotokoll anbieten, z.B. als Webservice über SOAP. Wir könnten die Anwendung aber auch einfach als Standalone Applikation builden. Dann kommen wir ganz ohne Server aus. Das ist alles mit ein bißchen Konfiguration problemlos möglich.
Als Frontend kommt übrigens ein Richclient zum Einsatz. Man könnte das ganze ohne weiteres um ein Webfrontend ergänzen.
-
byto schrieb:
Irgendwie verwunderts wenig, dass in einem C++ Forum eher Skepsis ggü. modernen Webtechnologien herrscht.
Das hat mit Skepsis weniger zu tun als mit Fakten.
