Quando falamos sobre um “aplicativo de desktop”, geralmente queremos dizer um programa que é executado com uma interface gráfica nativa da plataforma ou alimentada por algum kit de ferramentas visual de plataforma cruzada. Mas um aplicativo de desktop hoje em dia tem a mesma probabilidade de ser uma página da Web glorificada em uma instância independente de um navegador.
Se isso soa como uma crítica, não é. O aplicativo Web UI Desktop possibilita fornecer UIs ricas usando toda a cultura existente dos componentes da interface do usuário criados para a Web. Ainda assim, esse poder e flexibilidade custam o suficiente – para que o esforço de desenvolver um aplicativo de desktop nativo possa valer a pena.
O que exatamente é um aplicativo de desktop nativo?
Como estamos chamando de um aplicativo de desktop “nativo”?
Principalmente, isso se resume à diferença entre um programa que usa a tecnologia da web-uma interface da web, embalada em um exemplo de um navegador da web-versus um programa que usa o próprio sistema GUI da plataforma ou uma GUI de terceiros e plataformas cruzadas que não é principalmente baseada na Web.
Aplicativos de desktop como o Código do Visual Studio ou o Slack Client são baseados na Web. Eles constroem tecnologias como Electron ou Tauri, onde o front end do seu aplicativo é construído com HTML, CSS e JavaScript. (O back -end também pode ser JavaScript, mas não é necessário.)
Aplicativos verdadeiros de desktop, como o produto Visual Studio completo, o Microsoft Word ou a Adobe Creative Suite, não use um front end ou embalagem baseado na Web. Parte disso é o peso de uma base de código herdada, criada antes dos aplicativos e elétrons da interface do web: se não estiver quebrado, não altere. Mas os aplicativos nativos também fornecem um controle muito mais refinado sobre a experiência do usuário, com o custo de exigir mais desenvolvimento.
Benefícios de aplicativos baseados na Web
A maior vantagem de um aplicativo de interface do usuário da Web sobre um aplicativo de desktop nativo é sua capacidade de aproveitar o enorme ecossistema de componentes da UI baseados na Web. Se houver algum elemento de interface do usuário que você deseja apresentar ao usuário, as chances são de uma versão da Web. Não apenas isso, mas muitas vezes será muito mais fácil de implementar do que uma versão nativa da plataforma.
Como os componentes da Web são tão universais, é muito mais fácil redirecionar um para um aplicativo de interface do usuário da Web do que usar um widget escrito para algum outro sistema de ferramentas ou sistema de janelas. Isso não inclui apenas componentes comuns como formulários e campos de entrada, mas interfaces mais complexas, como gráficos 3D interativos. Quase tudo o que pode fazer parte da interface do usuário de um aplicativo nativo pode ser entregue como um componente da Web de algum tipo.
Os aplicativos da interface do usuário da Web também oferecem portabilidade. É muito mais fácil fornecer uma versão entre plataformas de um aplicativo de interface do usuário da Web do que seu colega nativo. Quase todas as abstrações da plataforma, como lidar com a área de transferência, são tratadas pelo tempo de execução do navegador.
Desvantagens de UIs da web para aplicativos de desktop
Todas as vantagens acima das UIs da Web vêm com desvantagens. O maior único é a dependência do navegador da web – seja um empacotado com o aplicativo ou uma visualização da Web nativa na plataforma de destino.
O agrupamento de um navegador com o aplicativo é a abordagem mais comum; É o que o Electron e seus spin-offs fazem. Isso fornece aos desenvolvedores controle de granulação fina sobre qual edição do navegador é usada, quais requisitos ele suporta e como ele os suporta. Mas esse controle vem com uma desvantagem enorme no tamanho do artefato binário. Os pacotes de navegador podem atingir 100 MB ou mais para um simples aplicativo “Hello World”.
Uma maneira possível de contornar isso é apenas invocar qualquer visualização da Web nativa disponível na plataforma de destino. Isso reduz drasticamente o tamanho da entrega, mas você nem sempre sabe quais serão os recursos de linha de base da Web View.
Se você não estiver usando os recursos do navegador de borda sangrenta, normalmente poderá se safar usando a visualização da web. Mas se você fizer alguma coisa envolvendo, digamos, o WebAssembly ou outras tecnologias de navegador que desenvolvem rapidamente, é seguro assumir que uma exibição na Web da plataforma ficará atrás das edições atuais do navegador em pelo menos um ano.
Outra limitação significativa é que qualquer interação entre a interface do usuário do aplicativo e seu back -end é limitada ao que pode ser suportado pelo navegador. Na maioria das vezes, isso significa que você terá que limitar essas interações com o que pode passar por um soquete de rede local entre o navegador e o back -end. Em teoria, pode incluir um plug -in de navegador ou “extensão de componente” (via Chrome), mas a maioria das UIs da Web usará uma conexão de rede.
Uma maneira importante que isso pode se manifestar é a latência da UI. As atualizações em tempo real são transmitidas para o navegador a partir de um back-end, serão gargalas pela pilha de rede. O trabalho com maior desempenho pode ser transferido para o navegador-por exemplo, como um módulo WebAssembly-mas com o custo potencial de adicionar outro idioma ou conjunto de etapas de construção aos requisitos do projeto.
Como escolher entre um aplicativo nativo ou interface da web
Um aplicativo completamente nativo – que funciona sem a necessidade de uma interface da web – provavelmente é a sua melhor escolha quando você tiver os seguintes critérios:
- Uma interface do usuário da web não é vital. Por exemplo, uma ferramenta leve da linha de comando pode ter uma interface da Web opcional para conveniência, mas não precisa funcionar.
- O tamanho dos assuntos entregáveis. (O exemplo da ferramenta de linha de comando também se encaixa aqui.)
- Você deseja o mínimo de camadas possível entre o aplicativo e o sistema operacional ou o sistema subjacente.
- A interface do usuário precisa de latência mínima ou o código mais sensível ao desempenho não pode ser executado no navegador.
Uma interface da web faz mais sentido quando:
- O tamanho da entrega é negociável.
- A facilidade de usar componentes da Web para o front -end é essencial para o desenvolvimento contínuo do aplicativo.
- É aceitável trabalhar com o sistema subjacente através das abstrações fornecidas pelo navegador.
- O front -end não precisa ter a menor latência possível com o back -end. (Ou quando qualquer comportamento sensível ao desempenho pode ser movido para o navegador.)
A linha entre aplicativos locais e aplicativos da Web está desfoque e já faz algum tempo. A Web se tornou sua própria plataforma de aplicativos, oferecendo conveniências que os aplicativos de desktop convencionais lutam para combinar. Mas a área de trabalho e a linha de comando junto com ela não desapareceram e, por boas razões.
