Web versus Desktop-Entwicklung - ist Web-Entwicklung schlimmer? [geschlossen]


29

Was sind die Vor- und Nachteile einer Webentwicklung als langjähriger Desktop-Entwickler, der unsere erste groß angelegte Webanwendung entwickeln möchte?

Ist die Entwicklung einer Webanwendung viel schlimmer als die Entwicklung einer Desktopanwendung? ZB ist es langweiliger oder nerviger? Ist die Zeit, um viel schlechter zu vermarkten? Ist die Webplattform übermäßig einschränkend? Wenn die Antwort auf eine dieser Fragen ja lautet, warum dann?

(Und wie vergleicht sich die Entwicklung einer Flash- oder Silverlight-App?)


5
Ich habe nicht für den Abschluss gestimmt, aber ich denke, dass es konstruktiver sein könnte, wenn es in einen Webentwicklungs- oder Desktopentwicklungsstandpunkt umgewandelt werden könnte.
Josh K

K: Okay, ich habe versucht, die Frage neu zu formulieren, ohne die vorhandenen Antworten ungültig zu machen. Vielen Dank.
Josh Kelley

Antworten:


26

Nein

Es ist schmerzhaft, wenn Sie nicht wissen, was Sie tun oder nicht richtig planen, aber das gilt für jede Entwicklung. Es ist einfacher, die Anwendung in eine Desktopanwendung einzufügen, aber dann verlieren Sie die Barrierefreiheit, die durch das Codieren einer Webanwendung bereitgestellt wird.

Ich würde die Wahl zwischen Desktop und Web basierend auf der gewünschten Verwendung treffen. Ich sehe viele Anwendungen, die webbasiert geschrieben wurden und nicht sein sollten, weil sie nicht wissen, wie man Desktop-Anwendungen codiert. Ich sehe jedoch nicht viele Desktop-Anwendungen, die webbasiert sein sollten, und ich denke, das ist etwas, das berücksichtigt werden muss. Wenn Sie den zentralen Speicher, den Fernzugriff und die Benutzeroberfläche benötigen, sind Sie sicher .

Ich kann Flash oder Silverlight nicht kommentieren, da ich auch keine verwende.


5
Ich hasse es, dieser Typ zu sein , aber ... :s/loose/lose/:)
Dr. Hannibal Lecter

@ Dr. Hannibal: Es wurde behoben. Manchmal tippe ich zweimal auf die Tasten. ;)
Josh K

4
@ Dr. Hannibal: Es gibt eine solche kognitive Dissonanz, die von den Worten "Ich hasse es, dieser Typ zu sein" kommt von "Hannibal Lecter" :)
Skilldrick

25

Wie von anderen erwähnt, geht es um Kompromisse und um das richtige Wissen.

Die einzige Gefahr, die Sie in Betracht ziehen könnten, ist die folgende: Sie erwähnen in Ihrer Frage, dass Sie das Web als "plattformübergreifend" betrachten. Aber ist es wirklich so? Stellen Sie sich das so vor: Wenn Sie etwas für den Desktop entwickeln, müssen Sie die Liste der zu unterstützenden Plattformen und deren Anforderungen definieren.

Machen Sie keinen Fehler, es ist das gleiche für das Web. Und auch wenn es bereits viel einfacher ist als früher, müssen Sie sich mit jeder möglichen Version jedes Webbrowsers auseinandersetzen, wenn Sie eine breite öffentliche App entwerfen. Wenn es sich eher um eine Unternehmensanwendung handelt, können Sie sich darauf vorbereiten, die Anforderungen für die unterstützten Browserplattformen sehr genau zu formulieren.

Denken Sie nicht, dass Sie plattformspezifische Hacks hier und da vermeiden, wenn Sie etwas Bedeutendes aufbauen.

Und dann die lustigen Teile. Was ist das beste? Browser, die sich fast transparent sehr regelmäßig aktualisieren, wie Chrome? Oder diejenigen, die Sicherheitsupdates nur monatlich bereitstellen und wichtige Funktionen in jeder Steinzeit bereitstellen (z. B. IE)? Die Antwort ist nicht so offensichtlich, wie Sie vielleicht denken, da einige dieser häufigen "transparenten" Aktualisierungen möglicherweise Ihren Code beschädigen und Sie diesem folgen und sofort reagieren müssen. Oder behalten Sie die Beta und Dev Pre-Releases im Auge, während Sie entwickeln und testen. Für alle Browser, die Sie dummerweise unterstützt haben (viel Glück).

Oh und lasst uns die UI-Überlegungen nicht vergessen. Sie haben auch die Freude, zu entscheiden, ob Sie eine konsistente Benutzeroberfläche für die Zielplattform wünschen alle Zielplattformen hinweg oder eine konsistente Benutzeroberfläche mit möchtenZielplattform jedes Hosts. Sehen Sie all die kleinen Schaltflächen, die Sie auf Webseiten anzeigen können? Möchten Sie, dass sie überall exakt gleich sind oder sich in die von Ihrem Benutzer verwendete Umgebung integrieren lassen? Natürlich ist dieses Problem nicht neu und existierte für andere Entwicklungsmodelle, aber es scheint hier wichtiger zu sein und hängt von der Art der Benutzer ab, die Sie ansprechen und was sie erwarten. Öffentliche Endbenutzer möchten in der Regel, dass Sie sich in ihre Plattform integrieren, möchten aber dennoch, dass Sie "wow!" sie mit ausgefallenen Sachen - während der Unternehmensbenutzer etwas möchte, das wie eine Desktop-App aussieht. Und mobile Plattformen hatten eine neue Dimension.

In den letzten beiden Absätzen besteht die häufigste Idee darin, einen vorkonfigurierten Webbrowser mit Ihrem Installationsprogramm zu packen, der dann eine Verbindung zu Ihrer Web-App herstellt (lokal gehostet oder im Web). Es ist großartig, weil Sie die Aktualisierungshäufigkeit kontrollieren und den Status "einfrieren" können und genau wissen, was Sie unterstützen und testen müssen. Außerdem können Sie coole Dinge wie dedizierte Benutzererweiterungen hinzufügen. Das Verpacken eines "eingefrorenen" Chromiums mit kleinen Chrome-Erweiterungen, die Sie entwickelt haben, um die Verwendung Ihrer Web-App für verschiedene Nutzertypen zu vereinfachen, kann beispielsweise äußerst hilfreich sein. Auf der anderen Seite ... sind Sie jetzt dafür verantwortlich, wenn eine Sicherheitsverletzung auftritt, weil Sie den Veröffentlichungszyklus eingefroren haben und Ihre App von Geschwindigkeitsverbesserungen (falls vorhanden) nicht profitiert.

Wie viele andere Dinge ist es eine zweischneidige Axt.

Anmerkung: Ich habe eine starke Vorliebe gegenüber dem Web, weil es im Grunde genommen ein Haufen von halbherzigen Technologien ist (und ich bin hier höflich), bis hin zu den OSI-Schichten, auf denen wir immer wieder Schichten Mist hinzufügen, um die Probleme darunter zu verbergen, ohne sie wirklich zu lösen oder reparieren sie.

That being said, bin ich zu Gunsten der Bahn für seine Allgegenwart als Plattform. Ich denke, der Umzug Ihres Unternehmens ist (wahrscheinlich) der richtige. Das hängt natürlich von Ihrem Zielmarkt und den Plattformen ab, die Sie anstreben. Wenn Sie etwas als Service verfügbar machen möchten, ist es wahrscheinlich eine gute Wahl (auch wenn dies nicht erforderlich ist). Wenn nicht, dann gibt es vielleicht nicht so viele Gründe dafür.

Hmm, und erwarten Sie in Zukunft einige unterhaltsame Entwicklungen, da für mobile Umgebungen (Netbooks, Smartphones, PDAs, Tablets, E-Books usw.) immer mehr Varianten vorhandener Betriebssysteme zum Einsatz kommen, bei denen der Einsatz von leichtgewichtigen eingebetteten Browsern im Vordergrund steht. .. aber mit all ihrem neuen Anteil an UI-Rendering-Pannen.

In Bezug auf Plugin-basierte Technologien würde ich sagen, lenken Sie von ihnen weg. Sie verbessern die Leistung Ihrer App, begrenzen jedoch deren Marktdurchdringung. In einigen Fällen wird dies als Plus für die plattformübergreifende Unterstützung angesehen, bis eine neue Plattform plötzlich die Unterstützung verweigert. Webstandards sind aus einem bestimmten Grund hier (achten Sie darauf, dass Sie sich nicht zu sehr über alles in HTMl5 aufregen, da dies sonst in die Luft jagen kann).


EDIT: andere Dinge zu beachten ...

Rekrutierung

Es ist äußerst schwierig , kompetente Webentwickler zu finden. Man könnte meinen, es gibt eine Herde von ihnen, aber sie befinden sich in einem riesigen Pool von ziemlich inkompetenten Leuten, die der Meinung sind, es geschafft zu haben, 700 Zeilen JavaScript / ECMAScript zu schreiben, um eine gewisse Validierung in ihren Formularen zu implementieren und alles, was in Bezug auf hochqualifizierte Fähigkeiten erreicht werden kann.

Ich mache keine Witze, in letzter Zeit ist meine erste Frage für alle Webentwicklungsinterviews, wie eine Variable deklariert wird und ob es einen Unterschied zwischen der Verwendung varund der Nicht-Verwendung gibt (je nachdem, wie sie beantwortet werden). Es ist deprimierend. Ich finde es viel schwieriger, einen durchschnittlichen oder fortgeschrittenen Webentwickler zu finden, als einen durchschnittlichen oder fortgeschrittenen Desktopentwickler.

Wahrnehmung

Niemand wird Sie jemals ernsthaft in Betracht ziehen, wenn Sie sagen "Ich bin ein Webentwickler". Es ist für eine Unterklasse von Programmierern, Entwicklern, nicht wahr? Die, die du ignorierst und von weitem verspottest und die nicht mitmachen, wenn sie Kaffee holen. :)

Dies ist offensichtlich falsch, aber es kommt darauf an, dass Sie sich für eine Umgebung entwickeln, die größtenteils für Sie verwaltet wird. Browser korrigieren Ihr verkorkstes Markup, Ihre verkorksten Stile und korrigieren sogar Ihr verkorkstes Scripting für einige von ihnen und optimieren es für Sie, wenn Sie möchten. Und wenn Sie ein Webentwickler sind, werden die Leute nicht davon ausgehen, dass Sie eine Ahnung von der Programmierung auf niedrigerer Ebene haben. Sie müssen also ein kompletter Idiot sein, oder?

Und dann erkennen sie, wie verrückt komplex ECMAScript sein kann, werden sich aber weigern, ihre Meinung zu überprüfen. Weil es Web ist. Wir mögen es nicht an sich, wir mögen nur, was es uns ermöglicht.


-2, +10 ... Ich sehe, ich habe einige Kontroversen gepflegt;)
Haylem

Unterschiede zwischen den Browsern sind immer weniger ein Problem geworden. Sicher, es gibt kleinere Inkonsistenzen in der Art und Weise, wie sie mit CSS umgehen und so weiter, aber größtenteils hatte ich nie ein großes Problem mit einem modernen Browser. Es sei denn, Sie sind mit HTML5 auf dem neuesten Stand <canvas>...
Dean Harding

6
"Hinweis: Ich habe eine starke Vorliebe für das Web, im Grunde genommen ein großer Haufen von halbherzigen Technologien zu sein (und ich bin hier höflich), bis hin zu den OSI-Schichten, auf denen wir immer wieder Schichten Mist hinzufügen, um die Probleme darunter zu verbergen, ohne es wirklich zu tun sie lösen oder reparieren. " - BIST DU ICH?????
Bobby Tables

2
Ich habe mit ein paar Leuten zusammengearbeitet, die echte Webentwicklungs-Gurus sind, erstaunliche Dinge tun und es als ernstzunehmende Software-Entwicklungsplattform verwenden. Sie haben meinen tiefen Respekt. Aber das sind nur zwei in den letzten 15 Jahren. Der Rest ... nun, ich hatte einmal einen Auftritt als Perl- "Experte", nur weil mein Beispielcode strukturiert war und nicht die Spaghetti, an die der Interviewer gewöhnt war. Zu dieser Zeit passte mein echtes Perl-Fachwissen in einen Fingerhut.
Bob Murphy

2
+1 für ECMAScript ist gut, schlecht und heißt ECMAScript.
Alan Pearce

14

Als jemand, der sich mit beidem befasst hat (mehr Desktop als Web): Mein größter Kritikpunkt ist das Gefühl der "allgemeinen Unbeholfenheit" in der Webentwicklung. Selbst mit den allerbesten Tools und Frameworks sind die Abstraktionen immer noch sehr undicht und Sie haben ständig damit zu tun, dass Sie ein zustandsloses Protokoll verwenden.

Ein weiteres Ärgernis ist der Technologiemix, mit dem Web-Apps implementiert werden. Es gibt keine nette, monolithische, modulare Umgebung und Sprache, in der alles möglich ist. Selbst relativ einfache Webanwendungen erfordern, dass Sie die Dinge in einer Handvoll separater Programmier-, Skript- und Auszeichnungssprachen codieren.

Als allgemeine Antwort: JA , es ist wirklich so schlimm. Zumindest, wenn Sie aus einem traditionellen Desktop-Hintergrund stammen, in dem Sie es gewohnt sind, Dinge in einer sauberen, nahtlosen Umgebung zu codieren, und eine Technologie und Plattform verwenden, in der alles sehr linear und klar definiert ist. Der beste Weg ist, einfach nicht zu versuchen, es als dasselbe Feld zu betrachten. Wenn Sie unbewusst davon ausgehen, dass die Webentwicklung "wie die Desktop-Entwicklung" ist, wird dies immer sehr unangenehm und ärgerlich aussehen.


4
Der Grund, warum es sich "allgemein klobig" anfühlte, ist vielleicht, dass Sie Frameworks verwendeten, die versuchten, "wegzuziehen" ... was, das Web? Das Web ist staatenlos. Unabhängig davon, wie viele "Webformulare" in ASP.NET Sie zu anderen Überlegungen veranlassen möchten, vergessen Sie niemals, dass sie zustandslos sind. Je schneller ein Entwickler dies als unveränderliche Wahrheit akzeptiert, desto schneller kann er hochwertige Webanwendungen schreiben.
Jason Whitehorn

1
+1, gut gesagt. Selbst mit Frameworks wie Rails, die die Lösung sein sollen, um alles in einem einzigen Tech-Stack zu schreiben, schaffen sie es, es zu vermasseln, indem sie die empfohlenen Vorgehensweisen von RJS zu "Unobtrusive JS" ändern.
Jas

11

Das größte Umdenken zwischen Desktop und Web ist: Die Web-App ist von Natur aus statusfrei

finde diesen Teil heraus und du bist gut.


spielt der Browser eine Rolle?
JeffO

@ Jeff Cross-Browser-Inkonsistenzen sind ärgerlich, aber nicht wirklich bedeutend
Steven A. Lowe

4
Sie müssen für echte Browser (einige Inkonsistenzen), Internet Explorer (weitere Inkonsistenzen) und möglicherweise das Kind des Teufels (IE6) schreiben.
TRiG

2
@Malfist: Wenn Sie nicht aufpassen, können Sie mit diesem Ansatz (zustandslos + Sitzungen = zustandsbehaftet) einen Emu mit angeschraubtem Flugzeugtriebwerk entwerfen, als Sie ursprünglich einen Adler gewünscht hatten;)
Piskvor

1
@ Jim G: natürlich ist es. Die Unterschiede zwischen Browsern und anderen sind jedoch winzig, verglichen mit dem Übergang vom zustandsbehafteten zum zustandslosen Anwendungsdesign.
Steven A. Lowe

5

Ein Großteil der Mühsal rührt von der Arbeit her, die erforderlich ist, um alles in allen Browsern zum Laufen zu bringen. Da Sie höchstwahrscheinlich nicht am Puls der Zeit sein müssen, können Sie die von anderen geleistete Arbeit nutzen, indem Sie ein geeignetes Web-Framework auswählen, anstatt Ihr eigenes zu verwalten.

Welches verwendet wird, hängt stark davon ab, in welcher Sprachumgebung Sie sich gerade befinden. Möglicherweise möchten Sie die Frage bearbeiten, um diese Informationen bereitzustellen.


2
Browser-Kompatibilitätsprobleme sind ein großer Schmerz, aber um das auszugleichen, vergessen Sie nicht, dass er mit der Desktop-Entwicklung verglichen wird, bei der es um verschiedene Versionen von Betriebssystemen, Bibliotheken usw. geht.
Carson63000

@Carson, wenn sie Java-Desktop-Entwicklung machen, ist dieser Schmerz eigentlich recht gering. Vielleicht ist es für .NET oder Win32 API viel schlimmer.

2

Nein, Webanwendungen haben andere Nachteile als Desktopanwendungen. Jeder hat seine Stärken in meinem Kopf. Zwar gibt es Stärken wie eine einzelne Bereitstellung, doch besteht der Nachteil darin, zu wissen, welche Browser Sie unterstützen und welche Bildschirmauflösung Sie vom Kunden erwarten? Während Sie die Kontrolle über die Serverhardware haben, stellt sich die Frage, wie viel Datenverkehr Sie erwarten und wie gut sich dieser skalieren lässt. Für diejenigen, die jahrelang Web-Entwicklung betrieben haben, können dies schmerzhafte Stellen sein, wie ich mir vorstellen würde, dass Sie einige Entwicklungsaufgaben haben, die Sie als großen Schmerz empfinden, oder?

Eine Flash-App kann für mich eine Webanwendung sein oder auch nicht. So etwas wie AIR kann jetzt Flash-Inhalte auf dem Desktop ausführen, und einige Anwendungen bauen darauf auf, z. B. Twhirl, sodass es nicht sofort so schneidend und trocken ist.


2

Die Webentwicklung ist nicht unbedingt schlechter , sondern ganz anders.

Eines der Dinge, die die Webentwicklung von der Desktop-Entwicklung trennen, ist die Fülle grundlegend unterschiedlicher Technologien, die Sie beherrschen müssen, um eine anständig komplexe Anwendung zu entwickeln. Grundsätzlich müssen Sie folgende Kenntnisse haben:

  • HTML
  • Javascript
  • CSS
  • Einige serverseitige Sprache (Java / PHP / was auch immer ...)
  • Ein RDBMS (oder eine persistente Speichertechnologie)
  • ... und möglicherweise viele andere Dinge wie Flash, Silverlight usw.

Während Sie bei der Desktop-Entwicklung normalerweise mit einem viel monolithischeren Satz von Technologien arbeiten. Um beispielsweise eine Java-App zu entwickeln, müssen Sie Java kennen, und das war's auch schon. (Das ist natürlich eine gewisse Vereinfachung, aber der springende Punkt ist, dass die Webentwicklung Sie mit einer viel größeren Bandbreite von radikal unterschiedlichen Technologien konfrontiert, die zusammenarbeiten müssen, um eine funktionierende Anwendung zu bilden.)


1

Nein

Solange Sie die richtigen Tools auswählen, ist die Webentwicklung so einfach und übersichtlich wie die Desktop-Entwicklung.

Die Web-APIs (HTML, CSS, Javascript und DOM) entsprechen der Win32-API. Irgendwann läuft alles bis auf diese API-Ebene, aber Sie sind verrückt, wenn Sie ohne Bibliothek direkt darauf programmieren, um die Unordnung, Ausführlichkeit und Inkonsistenz von Ihnen weg zu abstrahieren.

Seien Sie also vorsichtig bei der Auswahl der Frameworks. Einige Probleme entstehen durch die Auswahl fehlerhafter Tools (z. B. Probleme mit der Browserkompatibilität).

Es ist möglich, eine saubere und konsistente Webentwicklungsplattform mit einer einzigen Sprache zu haben. Wenn Sie zum Beispiel möchten, dass es "immer nur Java" ist, können Sie GWT verwenden und sowohl Ihren clientseitigen Code als auch den serverseitigen Code in Java schreiben. Wenn Sie lieber nur Javascript verwenden möchten, können Sie für die Clientseite Ext JS und für die Serverseite node.js auswählen.


0

Ich habe gehört, dass es als "... der Fluch meiner Existenz" beschrieben wurde, und ich würde dem zustimmen. Mir wurde eine Stunde Zeit für die HTML-Webentwicklung eingeräumt, und ich habe sie abgelehnt. Es ist so ein Schmerz. Ich habe die meiste Zeit in HTML verbracht und vor kurzem angefangen, mit der "Flash-Plattform" zu arbeiten. Es ist eines der ausgefeiltesten Frameworks, die ich je gesehen habe und niemand weiß davon. Wenn Leute Flash aufrufen, denken sie seit 10 Jahren an Flash. Es ist gewachsen ... viel. Ich liebe es, wieder Software zu schreiben.

Es hat immer noch seine Nachteile. Bugs verweilen manchmal für immer, aber es ist besser geworden (danke Steve J.).

Übrigens gibt es einen großen Mangel für Flex-Entwickler. Ich bin von so vielen Firmen angesprochen worden, dass es krank ist. Wenn Sie Ihren CS kennen, verbringen Sie die nächsten 6 Monate mit dem Erlernen von Flex Hardcore und rufen Sie mich an. Ich werde alle Stellenangebote weiterleiten, die ich ablehnen muss.

Update: Browserübergreifende Unterstützung ist der Hauptschmerzpunkt. Was in einem Browser funktioniert, funktioniert in einem anderen nicht oder in einer früheren Version nicht.

Der Prozess sieht ungefähr so ​​aus: - Website-Design abrufen - versuchen, es in einem Zielbrowser neu zu erstellen (dies kann schwierig sein) - Client anzeigen - Design von Client-Änderungen - alle Layout-Arbeiten, die Sie ursprünglich ausgeführt haben, abschaben - Funktionieren lassen - Client genehmigt - damit es in anderen Browsern funktioniert. Dies ist der schwierigste Teil. Es gibt dunkle Fehler auf dem ganzen Weg. Dann werden Sie auf Funktionen stoßen, die von früheren Browsern nicht unterstützt werden, z. B. abgerundete Ecken. Sie werden versuchen, Ihren Code und CSS wiederzuverwenden, aber das wird schnell fragmentiert. Es kann einfach sehr schnell zu einem hohen Wartungsaufwand werden. Fügen Sie Animationen und ältere Browser hinzu.

Der Client nimmt Änderungen vor. Sie werden am Ende Ihre ganze Zeit damit verbringen, "was einfache Dinge sein sollten" und Ihr Leben hassen. Sie werden ein Guru und wissen Dinge, die Sie nicht wissen wollen. Ich weiß, es klingt dramatisch, aber ich verschönere nicht die Probleme, mit denen Sie konfrontiert werden. Frameworks werden es einfacher machen. Wenn Sie hartnäckig mit HTML arbeiten, erstellen Sie zur Vorbereitung eine Ihrer Lieblingswebsites in HTML neu. Achten Sie dabei darauf, dass Design und Funktionalität in allen unterstützten Browsern übereinstimmen. Schaffen Sie die Probleme aus dem Weg, bevor Sie eine Stelle antreten. Themen wie die besten Designtools, die besten Javascript-Frameworks, die besten Debugging-Tools, die besten IDEs usw.


Könntest du deine Antwort ändern, um zu erklären, warum du sie für den Fluch deiner Existenz hältst?
Josh Kelley

Aktualisiert meine Antwort oben

1
Drei Dollar pro Stunde? Kein Wunder, dass Sie es abgelehnt haben, ist das heutzutage sogar ein Mindestlohn? ;)
Piskvor
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.