Eu já testei vários frameworks, quando estava no processo de escolher uma para uma aplicação que estou desenvolvendo para min e meus amigos, e assim, depende de cada um, mas se eu tivesse que fazer uma lista do que testei e das dificuldades que passei em cada uma seria algo mais ou menos assim: (detalhe, já faz um tempo que testei então alguns detalhes podem ter mudado ou eu esquecer de algum detalhe).

Nativo:

• XLib (para Linux): Dor, resumidamente, a documentação é antiga e difícil de achar, sem contar que como biblioteca para interagir diretamente com o sistema gráfico, isso significa que você não tem nenhum utilitário (quer um botão, fontes com antialliasing, implementa aí), MAS, a vantagem é justamente essa, você tem controle total sobre cada píxel que vai ser renderizado. Nem foi cogitada ser usada no app.

• Qt (Cross-plataforma): Vejo muito sendo recomendado, mas quando tentei usar achei a documentação meio confusa quanto a parte de customização, muitos aplicativos feitos com Qt tem como ponto forte a aparência seguir o sistema operacional (parecer um aplicativo do sistema), o que é um ponto negativo se você quer ter uma identidade visual própria, o Qt também tem sua própria linguagem para construção de layouts baseada em YML, confesso que não me aprofundei muito já que não achei muita informação sobre customizar elementos nativos (sei que dá para criar seus próprios do zero, mas ter que fazer isso para cada componente é trabalho e sem a certeza de usar uma linguagem como C++ ou a linguagem do Qt baseada em yml) fez eu perder o interesse.

Não nativos

nota: aqui vale tudo, desde que renderize na tela

(tem mais coisa depois da godot, é só que o da godot ficou muito grande)

• Godot (Desktop, Mobile*, web*): Esse aqui foi uma grande decepção, eu já tinha visto várias pessoas usando engines de jogos (como Unity, e Godot) para fazer aplicativos multi-plataforma, só que sempre descartei a ideia porque como o meu aplicativo era suposto rodar junto do seu PC o tempo todo eu queria que ele usasse o menor custo de processamento e memoria possível. (continua após a explicação)

Modo Imediato VS Modo Retido

Engines de jogos diferentes de frameworks multi-plataforma usam uma técnica de renderização chamada Modo Imediato (Immediate Mode) onde contrario ao (Retained Mode, sla a tradução disso) renderizam a tela a cada frame, ou seja, no modo imediato a UI é renderizada várias vezes por seguindo, já no modo retido é renderizada uma vez e fica parada esperando uma atualização para ser re-renderizada.

Isso traz várias vantagem e desvantagens para cada modo.

• Desempenho: O modo imediato vai gastar mais processamento gráfico, só que às vezes é uma quantia insignificante, especialmente se sua UI é bastante dinâmica e está sempre re-renderizando elementos visualmente (como animações, etc.), sem contar, que, por re-renderizar sempre a implementação da biblioteca gráfica, em vários casos, como o Dear ImGUI, por exemplo, onde você pode só implementar ele em qualquer sistema e ter ferramentas gráficas super rápidas e práticas.

• Padrões de layout: O modo retido, por outro lado, vai dominar no quesito de padrões de layout, já que por sua natureza já existe uma desconexão entre o visual e o lógico, por exemplo, em bibliotecas de modo imediato é comum que a função que deve ser executada quando um botão seja pressionado fique ali com o método que cria o botão visualmente, por exemplo, da Docs da própria Dear ImGui:

if (ImGui::Button("Save"))
    MySaveFunction();

A função que desenha o botão na tela já retorna se o botão está sendo pressionado na UI e chama a ação, a biblioteca pode fazer isso já que a cada quadro a interface está sendo re-desenhada, então não há problema de o usuário apertar onde costumava ter um botão, ou onde vai ter um botão.

Por outro lado, em bibliotecas de modo retido, é usado eventos, e separação do que é visual para a parte lógica do aplicativo (MVVM, MVC) para permitir que a UI seja atualizada somente quando necessário sem a perda de lógica, isso não significa que um modelo seja mais fácil que o outro, ou melhor, são abordagens diferentes para problemas diferentes.

Com isso dito, de volta para a Godot

• Godot: (Continuação). Após ser informado nos comentários de um post no Reddit eu decidi testar o modo de baixo processamento da godot que muda a forma de renderização do motor gráfico de Imediato para Retido, ou seja, o aplicativo só renderiza quando há uma atualização na tela, só que aí uma chuva de problemas começaram a aparecer, embora exista suporte de diversas linguagem para a godot, as duas mais usadas são a linguagem padrão da godot (que é bem parecida com python), e C# usando um editor especial com suporte, decidimos usar a versão C# o que limitou as opções de exportação já que na época o suporte para mobile e web estavam como algo a ser adicionado no futuro da versão 4 da engine. E no final mudamos porque as ferramentas de construção de interfaces eram simples e dependiam bastante em texturas para formas geometricas um pouco mais complexas que retângulos com bordas arredondadas (o que faz sentido, é um motor de jogos afinal), e as opções para comportamento dos elementos quando a janela era redimensionada não eram muito legais (de novo, se comportavam como você esperaria em um jogo e não em um aplicativo desktop). Nota: depois de já ter abandonado a ideia de usar a godot para fazer interface, eu tava ajudando meu irmão com um projeto de jogo dele que tava com problemas de desempenho, e o motivo: ele tinha uma grande lista de boleanos, e o godot fez cada boleano 20 bytes de tamanho.. Então é bom ter isso em mente se seu aplicativo tiver que armazenar muito estado na memória.

• Avalonia: O mais promissor, só que por algum motivo abandonado, tipo, ele exporta desktop multi-plataforma, mobile, e web, usa um esquema MVVM (Model, View, View-Model), feito em C#, parece ser super leve e rápido, tem integração direta com o Rider (da JetBrains), só que nem eu nem meu amigo conseguiamos aprender porque tutoriais e exemplos de programas feitos em avalonia mais raros de achar do que a gente imaginava, e aparentemente é porque a grande maioria dos desenvolvedores Avalonia tem conhecimento previo de fazer aplicativos Windows usando WPF, ambas bibliotecas são bem similares e por isso se você sabe uma, você se vira na outra, infelizmente o que aconteceu é que a gente não sabia nem uma nem a outra, junto a alguns bugs tentando usar o Code-With-Me da JetBrains a gente só abandonou essa biblioteca também.

• Doodle: Um framework Kotlin, multi-plataforma, baseado em componentes, e super promissor, só que ele é somente um framework e não resolveria a parte de como instalaríamos na máquina do usuário, e todas as outras soluções para instalar na máquina do usuário já tem um método preferido para renderizar, ainda, sim, um projeto promissor.

• Kotlin MultiPlatform: meu amigo sugeriu já que ele já era desenvolvedor Kotlin, e eu já tinha usado para fazer um aplicativo Android antes, o que foi prejudicial porque eu passei muita raiva tentando fazer uma customização para adicionar sombras com uma estética diferente nos elementos, pode 100% ser skill issue da minha parte, mas eu optei por pular essa opção, pelo menos até eu ter mais conhecimento no futuro.

• Tauri: Basicamente o que eu já falei na mensagem de cima, eu tenho problemas de compatibilidade por usar linux (arch especificamente, provavelmente algum pacote muito obscuro que eu não tenho instalado), e como o aplicativo era para a gente usar, não fazia sentido usar algo que não rodaria bem no meu PC.

E no final o que a gente escolheu?

Electron.

Mas não era para ser leve e de baixo processamento já que vai ficar sempre aberto?

Sim, mas de tanto a gente bater cabeça com vários frameworks e bibliotecas diferentes acabou que comprei um PC com 32 gigas de RAM e o cansaço bateu e a gente foi para a tecnologia que a gente já tinha usado antes, MAS, com alguns pontos importantes a se lembrar.

1. O Electron é pesado por conta própria, mas isso não significa que a gente poder ser preguiçoso, por mais que tenha um consumo base alto, se o seu aplicativo for bem organizado e estruturado dá para fazer esse consumo não duplicar, triplicar, quadruplicar, ..., ou seja, não tornar o que tá ruim ainda pior.

2. Dá sim para fazer o Electron ter uma aparência nativa, sem sacrificar o design do seu aplicativo, só que praticamente se dá ao trabalho, por exemplo, algo que implementei no meu aplicativo que deixa ele com uma cara nativa sem abdicar do design foi detectar a posição dos botões da janela (maximizar, minimizar, fechar) e replicar no aplicativo, para macOS e Windows é hardcoded na esquerda/direita e quais botões, no Linux um arquivo helper lê das configs do sistema para os 3 ambientes gráficos mais populares (GNOME, KDE Plasma, XFCE) e usa um fallback de usar a decoração nativa (a borda ao redor do aplicativo) do próprio sistema, fica mais feio e menos integrado, mas bem é um fallback.

   1. Um passo além é ler também cores padrões do tema da pessoa, tipo cor de destaque e cor base e integrar isso em componentes do seu aplicativo, isso faz o aplicativo parecer bem menos um navegador rodando uma página e mais um aplicativo de fato.

   2. Design para desktop VS Design para Web, vale lembrar que os conceitos de design que você usa para fazer um site como um blog, ou uma landing page são diferentes de aplicativos, mesmos os que rodam na web, como dashboards, ou aplicativos nativos do sistema, isso vem de vários fatores como qual typeface foi usada, tamanho da fonte, espaçamentos, e só de ajustar isso já deixa uma cara bem mais de aplicativo.

Conclusão:

Não conhecia o Wails, mas olhando a docs parece ser similar ao Tauri no sentido que ele também usa o renderizador nativo do sistema, talvés o build deles para linux inclua dependências extras necessarias, mas eu teria que testar.

No final das contas por mais que o electron sofra um hate (justificavel) ainda sim, dependendo do nivel tecnico, conhecimentos previos e tempo que você gostaria de gastar desenvolvendo a base do seu aplicativo, o electron ainda acaba sendo uma boa solução comparado com os problemas de outros, só que justamente por você ter conhecimento dos problemas do electron isso significa que você vai ter que ser bem mais consciente sobre o seu uso nele.

Por exemplo, eu experimentei usar Next.JS nesse meu aplicativo, era o framework frontend (que depois virou fullstack) que eu mais tinha conhecimento, mas agora estou fazendo um rewrite total para angular (indicação de um amigo meu) justamente para evitar o peso de rodar um servidor backend nextjs em cima de um aplicativo electron, sem ter necessidade, já que eu estava usando só para montar layout frontend.

Extra

Algumas coisas que é bom ter em mente se você quiser montar um aplicativo desktop usando frameworks multi plataforma como tauri, wails, ou electron.

• Menu Global: embora seja muito conhecido no macOS, é possível ter menus globais no Linux também, e vários frameworks vão fazer o trabalho por você (Electron faz e Tauri também se eu não me engano), ou seja, quando você registra um menu no seu aplicativo ao invés dele aparecer na janela do aplicativo, aparece no menu global do sistema, alguns frameworks não fazem isso, o Java Swing não faz isso para Linux se eu não me engano, nesses casos você vai ter que implementar suporte a DBus no seu aplicativo e interagir com com.canonical.AppMenu que por mais que tenha canonical no nome, é o protocolo que todo mundo usa basicamente.

• Decorações de janelas: esse eu já falei ali em cima mais é importante ressaltar, que não tem nada mais irritante do que ter um aplicativo no seu sistema cujos botões de minimizar, maximizar estão na direita quando o resto do sistema está com eles posicionados na esquerda, ou o contrário, se possível invista o trabalho necessário para exibir eles do lado certo se seu aplicativo renderizar os próprios botões ao invés de deixar o sistema renderizar.

• Acessibilidade: Se você planeja que outras pessoas usem seu aplicativo, invista o tempo necessário para torná-lo o mais acessível possível, esse pode inclusive ser um diferencial do seu aplicativo, pois muitos desenvolvedores (e empresas) não valorizam sistemas que funcionem com leitores de tela ou navegação por outros métodos de entrada (somente teclado, somente mouse, controle joystick, etc.). E o resultado é que muitas pessoas ficam excluídas e muitas empresas evitam até as contratar com medo do sistema interno deles não ser preparado para atender as necessidades, então assim, invista em tornar seu aplicativo acessível, se você tiver usando tecnologias web, muito do trabalho é feito por você, e só de usar HTML semântico e colocar as tags apropriadas já resolve muita coisa.

Se você leu esse post com mais de 13 mil caracteres, meus parabéns e o que você achou, útil, inútil, eu errei em algo ponto?

Vi sim, mas não interfere no meu caso, farei um app simples e o Tauri é perfeito para isso, para apps simples e que não vão interagir tanto com o OS, agora imagine um app simples com 3 features simples terem que passar pelo electron e resultar numa aplicação pesada... não faz sentido, então o Tauri vem pra manter os pequenos apps... pequenos kkk

Para te dar uma boa resposta, primeiro preciso descrever mais ou menos o que fazemos.

No nosso caso aqui, trabalhamos com integrações e rotinas customizadas para estender funcionalidades de ERPs.

Por exemplo, sua empresa tem um ERP da TOTVS, faz quase tudo, mas tem um processo/operação/integração que o ERP não faz e não é de interesse da TOTVS implementar no produto. É aí que a gente atua, criando uma rotina/programa para cobrir essa operação.

O que desenvolvemos não são produtos nossos, fazemos software sob medida. O código-fonte fica com o cliente, assim como a responsabilidade de mantê-lo no ar, e se ele quiser pode contar com o time interno dele para ampliar e dar manutenção no projeto.

Na maior parte dos cenários, é necessário que sejam aplicações desktop, por alguns motivos:

• Esses clientes não tem expertise para manter ambientes web, seja on-premise ou cloud;
• Esses grandes ERPs são muitas vezes desktop e colocar um processo web no meio do caminho pode dificultar para os usuários.
• Existem restrições de acesso a rede externa por conta de várias políticas.
• É necessário interagir com o hardware como balanças e impressoras.

No passado usamos muito Delphi para fazer isso, ainda usamos para alguns casos em que ele encaixa bem (muito por conta do projeto ACBr). Também usamos C# para projetos recentes.

O problema é que por mais que tenhamos projetos desktop no cenário que comentei, a maior parte dos projetos é web, e se pudermos usar tecnologias web para criar essas aplicações eu poderia otimizar o trabalho do nosso time aqui.

Já tentamos usar Electron aqui, mas o build, o tamanho dos artefatos e o consumo de memória nunca foram satisfatórios. Também tentamos Flutter, mas o time no geral não curtiu o Dart e a comunicação com as balanças no Flutter sempre foi um parto.

Para aplicações web a gente já usou PHP no passado, mas passamos a usar Node de alguns anos para cá. O Node tem atendido bem, mas dependendo do cenário o deploy não é tão simples por conta da estrutura do cliente. Foi por conta disso que comecei a estudar Go, que dentre várias vantagens ele gera um único executável, isso torna o deploy muito simples, além de podermos embutir as dependências como bibliotecas externas (dlls por exemplo), assets e etc dentro do próprio executável com embed.FS.

E se Go pode ser uma alternativa para nós para aplicações web, com o Wails pode também ser uma alternativa para o desktop, mas ainda estou estudando sobre isso.

E por que o Rust não seria uma boa opção?

Montar bons times que usam Rust custa caro!