Sviluppo web contro desktop - lo sviluppo web è peggio? [chiuso]


29

Come sviluppatore desktop di lunga data che sta cercando di realizzare la nostra prima applicazione Web su larga scala, quali sono i pro e i contro dello sviluppo web?

Lo sviluppo di un'applicazione Web è molto peggio dello sviluppo di un'app desktop? Ad esempio, è più noioso o fastidioso? Il tempo di immissione sul mercato è molto peggio? La piattaforma web è eccessivamente limitante? Se la risposta a una di queste è sì, allora perché?

(E come si confronta lo sviluppo di un'app Flash o Silverlight?)


5
Non ho votato per chiudere, ma penso che potrebbe essere più costruttivo se potesse essere riproposto in uno sviluppo web rispetto al punto di vista dello sviluppo desktop.
Josh K,

K: Ok, ho provato a riformulare la domanda senza invalidare le risposte esistenti. Grazie.
Josh Kelley,

Risposte:


26

No

È doloroso se non sai cosa stai facendo o non pianifichi correttamente, ma questo è vero con qualsiasi sviluppo. È più semplice imbottigliare l'applicazione in un'applicazione desktop, ma si perde l'accessibilità fornita dalla codifica per un'applicazione Web.

Vorrei fare la scelta tra desktop e web in base all'uso desiderato. Vedo molte applicazioni scritte basate sul Web che non dovrebbero essere perché non sanno come codificare le applicazioni desktop. Non vedo molte applicazioni desktop che dovrebbero essere basate sul web, e penso che sia qualcosa da considerare. Se hai bisogno di archiviazione centralizzata, accessibilità remota e tratti dell'interfaccia utente, assicurati .

Non posso commentare Flash o Silverlight perché non uso nessuno dei due.


5
Odio essere quel ragazzo ma ... :s/loose/lose/:)
dottor Hannibal Lecter il

@dr Annibale: risolto. A volte tocco due volte i tasti. ;)
Josh K

4
@dr Annibale: c'è una tale dissonanza cognitiva che deriva dalle parole "Odio essere quel ragazzo" proveniente da "Annibale Lecter" :)
Skilldrick,

25

Come menzionato da altri, è una questione di compromessi e di avere la giusta conoscenza.

L'unica trappola che potresti prendere in considerazione è questa: nella tua domanda menzioni che vedi che il Web ha "vantaggiosi" come multipiattaforma. Ma davvero? Pensala in questo modo: se sviluppi qualcosa per il desktop, devi definire l'elenco delle piattaforme e i loro requisiti da supportare.

Non commettere errori, è lo stesso per il web. E anche se è già tremendamente più semplice di prima, se si progetta un'app pubblica ampia, si dovrà affrontare ogni possibile versione di ogni browser Web. E se si tratta più di un'app enterprise, preparatevi e preparatevi a redigere i requisiti delle piattaforme browser supportate in modo molto preciso.

Non pensare che eviterai di avere hack specifici per la piattaforma qua e là se costruisci qualcosa di significativo.

E poi le parti divertenti. Qual è il migliore? I browser che si aggiornano in modo quasi trasparente in modo molto regolare come Chrome? O quelli che implementano aggiornamenti di sicurezza solo mensilmente e le funzionalità principali ogni età della pietra (come IE)? La risposta non è così ovvia come potresti pensare, perché alcuni di questi frequenti aggiornamenti "trasparenti" potrebbero violare il tuo codice e dovrai seguirlo e reagire prontamente. Oppure tieni d'occhio le versioni preliminari di beta e sviluppo durante lo sviluppo e il testing. Per tutti i browser che hai stupidamente detto che volevi supportare (buona fortuna).

Oh e non dimentichiamo le considerazioni sull'interfaccia utente. Devi anche affrontare la gioia di decidere se desideri un'interfaccia utente coerente ATTRAVERSO tutte le piattaforme di destinazione o un'interfaccia utente coerente CONpiattaforma di destinazione di ciascun host. Vedi tutti quei pulsanti che puoi vedere sulle pagine web? Vuoi che siano esattamente uguali ovunque o che si integrino con l'ambiente utilizzato dal tuo utente? Ovviamente questo problema non è nuovo ed esisteva per altri modelli di sviluppo, ma qui sembra essere più importante e dipende dal tipo di utenti target e da cosa si aspettano. L'utente finale pubblico tende a desiderare che tu ti integri con la sua piattaforma, ma vorrà comunque che tu "wow!" con cose fantasiose, mentre l'utente aziendale vorrà qualcosa che assomigli a un'app desktop. E le piattaforme mobili avevano una nuova dimensione in tutto questo.

Per gli ultimi 2 paragrafi, a volte un'idea comune è quella di creare un pacchetto di un browser Web preconfigurato con il programma di installazione, che quindi si connette alla tua app Web (ospitata localmente o sul Web). È fantastico perché controlli la frequenza di aggiornamento e puoi "congelare" lo stato e sai esattamente su cosa supportare e testare. Inoltre puoi aggiungere cose interessanti come estensioni utente dedicate. Ad esempio, creare un Chromium "congelato" con piccole estensioni di Chrome sviluppate per semplificare l'utilizzo della tua app Web per diversi tipi di utenti può essere estremamente piacevole. D'altra parte ... ora sei responsabile se si verifica una violazione della sicurezza perché hai bloccato il ciclo di rilascio e la tua app non beneficerà dei miglioramenti della velocità (se presenti).

Come molte altre cose, è un'ascia a doppio taglio.

Nota: ho un forte pregiudizio nei confronti del web per essere sostanzialmente una grande pila di tecnologie semi-cotte (e sono educato qui), fino ai livelli OSI, su cui continuiamo ad aggiungere strati di schifezze nascondendo i problemi sottostanti senza davvero risolvere o risolverli.

Detto questo, sono a favore del web per la sua natura onnipresente come piattaforma. Penso che la mossa della tua azienda sia (probabilmente) quella giusta. Dipende dal tuo mercato di riferimento e dalle piattaforme a cui miri, ovviamente. Se vuoi esporre qualcosa come servizio, probabilmente sei a posto (anche se non è nemmeno necessario). In caso contrario, forse non ci sono così tante ragioni per questo.

Mmm, e aspettatevi alcuni sviluppi divertenti in futuro ora che più varianti leggere dei sistemi operativi esistenti continuano a generarsi per ambienti mobili (netbook, smartphone, PDA, tablet, eBook ...), con maggiore enfasi sull'uso di browser integrati leggeri. .. ma con tutta la loro nuova quota dell'interfaccia utente che rende glitch.

Per quanto riguarda le tecnologie basate su plug-in ... direi di starne alla larga. Miglioreranno la potenza della tua app, ma limiteranno la sua penetrazione nel mercato. In alcuni casi lo vedrai come un vantaggio in termini di supporto multipiattaforma, fino a quando una nuova piattaforma rifiuta improvvisamente di supportarli. Gli standard Web sono qui per un motivo (fai attenzione a non eccitarti troppo per tutto in HTMl5 o potrebbe esplodere in faccia).


EDIT: altre cose da considerare ...

Reclutamento

È estremamente difficile trovare sviluppatori web competenti. Penseresti che ce ne sia un branco, ma sono persi in un enorme pool di, beh, abbastanza incompetenti che pensano di essere riusciti a scrivere 700 righe di JavaScript / ECMAScript per implementare una convalida nei loro moduli è il fine-tutto ed essere tutto ciò che può essere raggiunto in termini di competenze di alto livello.

Non sto scherzando, ultimamente la mia prima domanda per tutte le interviste di sviluppo web è come dichiarare una variabile, e quindi se c'è un diverso uso varo meno (a seconda di come rispondono). È deprimente. Trovo molto più difficile trovare uno sviluppatore web medio o avanzato che trovare uno sviluppatore desktop medio o avanzato.

Percezione

Nessuno ti considererà mai seriamente quando dici "Sono uno sviluppatore web". È per una sottoclasse di programmatori, sviluppatori, no? Quelli che ignori e deridi da lontano, e non ti unisci quando vanno a prendere un caffè. :)

Questo è ovviamente falso, ma dipende dal fatto che si sviluppa per un ambiente gestito principalmente per te. I browser correggono il markup incasinato, gli stili incasinati e correggeranno anche gli script incasinati per alcuni di essi e lo ottimizzeranno per te se lo desideri. E se sei uno sviluppatore web, le persone non presumono che tu abbia un indizio sulla programmazione di livello inferiore, quindi devi essere un completo idiota, giusto?

E poi si rendono conto di quanto follemente complesso possa essere ECMAScript, ma rifiuteranno di rivedere la loro opinione. Perché è web. Non ci piace intrinsecamente, ci piace solo ciò che ci consente di fare.


-2, +10 ... Vedo che ho suscitato alcune controversie;)
haylem

Le differenze tra i browser sono diventate sempre meno un problema. Certamente, ci sono piccole incongruenze nel modo in cui gestiscono i CSS e quant'altro, ma per la maggior parte, non ho mai avuto un grosso problema con un browser moderno. A meno che tu non sia al limite con HTML5 <canvas>e cose del genere ...
Dean Harding

6
"Nota: ho un forte pregiudizio nei confronti del web per essere sostanzialmente una grande pila di tecnologie semi-cotte (e sono educato qui), fino ai livelli OSI, sui quali continuiamo ad aggiungere strati di schifezze nascondendo i problemi sottostanti senza davvero risolverli o risolverli ". - SEI ME ?????
Tavoli Bobby,

2
Ho lavorato con un paio di ragazzi che sono veri guru dello sviluppo web, fanno cose straordinarie e lo usano come una seria piattaforma di sviluppo software. Hanno il mio profondo rispetto. Ma sono solo due negli ultimi 15 anni. Il resto ... beh, una volta ho avuto un concerto come "esperto" Perl solo perché il mio codice di esempio era strutturato piuttosto che gli spaghetti a cui l'intervistatore era abituato; a quel tempo, la mia genuina competenza Perl poteva inserirsi in un ditale.
Bob Murphy,

2
+1 per ECMAScript è buono, cattivo e chiamato ECMAScript.
Alan Pearce,

14

Come qualcuno che ha affrontato entrambi (più desktop che Web): di gran lunga la mia più grande lamentela è il senso di "clunkiness generale" nello sviluppo web. Anche con i migliori strumenti e framework, le astrazioni sono ancora molto permeabili e hai costantemente a che fare con un protocollo senza stato.

Un altro fastidio correlato è il mix di tecnologie utilizzate per implementare le app Web. Non esiste un ambiente e un linguaggio modesti, monolitici e modulari in cui tutto possa essere fatto. Anche le app Web relativamente semplici richiedono di codificare le cose in una manciata di linguaggi di programmazione, scripting e markup separati.

Quindi, come risposta generale: , è davvero così male. Almeno se vieni da uno sfondo desktop tradizionale in cui sei abituato a scrivere codice in un ambiente pulito e senza soluzione di continuità, utilizzando una tecnologia e una piattaforma in cui tutto è abbastanza lineare e ben definito. Il modo migliore è semplicemente di non pensarlo come lo stesso campo. Se continui inconsciamente ad aspettarti che lo sviluppo web sia "simile allo sviluppo desktop", sembrerà sempre molto odioso e fastidioso.


4
Il motivo per cui sembrava "generalmente goffo" è forse perché stavi usando dei framework che tentavano di "astrarre" via ... cosa, il web? Il web è apolide. Non importa quanti "moduli web" in ASP.NET vogliono farti pensare diversamente, non dimenticare mai che è apolide. Quanto più rapidamente uno sviluppatore lo accetta come verità immutabile, tanto più rapidamente riesce a scrivere applicazioni Web di qualità.
Jason Whitehorn,

1
+1, ben detto. Anche con framework come Rails che dovrebbero essere la soluzione per scrivere tutto in un unico stack tecnologico, riescono a rovinarlo cambiando le pratiche consigliate da RJS a "Unobtrusive JS".
Jas,

11

il più grande ripensamento che passa dal desktop al web è: l'app Web è intrinsecamente apolide

capire che parte, e tu sei bravo.


importa il browser?
JeffO,

Le incongruenze tra browser di @Jeff sono fastidiose, ma non molto significative
Steven A. Lowe

4
Devi scrivere per browser reali (alcune incoerenze), Internet Explorer (più incoerenze) e forse il figlio del diavolo (IE6).
TRiG

2
@Malfist: se non stai attento, con questo approccio (apolide + sessioni = stateful) potresti progettare un emu con un motore a reazione per aerei imbullonato, quando in origine desideravi un'aquila;)
Piskvor

1
@Jim G: certo che lo è. Ma le differenze tra i browser e altri sono minuscole rispetto al passaggio dalla progettazione di applicazioni con stato a quella senza stato.
Steven A. Lowe,

5

Gran parte della noiosità deriva dal lavoro necessario per far funzionare tutto in tutti i browser. Dal momento che molto probabilmente non è necessario essere al limite, è possibile sfruttare il lavoro svolto da altri, scegliendo un framework Web adatto invece di gestire manualmente il proprio.

Quale utilizzare, dipende fortemente dall'ambiente linguistico a cui sei attualmente abituato. Potresti voler modificare la domanda per fornire tali informazioni.


2
I problemi di compatibilità del browser sono una vera seccatura, è vero, ma per bilanciare tutto ciò, non dimenticare che si sta confrontando con lo sviluppo del desktop, dove devi affrontare diverse versioni di sistemi operativi, librerie, ecc.
Carson63000,

@Carson, se fanno lo sviluppo del desktop Java questo dolore è in realtà abbastanza minimo. Forse è molto peggio per .NET o Win32 API.

2

No, le applicazioni Web hanno compromessi diversi rispetto alle applicazioni desktop. Ognuno ha i suoi punti di forza nella mia mente. Mentre ci sono punti di forza come una singola distribuzione, c'è il compromesso di sapere quali browser supportate e quale risoluzione dello schermo vi aspettate dal cliente? Mentre hai il controllo sull'hardware del server, c'è la domanda su quanto traffico ti aspetti e quanto bene ridimensionerà? Per quelli che hanno fatto lo sviluppo web per anni, questi possono essere punti dolenti molto come immagino che tu abbia alcuni compiti di sviluppo che ritieni siano un grande dolore, no?

Un'app Flash può essere o meno un'applicazione web per me. Qualcosa come AIR può far girare alcune cose Flash sul desktop ora e alcune applicazioni sono basate su questo, ad esempio Twhirl, quindi non è immediatamente così secco.


2

Lo sviluppo web non è necessariamente peggio , è solo molto diverso.

Una delle cose che separa lo sviluppo web dallo sviluppo desktop è la pletora di tecnologie radicalmente diverse che devi padroneggiare per sviluppare un'applicazione decentemente complessa. Voglio dire, in pratica devi avere una forte conoscenza di:

  • HTML
  • Javascript
  • CSS
  • Qualche linguaggio lato server (Java / PHP / qualunque ...)
  • Un RDBMS (o una tecnologia di archivio persistente)
  • ... e forse molte altre cose come Flash, Silverlight, ecc.

Considerando che, con lo sviluppo desktop di solito stai lavorando con un set di tecnologie molto più monolitico. Ad esempio, lo sviluppo di un'app Java richiede fondamentalmente la conoscenza di Java, e il gioco è fatto. (Certo, questa è in qualche modo una semplificazione, ma il punto è che lo sviluppo web ti espone a una gamma molto più ampia di tecnologie radicalmente diverse che devono lavorare insieme per formare un'applicazione funzionante.)


1

No

Finché scegli gli strumenti giusti, lo sviluppo web è semplice e pulito come lo sviluppo desktop.

Le API web (html, CSS, Javascript e DOM) sono l'equivalente dell'API win32. Alla fine tutto si riduce a quel livello API, ma sei pazzo se programmi direttamente sopra di esso senza una libreria per astrarre il disordine, la verbosità e l'incoerenza da te.

Quindi, fai attenzione alla tua scelta di framework. Alcuni problemi vengono autoinflitti selezionando strumenti dannosi (ad esempio problemi di compatibilità del browser).

È possibile avere una piattaforma di sviluppo web pulita e coerente, con una sola lingua. Ad esempio, se si desidera che sia "tutto java tutto il tempo", è possibile utilizzare GWT e scrivere sia il codice lato client sia il codice lato server in Java. Oppure, se preferisci che sia tutto javascript, puoi scegliere qualcosa come Ext JS per il lato client e node.js per il lato server.


0

L'ho sentito descritto come "... la rovina della mia esistenza" e sarei d'accordo. Mi è stato offerto $$$ un'ora per fare lo sviluppo web HTML e l'ho rifiutato. È un gran dolore. Ho trascorso la maggior parte del tempo in HTML e recentemente ho iniziato a lavorare con la "piattaforma Flash". È uno dei framework più sofisticati che abbia mai visto e nessuno lo sa nemmeno. Quando le persone tirano su Flash pensano a Flash già 10 anni fa. È cresciuto ... molto. Adoro scrivere di nuovo il software.

Ha ancora i suoi svantaggi. Gli insetti a volte persistono per sempre ma è migliorato (grazie Steve J.).

A proposito, c'è una grande carenza per gli sviluppatori Flex. Sono stato avvicinato da così tante aziende che è malato. Se conosci il tuo CS, trascorri i prossimi 6+ mesi imparando Flex hardcore e chiamami. Trasmetterò tutte le offerte di lavoro che devo rifiutare.

Aggiornamento: il supporto del browser incrociato è il principale punto debole. Ciò che funziona in un browser non funzionerà in un altro o lo farà ma non in una versione precedente.

Il processo procede in questo modo: - ottieni la progettazione del sito - prova a ricrearlo in un browser di destinazione (questo può essere difficile) - mostra client - progettazione delle modifiche del client - raschia tutto il lavoro di layout che hai fatto originariamente - rendilo funzionale - il client approva - farlo funzionare in altri browser. Questa è la parte più difficile. Ci sono bug oscuri lungo la strada. Quindi incontrerai funzionalità che i browser precedenti non supportano come gli angoli arrotondati. Tenterai di riutilizzare il tuo codice e CSS, ma questo diventa rapidamente frammentato. Semplicemente può diventare molto rapidamente una manutenzione elevata. Aggiungi animazioni e browser più vecchi soffocano.

Il cliente effettuerà modifiche. Alla fine passerai tutto il tuo tempo a fare "ciò che dovrebbe essere semplice" e odierai la tua vita. Diventerai un guru e saprai cose che non vuoi sapere. So che sembra drammatico, ma non sto abbellendo i problemi che dovrai affrontare. I frame renderanno più semplice. Se sei persistente a lavorare in HTML, allora preparati a ricreare uno dei tuoi siti preferiti in HTML assicurandoti di abbinare il design e la funzionalità in tutti i browser che supporta. Elimina i problemi che incontri prima di iniziare un lavoro. Problemi come i migliori strumenti di progettazione, i migliori framework javascript, i migliori strumenti di debug, i migliori IDE, ecc.


Potresti modificare la tua risposta per spiegare perché la consideri la rovina della tua esistenza?
Josh Kelley,

Aggiornato la mia risposta sopra

1
Tre dollari l'ora? Non c'è da meravigliarsi che tu l'abbia rifiutato, è quel salario minimo al giorno d'oggi? ;)
Piskvor,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.