Vorteile von Nicht-Web-Applikationen?
-
Ich muss mich gerade zwischen Web-Applikation und "normaler" Client-Applikation entscheiden.
Welche Vorteile hat denn eine Client-Applikation gegenüber Web-Applikationen heutzutage überhaupt noch? Ich sehe da bspw. "funktioniert evtl. auch Offline". Wobei das bei einem Programm, das Daten eines Standortes an verschiedenste Außendienstmitarbeiter weitergeben soll eher sinnlos klingt das offline zu starten ... es sei denn man cached da halbe Datenbanken ...
Welche Vorteile fallen euch ein?
MfG SideWinder
-
- ist nicht abhängig von w3c-zeugs, rfc's, xml, soap-specs, webservices, internetprotokollen und sowas, also: weniger kompexität, weniger code, kleinere executables, bessere performance, etc. braucht weniger kram auf dem client, keinen webbrowser, xml-pareser usw. daher gut geeignet für thin clients und embedded systeme.
- protokolldesign, architektur, topologie usw. sind frei wählbar, push/pull, peer-to-peer, serverbasiert, was du willst...
- grösseres potential um neue technologien zu schaffen (siehe z.b. bittorrent-systeme)
mehr fällt mir grad nicht ein. gibt aber bestimmt noch viel mehr argumente...
-
Ich hab noch keine Web-app gesehen, mit der man so komfortabel arbeiten kann wie mit normalen client-app.
-
//fricky schrieb:
- ist nicht abhängig von w3c-zeugs, rfc's, xml, soap-specs, webservices, internetprotokollen und sowas
Und warum ist das für Dich ein Vorteil? Was ist der Nachteil solcher Specs? Bei einem Rich Client ist man dafür von ganz anderen Sachen abhängig, z.b. einem GUI Framework etc.
weniger kompexität, weniger code, kleinere executables, bessere performance
Sehe ich anders. Wenn der Code auf dem Server abläuft, könnte die Peformance auf dem Client nicht besser sein. Ein Executable gibts gar nicht (abgesehen vielleicht von JavaScript) und die Performance ist idR besser als bei Rich Clients (es muss nicht ein ganzes System hochgefahren werden, nur um kurz ein paar Daten abzurufen). Weniger Code kann ich auch nicht unterschreiben. Für die meisten GUI Frameworks ist doch extrem viel Boilerplate Code erforderlich.
braucht weniger kram auf dem client, keinen webbrowser, xml-pareser usw. daher gut geeignet für thin clients und embedded systeme.
Spätestens jetzt kann ich Deiner Argumentation nicht mehr folgen. Du redest doch grade von Rich Clients. Da braucht man doch deutlich mehr Kram auf dem Client als bei einer Webanwendung. Einen Browser gibts eh überall. Den Rich Client musst Du erstmal runterladen / installieren. Und Du brauchst auch alle abgängigen Bibliotheken usw. Beim Webclient brauchst Du gar nichts, ausser einen Browser. XML-Parser bei einem Weblcient? Wovon sprichst Du? Die bruachst Du wohl eher bei einem Richclient, wenn Du XML Daten laden willst. Beim Webclient bringt der Webbrowser alles mit, und der ist nahezu überall schon installiert.
protokolldesign, architektur, topologie usw. sind frei wählbar, push/pull, peer-to-peer, serverbasiert, was du willst...
Das ist richtig, wenn auch hier Webserver nachlegen. Javas Servlet Spec fürs kommende JEE 6 unterstützt z.B. Server Pushs. Heute gibts dafür aber auch schon Libraries wie Comet. Und es spricht ja auch schon heute nichts dagegen, bei einer Webanwendung jede erdenkliche Technologie oder Architektur serverseitig zu verwenden.
-
byto schrieb:
//fricky schrieb:
- ist nicht abhängig von w3c-zeugs, rfc's, xml, soap-specs, webservices, internetprotokollen und sowas
Und warum ist das für Dich ein Vorteil? Was ist der Nachteil solcher Specs?
sie sind oft viel zu umfassend und für so manche anwendung viel zu übertrieben. die meisten benutzer sind sich garnicht dessen bewusst, wie viel code auf ihrem client involviert ist, wenn sie eben mal eine webseite aufrufen. das ist 'ne menge holz. und wehe, du hast irgendwas nicht schon da, oder nicht als library verfügbar und musst es selbst implementieren. das kann ganz schön lange dauern.
byto schrieb:
weniger kompexität, weniger code, kleinere executables, bessere performance
Sehe ich anders. Wenn der Code auf dem Server abläuft, könnte die Peformance auf dem Client nicht besser sein.
ich meinte den speed der clients. die brauchen weniger rechenzeit wenn sie z.b. keine soap-envelopes auspacken, xml parsen und generieren müssen, usw. die haben dadurch viel bessere reaktionszeiten. demzufolge können kleinere prozessoren und weniger kostspielige hardware eingesetzt werden. spielt z.b. eine rolle bei sogenannten 'internet appliances'.
byto schrieb:
Ein Executable gibts gar nicht
klar, z.b. einen relativ fetten webbrowser brauchste auf'm client und auf der servermaschine läuft ein webserver, der vielleicht pHP, java-EE, was weiss ich noch alles braucht. dabei reicht oft schon sowas: http://www.sics.se/~adam/uvnc/ auf dem server und die software der clients kann auch entsprechend klein sein.
byto schrieb:
braucht weniger kram auf dem client, keinen webbrowser, xml-pareser usw. daher gut geeignet für thin clients und embedded systeme.
Spätestens jetzt kann ich Deiner Argumentation nicht mehr folgen.
das kommt, weil wir's aus verschiedenen blickwinkeln sehen. ich sehe ein gerät, das in einer maschine eingebaut ist, damit sie übers internet kommunizieren kann. du siehst es aus der perspektive eines pc-users mit fettem OS, viel speicher und rechenpower, wo sowieso schon alles dabei ist.
btw, und nicht dass hier ein glaubenskrieg entsteht. ich bin auf die frage des OP eingegangen und wollte nicht über standardisierte webtechnologien wettern.
-
Ich sehe den Vorteil von Fatclients hauptsächlich darin, dass man dort einfach grafisch aufwendige Anwendungen erstellen kann. Unter Java gibt es z.B. mit JGraph und JasperReports Bibliotheken, deren umfangreiche Gestaltung nur sehr schwer im Web nachzubilden ist.
Sonst überwiegen aber imo in der Regel die Vorteile einer Webanwendung..
-
Headhunter schrieb:
Unter Java gibt es z.B. mit JGraph und JasperReports Bibliotheken, deren umfangreiche Gestaltung nur sehr schwer im Web nachzubilden ist.
Man kann viel machen mit JavaScript, CSS,Ajax usw. Der browser kann Java-Applets, Flash oder die neue Silverlight-technologie von Microspoft benutzen.
-
Sehe keine Vorteile mehr ... irgendwann gibts nurnoch Web-Applikationen und Storage.
Wer hier sogenante nachteile von Web-Applikationen aufzählt hat doch nur keine Ahnung
-
normale client apps sind meist übersichtlicher.
die gui funktioniert schneller, macht weniger zicken.
braucht weniger ram und weniger rechenleistung.
gewisse dinge kann der client selbst machen, was den server entlastet.
-
hustbaer schrieb:
normale client apps sind meist übersichtlicher.
die gui funktioniert schneller, macht weniger zicken.
braucht weniger ram und weniger rechenleistung.
gewisse dinge kann der client selbst machen, was den server entlastet.Aber hat das in Zeiten von Ajax noch Bestand? Ist das nicht vielleicht nur noch 1-2 Jahre so, und dann muss man sich von Client-Applikationen bald ganz verabschieden?
Ist eine Neuentwicklung einer Web-Applikation überhaupt zukunftssicher?
MfG SideWinder
-
Also ich hab zwar nur vor ein paar Jahren ein paar kleine Web-Applikation geschrieben, aber was mir da schon aufgefallen ist, dass sich jeder Browser in Details anders verhält und das nervt.
-
PRIEST schrieb:
Sehe keine Vorteile mehr ... irgendwann gibts nurnoch Web-Applikationen und Storage.
das führt uns zu einem weiteren gegenargument: nicht jeder benutzer möchte, dass seine privaten daten durch irgendwelche netze schwirren (trotz unknackbarer crypto-verfahren). alles lokal zu haben schafft bei vielen ein gefühl der sicherheit.
PRIEST schrieb:
Wer hier sogenante nachteile von Web-Applikationen aufzählt hat doch nur keine Ahnung
bezeichnenderweise wird gerade dieser spruch meistens von ahnungslosen gebracht.
harumrum schrieb:
...dass sich jeder Browser in Details anders verhält und das nervt.
dass lag daran, dass der IE von m$ CSS nicht richtig konnte und HTML und JS eigenwillig interpretierte. ist heute nicht mehr so schlimm.
-
SideWinder schrieb:
Aber hat das in Zeiten von Ajax noch Bestand?
Hoffentlich. Ajax ist mehr ein Workaround denn eine Innovation; technologisch wäre das ein Rückschritt.
Bei StackOverflow kam das Thema u.a. hier auf. Die ganze Problematik wird von folgendem Satz recht gut zusammengefaßt:
Henk Holtermann schrieb:
The technical trade-off is clear: a web app still takes more effort for less functionality.
-
audacia schrieb:
Ajax ist mehr ein Workaround denn eine Innovation; technologisch wäre das ein Rückschritt.
wohl sowas wie c++, ne?
aber im ernst, es gibt tolle ajax-basierte software, wie sowas z.b. http://eyeos.org/de/
-
//fricky schrieb:
aber im ernst, es gibt tolle ajax-basierte software, wie sowas z.b. http://eyeos.org/de/
Es gibt auch jede Menge toller Software, die in C++ geschrieben wurde. Das will gar nichts heißen
-
aber im ernst, es gibt tolle ajax-basierte software, wie sowas z.b. http://eyeos.org/de/
Man soll ja bereits mit Assembler zum Mond gekommen sein
-
JustAnotherNoob schrieb:
aber im ernst, es gibt tolle ajax-basierte software, wie sowas z.b. http://eyeos.org/de/
Man soll ja bereits mit Assembler zum Mond gekommen sein
lach du nur... hast du's schon mal getestet? kannst ganz einfach auf dem demo-server 'nen benutzer anlegen und ausprobieren. ich find's garnicht so schlecht. schalte den browser dann noch in den fullscreen-mode und du denkst, du sitzt vor irgend so'ner linux-kiste.
-
//fricky schrieb:
PRIEST schrieb:
Wer hier sogenante nachteile von Web-Applikationen aufzählt hat doch nur keine Ahnung
bezeichnenderweise wird gerade dieser spruch meistens von ahnungslosen gebracht.
genau wie deiner ;)!
-
//fricky schrieb:
lach du nur... hast du's schon mal getestet? kannst ganz einfach auf dem demo-server 'nen benutzer anlegen und ausprobieren. ich find's garnicht so schlecht. schalte den browser dann noch in den fullscreen-mode und du denkst, du sitzt vor irgend so'ner linux-kiste.
Ich habe es soeben getestet.
Alle Reaktionen sind ungewohnt langsam, was aber nicht wirklich stört.
Die Arbeit damit ist lahm. Im Textverarbeitunsgprog mal 10 Zeilen zu pasten dauert auch 10 Sekunden, die schön nachlaufen, während man Däumchen dreht.
-
volkard schrieb:
Alle Reaktionen sind ungewohnt langsam, was aber nicht wirklich stört.
Die Arbeit damit ist lahm.liegt wohl an deinem computer, deinem browser oder vielleicht war grad mal engpass bei der internetverbindung. aber wir haben schon wieder ein argument gegen cloud computing und webanwendungen: potentiell miese performance und reaktionszeiten sind abhänging von der qualität und leistungsfähigkeit aller einzelkomponenten.
