Esistono limitazioni di un'applicazione web HTML5 idealistica

Off top of my head ...

• accede ad hardware proprietario che esporta il proprio I / O con mezzi diversi da un file. Sia che si tratti di attrezzature scientifiche, macchinari industriali o semplici registratori CD e una tavoletta per digitalizzatore con supporto per inclinazione.
• solo HTTP e una piccola famiglia di altri protocolli. Non puoi creare socket come desideri, trasferendo i dati binari che desideri. Ciò limita enormemente la connettività con altri sistemi e servizi.
• Nessuno sviluppatore ragionevole creerà un gioco con grafica intensiva in Javascript. La banda larga non è quasi paragonabile al throughput DVD / HDD spesso necessario. Il supporto per 3D in Canvas è di gran lunga inferiore a quello che ottieni con i motori di gioco. Nessun modo per supportare il joystick, più tasti simultanei, la natura aperta rende l'imbroglio facile. Ma soprattutto, il calo delle prestazioni non è accettabile.
• sandboxing pesante. Non otterrai materiale che si integri profondamente nel sistema operativo. Schermate, antivirus, unità virtuali, attività in background a'la barra delle applicazioni, attività amministrative ecc.
• non può essere mission-critical. A seconda della banda larga in ogni momento per eseguire il proprio software di base non è il modo preferito la maggior parte delle aziende piace correre.

Essenzialmente, tutto ciò che può essere adattato al modello server / client può rendere una buona applicazione web e si può dire che l'opposto sia vero. La tendenza a spostarsi sul Web è stata così rapida probabilmente perché, vedendo come la maggior parte dei programmi possono essere modellati in Model / Controller / View, i programmi possono dividere il modello e il controller dalla sua visualizzazione.

Ovviamente per motivi di efficienza, alcuni controller sono posizionati anche sul lato client per evitare di sovraccaricare il server con richieste e dati errati.

Sebbene il mio punto sia: quali programmi non si adattano all'architettura del modello / controllore / vista del software, poiché sono probabilmente gli stessi programmi che non sono mai stati convertiti in applicazioni web. Buoni esempi che vengono in mente sono i sistemi operativi, i programmatori di attività, il prompt dei comandi, la protezione da virus, la protezione da spyware. Ognuno dei quali probabilmente non è implementato su un sito web perché non si adatta al modello. E non è un caso che ognuno di questi programmi dipenda pesantemente dal tuo sistema. La maggior parte richiede l'accesso diretto all'hardware, mentre altri richiedono semplicemente una maggiore sicurezza per poter essere eseguiti e non possono essere considerati affidabili dai siti Web.

Naturalmente, Google sta completamente riadattando questo concetto con il suo nuovo sistema operativo. Presumibilmente, a differenza di Windows, non è semplicemente un sistema che è cresciuto per utilizzare Internet, ma piuttosto un sistema strongmente dipendente da esso. Presto potresti vedere tutti questi programmi resi disponibili online, consentendo l'accesso al tuo hardware e software, data una rigorosa autenticazione del certificato per impedire che solo qualsiasi sito sia in grado di farlo, ma piuttosto siti affidabili. Sono ansioso di vedere che cosa escogitano, poiché penso che tra 20 anni i computer non saranno più realizzati con software installabile. Piuttosto tutti i servizi saranno disponibili online.

•Any tool that needs to interact with a foreign 3rd party piece of hardware attached to your computer will have a difficult time talking to your web application.

Il software su cui sto lavorando ora ha un aspetto desktop oltre che un aspetto basato sul web proprio perché ha bisogno di raccogliere dati da periferiche di terze parti. Lo sviluppo necessario per i driver e un programma desktop client per colmare il divario tra Device e Web.

Questo non esclude le applicazioni Web, tuttavia, poiché questi tipi di applicazioni desktop possono essere sottili con la logica che risiede principalmente sul server.

Sull'altra nota si può dire con l'aspetto del cloud computing e della virtualizzazione di massa che nessuna applicazione deve necessariamente essere limitata dalle limitazioni e dai buchi di sicurezza della tecnologia web. L'esecuzione di applicazioni desktop da un ambiente virtuale su un terminale stupido (molto simile a Citrix) è diventata molto più facile da raggiungere e potrebbe essere la prossima "moda" dello sviluppo.

La linea di fondo è che ora ci sono più scelte che mai e un sacco di teste parlanti parlano della tecnologia di domani come il modo "migliore".

Let's assume the following two assumptions are true.

• Your entire userbase has broadband access everywhere
• There is an imaginary browser X that implements the entire draft specification of the HTML5 and WHATWG groups, consistently and all users use browser X.

What are the intrinsic limitations of a commercial public HTML5 web application that we need commercial public desktop applications for?

I'm interested in the limitations of plugin-less web applications that don't rely on Flash/Java/SilverLight/etc bridges for extra features nor rely on browser plugins for extra features.

Ok, allora ecco il problema: quel browser sarà per sua natura insicuro. Quindi ci stai chiedendo di fare un compromesso tra i due. Tuttavia, superando questo, e assumendo che abbiamo javascript (a cui hai fatto riferimento nel tuo post), allora la risposta che non c'è un'app che non può essere scritta usando solo HTML5 / Javascript. Tuttavia, supponiamo che un browser non interferisca con il modo.

La cosa ha un db store locale, può effettuare chiamate a qualsiasi altra piattaforma usando le richieste HTTP (che un RESTafarian ti dirà è sufficiente) e può disegnare (via Canvas) praticamente tutto ciò che vuoi. Ci sono già giochi 3D scritti usando standard aperti (OpenGL ish) e ci sono API per fare praticamente quello che vuoi.

L'unico vero inconveniente è la velocità. Ci vorrà del tempo per fare quelle chiamate API HTTP ad altri sistemi (database). Ci vorrà del tempo per elaborare FILE (richieste COM1 :) (per leggere su un dispositivo seriale su Windows per esempio), quindi quelle sono le aree problematiche che mi aspetterei. Naturalmente, presumo anche che i driver siano stati scritti per accedere come i file, che sono abbastanza sicuro non è più vero. Ma potrebbero esporre un meccanismo del genere;)

Per l'utente, non molto sarà del tutto diverso.