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 var
o 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.