Este artigo foi baseado e traduzido a partir do artigo How Flutter Will Win The Desktop por Lew C. O autor forneceu autorização para que eu traduzisse o artigo para o português. O original pode ser visto no seguinte link:

Você sabia que Visual Basic 6 foi lançado há 22 anos? Eu sei, você provavelmente se sentiu bem velhinho agora. Mas ele foi lançado num tempo diferente, no tempo em que o RAD (Rapid Application Development) era a última moda.

Vinte anos depois o desenvolvimento de software e o design mudaram consideravelmente. No entanto, de certo modo, aquela empresa que nos presenteou com o Sistema Operacional (Windows) tem nos fornecido as ferramentas mais fracas para fazer aplicativos para o seu próprio Sistema Operacional. Como isso é possível?!

Para entender isso, nós precisamos fazer uma jornada pela história da criação de aplicativos para computadores Windows. É um pequeno desvio, mas valerá a pena.

Tudo Começou com o Win Forms

Quando todos (felizmente) saíram do Visual Basic 6, a próxima coisa que apareceu foi o WinForms. O WinForms foi ótimo na questão de facilitar a construção (design) da aplicação, pois bastava arrastar e soltar os componentes no formulário. No entanto, a cara da aplicação poderia ser sempre a mesma, aquele visual padrão e insosso. Claro que existiam recursos que podiam melhorar o visual da aplicação, mas era algo que precisava ser personalizado. O visual padrão era sempre o mesmo.

Os aplicativos WinForms também tinham um ‘problema’ de forte acoplamento entre a lógica de negócios e a lógica da IU (Interface do Usuário). Isso ocorreu porque a maioria das ações em um aplicativo WinForms são eventos que são tratados por alguma coisa tal como um OnClick. Daí era muito simples colocar toda a sua lógica de negócios naqueles eventos maravilhosos. Show de bola! SQN. O que ocorria era que, com o tempo, o código se tornava cada vez mais difícil de manter.

Por conseguinte, testar a aplicação se tornou um pesadelo. Era muito difícil criar testes de unidade com um código tão acoplado. Evidentemente, era possível escrever testes para interagir com os formulários, chegando a algum resultado, mas era basicamente isso.

E então veio o Windows Presentation Framework

O Windows Presentation Framework (WPF) foi lançado com muito alarde em 2006. Finalmente, aplicativos lindos e graciosos poderiam ser produzidos para o Windows. Ele usava o XAML para a IU e o C# ou o VB.NET para o código por trás do formulário e para codificar as regras de negócio. Também era possível utilizar facilmente algumas arquiteturas e padrões como o Model-View, View-Model (MVVM) e o IoC (Inversion of Control — Inversão de Controle).

Você também poderia reutilizar o seu conhecimento de WPF para criar uma excelente experiência para os usuários da web por meio do Silverlight. A Microsoft também tinha o Blend, que permitia ajustar os aspectos visuais de seu aplicativo e criar algo que pudesse ser genuinamente impressionante.

Então a Microsoft matou o Silverlight.

Não me interpretem mal, foi a coisa certa a fazer. O HTML5 estava tendo uma adoção generalizada, o outro concorrente neste mercado (Flash) era conhecido como bugado e sujeito a riscos de segurança. Além disso, as pessoas odiavam instalar plugins no navegador, e os plugins não eram totalmente compatíveis com todos os navegadores.

Mas pra que o desespero? Você não poderia mais usar seus conhecimentos de WPF para aplicações web, mas poderia utilizá-los para criar apps mobile para o Windows Phone. Ual! Ainda bem, deram uma dentro! Só que em 2017, depois de muitos anos de expectativas perdidas, o Windows Phone foi finalmente enterrado.

Então, agora, você não poderia mais usar seus conhecimentos de XAML em aplicativos web, porque o Silverlight ‘morreu’. Você também não poderia usá-los em aplicativos para o celular porque o Windows Phone já era. Sobrou o que? Você adivinhou! O venerável Desktop. Agora pare e pense um pouco: se você fizesse um aplicativo hoje voltado apenas para ambientes desktop, qual seria sua inserção no mercado? Provavelmente muito ruim —imagine se você pudesse usar o Instagram apenas na frente de um computador?!

Em 2016, a Microsoft comprou a Xamarin. Um dos produtos da Xamarin era o Xamarin Forms, que permite o desenvolvimento de apps para iOS, Android e Windows. O Xamarin também utiliza o XAML para o design e o C# para as regras de negócio. Isso é uma ótima notícia, certo? Provavelmente você pensou: “agora vou simplesmente migrar do UWP para o Xamarin Forms e tá tudo certo, vou aproveitar todo o meu conhecimento”.

Sinto muito, mas não é bem assim. Existem diferenças de sintaxe abundantes entre WPF, UWP e Xamarin Forms. Se você quisesse alinhar seus componentes de cima para baixo, em uma coluna, o que você usaria? No Xamarin Forms, você usariaStackLayout, enquanto no UWP você usaria StackPanel. Essas inconsistências sintáticas tendiam a aparecer com frequência e se tornaram frustrantes (uma lista incompleta de todas essas diferenças está aqui) e, honestamente, por que um StackLayout é chamado de algo diferente de StackPanel quando ambos servem para a mesma coisa? Francamente, você conhece alguém que faz aplicações para Desktop e usa Xamarin Forms?

Para deixar claro, quando menciono aplicativos de desktop, não me refiro necessariamente aos aplicativos que saem da Microsoft Store e são aplicativos genuínos da Plataforma Universal do Windows (Universal Windows Platform — UWP). Vamos ser sinceros, poucos dos aplicativos que usamos são feitos com essa tecnologia. o aplicativo desktop a que me refiro aqui é aquele que normalmente vem com um instalador e executa como uma janela dentro do Windows.

Se eu fosse desenvolver um aplicativo para desktop hoje, não usaria Win Forms, Windows Presentation Framework ou Universal Windows. Provavelmente também não usaria Xamarin Forms, apesar de oferecer suporte ao Windows 10 para realizar a implantação (deploy). Então, o que resta?

Bem, existem outras soluções que permitem escrever aplicativos em JavaScript e tecnologias da web, como Electron. Então, eu usaria o Electron?

Usando Electron para sua aplicação desktop

O parágrafo de abertura do site da Electron é: “Se você pode construir um website, você pode construir um aplicativo desktop”. E é tecnicamente verdade — você pode utilizar seus conhecimentos de tecnologias web para desenvolver aplicações desktop. Mas só porque você pode, isso significa que você deve?

Eu acho que a ideia é: se você sabe como fazer um frontend web usando JavaScript ou TypeScript, você pode aplicar isso ao Electron para construir uma aplicação desktop. O Electron é usado como base para softwares muito populares, como Visual Studio Code ou Microsoft Teams. As pessoas têm uma variedade de experiências com o VS Code, ou mesmo com o Microsoft Teams, e na maioria das vezes é uma excelente experiência.

O Electron funciona e impulsiona muitas experiências excelentes hoje. No entanto, uma das principais áreas em que nos preocupamos como desenvolvedores é o desempenho. O JavaScript é compilado Just In Time (JIT), o que significa que o código é compilado em código de máquina pelo interpretador JavaScript. Não me leve a mal, esses intérpretes são muito rápidos hoje em dia, mas outras linguagens como C++ ou Dart compilam Ahead Of Time (AOT). Isso significa que em tempo de execução, nenhum tempo é gasto compilando seu código para o código de máquina, ele apenas é executado.

Como você poderia esperar, o código que é compilado com antecedência é executado mais rápido no processador em tempo de execução, pois não precisa ser compilado antes de ser executado.

Criando aplicações desktop em HTML

O HTML foi originalmente projetado para fazer páginas da web. Então, com o passar do tempo, vários frameworks JavaScript adicionaram recursos de vinculação de dados (data binding) ao HTML e temos aí frameworks como Angular e React. Embora esses frameworks possam levar a uma experiência excelente e responsiva para a web, acredito que não sejam a melhor opção para aplicações desktop.

Usar elementos <div> para desenhar uma tela faz sentido em uma página web, mas a lógica começa a falhar quando desenhamos telas para o desktop. Os elementos em si não têm estilo, daí você precisa usar as folhas de estilo (CSS) para que sua aplicação tenha a aparência desejada. Versões maduras do CSS permitem que você utilize flex box e flex elements para ajudar nesse processo, mas isso pode se tornar rapidamente complicado.

Além disso, para fazer uma aplicação funcional e com boa aparência, você acaba entre HTML para o layout geral, JavaScript para as regras de negócios e CSS para o visual (look and feel). Portanto, você precisa usar a trinca HTML + JS + CSS para construir qualquer coisa que preste.

A galera que usa o Electron se enquadra em dois campos: serão muito bons na trinca HTML + JS (ou TypeScript) + CSS. Ou aprenderão do zero essas tecnologias para projetar e construir aplicativos. No segundo caso, deveria alguém aprender tecnologias web (HTML + JS + CSS) para construir aplicações desktop no Electron? Eu diria que não. Não me leve a mal, não é ruim aprender mais do que você absolutamente precisa. Ocorre que talvez não faça muito sentido você aprender tecnologias para a construção de páginas web quando sua intenção é construir aplicações desktop.

Como já dissemos, o que você pode construir na UWP, no WPF ou talvez até no Electron será “de boa”. Mas você está querendo o “de boa” ou procura algo mais? O ideal seria você ter como objetivo: “a experiência mais incrível e bonita que meu usuário já teve ao usar uma aplicação”. Não precisa começar dessa forma, mas você deve ser capaz de crescer até chegar lá.

E então há todo o resto

Ao longo dos anos, muitas linguagens surgiram e caíram na batalha pelo desktop. Java e QT vêm à mente, mas nenhum realmente garantiu uma participação de mercado dominante — ninguém realmente ‘usa como padrão’ um ou outro quando quer fazer uma aplicação desktop.

Claro, o título deste artigo é sobre como o Flutter vai “ganhar o desktop” — por que no futuro o Flutter (na minha opinião) se tornará o padrão de fato para aplicativos escritos para desktop Windows, macOS e Linux. Mas como isso vai acontecer? Vejamos.

O Delphi

Antes de entrarmos no mérito do Flutter, vou pedir licença ao autor do artigo original para falar sobre o Delphi. O autor pode não ter lembrado do Delphi talvez porque ele se concentrou mais no universo Microsoft ou porque nunca o tenha utilizado, mas ele é uma ferramenta muito importante para nós desenvolvedores brasileiros.

Na época em que o Visual Basic estava em alta existia uma batalha entre ele e o Delphi, batalha essa vencida pelo Delphi, visto que o mesmo se encontra firme e forte atualmente e o VB está morto e enterrado. Posso afirmar que a maioria das aplicações desktop feitas no Brasil e ainda em uso foram feitas com o Delphi.

O Delphi sempre tentou acompanhar o Windows e fez esse papel muito bem com o passar dos anos, talvez até melhor que a própria Microsoft durante muito e muito tempo. O Windows teve o seu papel ‘ameaçado’ pelo Linux ali no começo dos anos 2000, onde parecia que o Linux finalmente tomaria o lugar do Windows como um ambiente amigável e gratuito para o usuário final, o que nunca aconteceu de fato, por diversas razões que não cabe aqui mencionar.

O que ocorreu com o fabricante do Delphi nessa época? (eu teria que pesquisar para saber o nome da empresa na época, pois o Delphi mudou de mãos algumas vezes: Borland, Inprise, CodeGear, Embarcadero). Bem, eles fizeram o Kylix (o Delphi para o Linux). Parecia ser o sonho de todo desenvolvedor: meu sistema vai rodar no Windows e no Linux! Mas, o sistema feito no Windows não rodava no Linux. Era outro núcleo, outros componentes. Muito empenho. Não vingou.

O tempo passou, as coisas foram evoluindo e o Delphi também evoluiu ao ponto de lançar um framework que promete rodar a mesma aplicação no Windows, MAC, iOS e Android — o Firemonkey. Novamente as aplicações feitas para o Windows (VCL) não podem ser aproveitadas aqui. É preciso construir uma nova aplicação em Firemonkey. É preciso aprender esse novo framework. As coisas são diferentes aqui. E muitas vezes os problemas que surgem entre as plataformas tornam o desenvolvimento da app um sofrimento.

Recentemente vemos que o Delphi, embora tenha evoluído bastante, não consegue se manter tão ativo e não consegue despertar o interesse do mundo acadêmico e dos jovens que chegam no mercado. Embora ele tenha uma versão Community (que levou anos para ser finalmente disponibilizada), o marketing por trás dessa versão e os valores por trás das versões pagas não ajudam em nada na fidelização de novos usuários.

Existem relatos de desenvolvedores no Brasil que receberam ligações da Embarcadero informando que estiveram analisando os logs das máquinas do desenvolvedores e que eles são obrigados a comprarem licenças caríssimas ou então que deverão responder judicialmente por estarem utilizando um software pirata. Claro que a pirataria não é algo bom (é crime no Brasil), mas a forma como a Embarcadero vem atuando nesse sentido é assustadora (em todos os sentidos), assusta inclusive os entusiastas que poderiam querer utilizar o Delphi para fazer suas primeiras aplicações.

O Delphi poderia ter ganho o mercado desktop mundial e poderia até mesmo ter partido para cima dos demais (mobile e web) de forma inteligente para ganhar, mas eles acabaram se perdendo no caminho com decisões esquisitas que acabaram afastando muitos desenvolvedores, muitos deles dos mais fiéis à ferramenta.

E o Lazarus, o irmão pobre do Delphi? Vale a pena falar sobre ele? Se fosse apenas uma questão de ganhar o desktop e a briga estivesse entre o Delphi e o Lazarus, sim, poderíamos trazê-lo para a discussão. Mas o buraco é mais embaixo e o Lazarus não é a bala de prata.

O Flutter

Design sensato

O Flutter sabe como você deve fazer as coisas nos bastidores, como fazer solicitações de rede etc, mas também sabe muito como você deve fazer o layout de seu aplicativo. Você desenha o seu aplicativo usando linhas e colunas e define o quanto essas linhas e colunas devem se estender no layout geral. O conjunto de ferramentas de design do Flutter é um tópico vasto e está além do escopo deste artigo. No entanto, se tivermos de comparar o Flutter com o Xamarin Forms e o WPF XAML, tenho que dizer que o Flutter é muito superior.

Tudo parece ficar onde você deseja. Se não ficar, a princípio, é possível configurar para chegar exatamente onde você quer. Diferente do Xamarin Forms, o Flutter deixa eu fazer o layout da minha aplicação da forma que eu quero. Isso ocorre porque o Flutter usa seu próprio mecanismo de renderização, ao contrário do Xamarin Forms ou do Electron que dependem dos controles do sistema nativo ou de como o navegador renderiza esses controles. O Flutter é capaz de renderizar cada pixel em seu aplicativo da maneira exata que você deseja, a uma velocidade igual ou quase igual a de um aplicativo nativo.

Tooling

Você provavelmente já ouviu as palavras ‘Hot Reload’ e ‘Flutter’ na mesma frase, se você já começou a estudar e usar o Flutter. Isso ocorre porque a IU é recarregada ativamente. Se você alterar o texto de um botão e clicar no botão salvar da IDE, o texto no botão será atualizado automaticamente no dispositivo que está apresentando a aplicação.

Na minha opinião, o verdadeiro poder dessa funcionalidade é que tudo se beneficia do hot reload. Se você estiver trabalhando em um serviço para fornecer uma função, basta salvar o arquivo Dart para atualizar o código dessa função específica. Na próxima vez que o caminho do código for executado, ele executará o novo caminho que você acabou de escrever, o que significa que você gasta consideravelmente menos tempo reconstruindo seu aplicativo quando algo muda. O XAML no WPF ou no Xamarin Forms também tem hot reload, mas ele é estritamente limitado à IU e, pelo menos na minha opinião, o hot reload do Flutter funciona de forma mais confiável.

Suporta macOS, Linux e Windows como destinos de compilação

Devido à forma como o Flutter funciona, você pode direcionar qualquer plataforma de desktop de sua preferência e desenvolver para ela. O suporte para macOS e Linux já está em alfa e, com a parceria da Canonical com o Google, sinto que isso se desenvolverá rapidamente em breve.

O Windows está listado como ‘em desenvolvimento’, mas na minha experiência pessoal, se você mudar para o canal master do Flutter, poderá facilmente criar um aplicativo Flutter tendo o Windows como target e tudo funciona muito bem, até mesmo o Hot Reload . É uma base incrivelmente forte para construir.

Invocação eficiente de plataforma cruzada

No que diz respeito a isso, especialmente ao escrever aplicativos que são multiplataforma, as implementações de várias funções por plataforma são importantes. Isso era algo difícil em plataformas como o Xamarin Forms, pois você tinha que expressar o que queria por meio de uma “biblioteca de vinculação” C# para a plataforma de destino. Nunca achei essa uma experiência intuitiva.

Em vez disso, o Flutter permite que você escreva as implementações específicas da plataforma na linguagem nativa de cada plataforma: swift no macOS, C++ no Linux e no Windows (C#/. NET é aparentemente possível, e está chegando, de acordo com isso). Isso significa que você se beneficia de todos os exemplos de código que já existem para essas plataformas e reduz a barreira para escrever seus próprios plugins.

Aplicativos bonitos são fáceis de fazer

Quando você cria um aplicativo WPF, UWP, Xamarin Forms ou Electron, o estilo é inteiramente seu, ou qualquer pacote de estilo que você traga para dar ao seu aplicativo uma certa aparência. Por padrão, é bastante simples.

A maioria dos aplicativos no Flutter usa o widget MaterialAppno nível superior, o que significa que os aplicativos se beneficiam imediatamente do estilo do Material. Mesmo que você despreze o design do Material, ainda tem uma aparência melhor do que um HTML completamente sem estilo ou um aplicativo Xamarin Forms (que na verdade é apenas texto preto em um fundo branco). Mesmo pequenas coisas, como colocar o texto em um círculo com um fundo gradiente, coisas que seriam quase impossíveis de expressar em XAML, são muito mais fáceis no Dart.

Unificação em design, lógica de negócios e estilo

Com o Flutter, você sempre estará trabalhando com a lingaugem Dart, seja projetando a aparência da aplicação, seja trabalhando na lógica de negócios. Você não fica alternando entre XAML, HTML, CSS e C# ou JavaScript, etc, não, há apenas uma linguagem. Isso significa que quando você aprende um truque legal no Dart na IU ou na camada de serviço, também pode aplicar isso a outras facetas do aplicativo. Anteriormente, suas habilidades com CSS, HTML e JavaScript (ou C# e XAML) cresceriam independentemente um do outro, às vezes de forma totalmente desproporcional. Agora sua habilidade com o Dart cresce como uma só. O benefício disso é significativo.

O Flutter vai ganhar o Desktop porque hoje, em uma versão alpha/dev muito inicial, ele demonstra um nível surpreendente de competência, mesmo quando comparado a soluções que estão neste espaço há muito tempo. Você pode imaginar como será quando o suporte a Windows, macOS e Linux estiverem no canal ‘stable’?

Eu, pelo menos, não posso esperar.

Projeto T2TI ERP 3.0

A T2Ti está desenvolvendo um ERP com 48 módulos usando o Flutter para construir o frontend e cinco linguagens para construir o backend: C#, Delphi, Java, Node e PHP.

O projeto foi dividido em duas fases: Projeto T2Ti ERP Fenix e Projeto T2Ti ERP Pegasus.

T2Ti ERP Fenix

O T2Ti ERP Fenix é composto de 24 módulos, que podem ser vistos na imagem abaixo.

Nessa primeira fase o nosso foco principal foram os dispositivos móveis. Você pode ver como a aplicação cliente se comporta num celular e num navegador observando os seguintes vídeos:

T2Ti ERP Pegasus

O T2Ti ERP Pegasus tem seu início em Novembro/2020. Também serão construídos 24 módulos para o Pegasus, que podem ser vistos na imagem abaixo:

O nosso foco no Pegasus será a experiência do usuário em telas maiores, então voltaremos nossa atenção para o Desktop. Por conta disso, uns dos primeiros módulos que serão construídos para o Pegasus serão o PAF-ECF e o MFE CE.

Além disso, nós mostraremos como atualizar os módulos anteriores feitos no Fenix para que os mesmos fiquem responsivos de tal maneira que a experiência do usuário sempre seja fantástica, esteja ele utilizando a aplicação num celular, num tablet, num navegador ou num computador deskop com um monitor grande.

Se você quer saber porque centenas de colegas estão migrando suas aplicações para o Flutter e como você também pode entrar nessa onda, acesse o link abaixo e fique por dentro do Projeto T2Ti ERP 3.0: