Existe alguma limitação de um aplicativo da web HTML5 idealista

Vamos supor que as duas suposições a seguir sejam verdadeiras.

• Toda a sua base de usuários tem acesso de banda larga em qualquer lugar
• Existe um navegador imaginário X que implementa toda a especificação de rascunho dos grupos HTML5 e WHATWG, de forma consistente e todos os usuários usam o navegador X.

Quais são as limitações intrínsecas de um aplicativo Web HTML5 público comercial para o qual precisamos de aplicativos de área de trabalho pública comercial?

Estou interessado nas limitações de aplicativos da web sem plug-ins que não dependem de pontes Flash / Java / SilverLight / etc para recursos extras nem de plug-ins de navegador para recursos extras.

Possíveis limitações que não se aplicam:

• Bases de dados? Temos WebSQL e indexedDB.
• Arquivo IO? Temos a API de arquivos HTML5, que faz leitura e gravação.
• Rapidez? Com a recente corrida do mecanismo JavaScript, o navegador não está mais lento. O C ++ nativo é apenas três vezes mais rápido que o mecanismo V8 do chrome.
• Ferramentas de desenvolvimento? A web amadureceu e há uma variedade de ferramentas disponíveis, que são numerosas demais para serem listadas.
• Fonte fechada? Sim, todo o código é de código aberto. Esta é uma faca de dois gumes e existem inúmeras opiniões sobre o uso de código-fonte fechado ou código-fonte aberto. Pessoalmente, acredito que as vantagens do código-fonte aberto superam as desvantagens.
• JavaScript / HTML5? Argumentos como "Pessoalmente, acho que HTML5 e EcmaScript são plataformas de desenvolvimento horríveis" não contam.

Limitações conhecidas:

• O código crítico em tempo real / segurança (altamente secreto) não pertence à Web nem pode. Ele precisa ser escrito em uma linguagem de baixo nível e altamente controlável, como C ou C ++.
• Qualquer ferramenta que precise interagir com um hardware externo de terceiros conectado ao seu computador terá dificuldades para conversar com seu aplicativo da web.

Há também todo um conjunto de programas que não pertencem à web. Sistemas operacionais, drivers, software de servidor, APIs de baixo nível. Estou ciente disso, mas não os classifico como aplicativos "públicos comerciais", esse é o tipo de software que pode ser pré-instalado em computadores.

Como um aparte, eu sei que as duas suposições são terrivelmente irrealistas, mas podemos alcançá-las em 10/10/20/30 anos. Estou interessado no tipo de aplicativos e nos recursos dos aplicativos que os tornam completamente incompatíveis com a web.

Motivação:

• Aplicativos do Google
• Microsoft Office365
• Lista de aplicativos da Web
• Adobe Aviary

O ponto:

Dado o conjunto de problemas em que um aplicativo de desktop é uma solução válida.

• Por que um aplicativo Web não é uma solução válida?
• Como identifico se posso ou não usar um aplicativo da Web como solução.

Tentei remover as principais dificuldades dos aplicativos da Web (conexão com a Internet e suporte ao navegador) afirmando que eles não existem.

Além disso, os aplicativos offline do HTML5 e o Modernizr estão no caminho certo para resolver esses dois problemas.

Quais são as outras dificuldades com o desenvolvimento de aplicativos da web?

Em cima da minha cabeça ...

• acessar hardware proprietário que exporte sua E / S por outros meios que não um arquivo. Seja esse equipamento científico, maquinaria industrial ou gravador de CD comum e um tablet digitalizador com suporte para inclinação.
• apenas HTTP e uma pequena família de outros protocolos. Você não pode criar soquetes como desejar, transferindo os dados binários que desejar. Isso limita bastante a conectividade com outros sistemas e serviços.
• Nenhum desenvolvedor sensato criará jogos com muitos gráficos em Javascript. A banda larga não é quase comparável às taxas de transferência de DVD / HDD frequentemente necessárias. O suporte ao 3D no Canvas é muito inferior ao que você obtém com os mecanismos de jogo. Não há como apoiar o joystick, pressionamentos de teclas simultâneos múltiplos, a natureza aberta facilita a trapaça. Mas, principalmente, a queda no desempenho não é aceitável.
• Sandbox pesado. Você não receberá coisas que se integram profundamente ao sistema operacional. Capturas de tela, antivírus, unidades virtuais, tarefas em segundo plano na bandeja do sistema, tarefas administrativas etc.
• não pode ser de missão crítica. Dependendo da banda larga o tempo todo para executar seu software básico não é a maneira preferida para a maioria das empresas.

Essencialmente, qualquer coisa que possa se encaixar no modelo de servidor / cliente pode criar um bom aplicativo da Web e, de fato, pode-se dizer o contrário também. A tendência de migrar para a Web aumentou muito rapidamente, pois, como a maioria dos programas pode ser modelada em Model / Controller / View, os programas podem dividir o modelo e o controlador da visualização.

Obviamente, por razões de eficiência, algum controlador é colocado também no lado do cliente para evitar sobrecarregar o servidor com solicitações e dados incorretos.

Embora meu argumento seja: quais programas não se encaixam na arquitetura de software model / controller / view, pois provavelmente são os mesmos programas que nunca foram convertidos em aplicativos da web. Bons exemplos que vêm à mente são sistemas operacionais, agendadores de tarefas, prompt de comando, proteção contra vírus e proteção contra spyware. Provavelmente, cada um deles não é implementado em um site porque não se encaixa no modelo. E não é por acaso que cada um desses programas depende muito do seu sistema. A maioria exige acesso direto ao hardware, enquanto outros simplesmente exigem uma segurança mais alta para poderem ser executados e não se pode confiar nos sites da Internet.

Obviamente, o Google está reajustando completamente esse conceito com seu novo sistema operacional. Supostamente, ao contrário do Windows, não é simplesmente um sistema que cresceu para usar a Internet, mas um sistema fortemente dependente dela. Em breve, você poderá ver todos esses programas disponíveis on-line, permitindo o acesso ao seu hardware e software, com uma autenticação rigorosa de certificado para impedir que qualquer site possa fazê-lo, mas sites confiáveis. Estou ansioso para ver o que eles criam, já que penso que daqui a 20 anos, os computadores não serão mais fabricados com software instalável. Todos os serviços estarão disponíveis online.

• Qualquer ferramenta que precise interagir com um hardware externo de terceiros conectado ao seu computador terá dificuldades para conversar com seu aplicativo da web.

O software em que estou trabalhando agora tem um aspecto de área de trabalho e um aspecto baseado na Web, precisamente porque precisa coletar dados de periféricos de terceiros. A necessidade de desenvolvimento de drivers e um programa de desktop cliente para preencher a lacuna entre o Dispositivo e a Web.

No entanto, isso não exclui aplicativos da Web, pois esses tipos de aplicativos de área de trabalho podem ser limitados, com a lógica residindo principalmente no servidor.

Por outro lado, pode-se dizer, com o aspecto da computação em nuvem e virtualização em massa, que nenhum aplicativo precisa necessariamente ser restringido pelas limitações e brechas de segurança da tecnologia da web. A execução de aplicativos de desktop a partir de um ambiente virtualizado em um terminal burro (como o Citrix) tornou-se muito mais fácil de alcançar e pode ser o próximo "modismo" de desenvolvimento.

O ponto principal é que agora existem mais opções do que nunca e muito mais pessoas falando sobre a tecnologia de amanhã como o "Melhor" caminho.

Vamos supor que as duas suposições a seguir sejam verdadeiras.

• Toda a sua base de usuários tem acesso de banda larga em qualquer lugar
• Existe um navegador imaginário X que implementa toda a especificação de rascunho dos grupos HTML5 e WHATWG, de forma consistente e todos os usuários usam o navegador X.

Quais são as limitações intrínsecas de um aplicativo Web HTML5 público comercial para o qual precisamos de aplicativos de área de trabalho pública comercial?

Estou interessado nas limitações de aplicativos da web sem plug-ins que não dependem de pontes Flash / Java / SilverLight / etc para recursos extras nem de plug-ins de navegador para recursos extras.

Ok, então aqui está o problema: esse navegador, por sua própria natureza, será inseguro. Então você está nos pedindo para fazer uma troca entre os dois. No entanto, superando isso e assumindo que temos javascript (que você aludiu na sua postagem), a resposta é que não há aplicativo que não possa ser escrito usando apenas HTML5 / Javascript. No entanto, assumimos um navegador que não atrapalha.

A coisa tem uma loja local de banco de dados, pode fazer chamadas para qualquer outra plataforma usando solicitações HTTP (o que um RESTafarian lhe dirá ser suficiente) e pode desenhar (via Canvas) praticamente o que quiser. Já existem jogos em 3D escritos usando padrões abertos (OpenGL ish) e existem APIs para fazer o que você quiser.

A única desvantagem real é a velocidade. Levará tempo para fazer essas chamadas da API HTTP para outros sistemas (bancos de dados). Levará algum tempo para processar solicitações de FILE (COM1 :) (para ler sobre um dispositivo serial no Windows, por exemplo), portanto essas são as áreas problemáticas que eu esperaria. Obviamente, também presumo que os drivers sejam escritos para serem acessados ​​como arquivos, o que tenho certeza de que não é mais verdade. Mas eles poderiam expor esse mecanismo;)

Para o usuário, não será muito diferente.