Executando verificação de segurança...
10

Explorando o Tauri, depois de passar por Electron e Flutter! 💆🏻‍♂️

Eu já trabalhei em alguns projetos usando Electron pra criar apps de desktop.

Na maioria das vezes, usei junto com Angular e SQLite, mas teve um caso em que fui só de HTML, JS vanilla e localStorage...

Nesse contexto, acho que o projeto mais marcante em que me envolvi foi a criação de uma nova versão do antigo app desktop do GRAN, dada a grande quantidade de usuários, que eu já nem lembro quantos eram.

Na época, fiquei responsável por montar a arquitetura inicial da aplicação e apelidei o projeto carinhosamente de "app-desktop-remix", pra manter uma "conexão" semântica com a primeira versão, que era o "app-desktop".

Sempre curti essa ideia de ter apps pra Windows, Linux e MacOS com um único código. Era tão encantador que eu fazia vista grossa para uma chatices do Electron: o tamanho ENORME do build final. 😱

No caso do app do GRAN, se não me falha a memória, o executável final ficava na casa dos 200MB... meio frustrante, considerando que o build do Angular sozinho era bem mais enxuto, com uns poucos MB. 💆🏻‍♂️

Mais pra frente, dei uma brincada com Flutter Desktop e fiquei impressionado com o tamanho do build final: também só alguns MB! Juntando isso com a possibilidade de compilar pra mobile (Android e iOS), comecei a olhar pro Flutter com mais carinho... mas, no fim, nunca usei ele num projeto real de desktop. ☹️

Fiquei ali... só esperando a chance. 🕒

Recentemente, navegando por aí, vi alguém comentando sobre um tal de Tauri e fiquei curioso. Descobri que era tipo um Electron da nova geração... e segui minha vida.

De repente... pah!

Pintou a oportunidade de criar um app desktop: uma calculadora de calorias pra pessoas sedentárias! 🤣🤣

Um projetinho/brincadeira que resolvi tocar, embalado pela vibe de um hackathon de software inútil que descobri. 🤣

Como o lance era se "divertir", pensei: por que não testar algo novo? E lá fui eu mergulhar no tal do Tauri, tentando entender como esse troço funcionava enquanto colocava a ideia no ar... rsrs

E deu certo?! 🚀🚀🚀

Criei uma aplicação pra Windows usando Tauri e React, com um build final de apenas 3,1MB 🤯

E ainda com a possibilidade de rodar em Linux, MacOS, Android, iOS e etc... se vacilar, roda até em microondas!

Ainda não testei nada disso de portabilidade, então não sei o que me espera... mas tô animado com as possibilidades!

Como nem tudo são flores, alguma coisa tinha que dificultar minha vida. Nesse caso, foi o fato do "backend" precisar ser escrito em Rust (oi???) 🤨

Então agora ganhei um dilema novo pra vida (parabéns aos envolvidos!!!):

Na próxima vez que for fazer um app desktop, vai bater a dúvida: **Rust ou Dart?**💆🏻‍♂️

E eu não sou especialista em nenhum dos dois kkkk

Por hora, fiquei feliz com o resultado...

Me diz aí:

🔹 Já ouviu falar em Tauri?
🔹 Já testou a portabilidade dele??
🔹 Devo esperar dores de cabeça???

Se quiser dar uma olhada no app que fiz com Tauri:
➡️ https://fitless.nerdlex.com/

Se quiser entender que história é essa de hackathon de software inútil:
➡️ https://www.tabnews.com.br/alexolidev/criei-um-meme-saas-so-por-diversao

Flw, vlw, bj... tchau!

Carregando publicação patrocinada...
4

Uma coisa importante: O Tauri não é um concorrente direto ou substituto do Electron.

As principais soluções que se usamos hoje em dia são:

  • Nativo (as pessoas estão correndo dele no desktop, mas não no mobile, vai entender...) que dá a melhor experiência do usuário. E a "conversa" de que tem que fazer vários porque tem plataformas diferentes, não é um problema de fato porque tem soluções que abstrai todas as plataformas, mesmo que não fique muito bom, mas ainda pode ficar melhor que web. E mesmo que dê um pouco mais de trabalho. Web também para rodar em todos os navegadores, pode dar até mais.
  • Browser - o usuário acessa no navegador dele e faz o que precisa com limitações. O funcionamento correto dependerá do navegador e a versão dele. Quando o usuário acessa seu site/app web de um navegador não (bem) homologado para ela, tudo pode acontecer, até mesmo nada.
  • Webview - é parecido porque usa o renderizador do navegador padrão do sistema operacional ou outro em alguns casos. Se mudar a versão, sua aplicação pode quebrar também, e tem que "garantir" que vai rodar em todos os sistemas operacionais. Ele permite mais liberdade porque a aplicação pode ser considerada nativa, exceto a parte da UI.
  • Renderização própria - aqui você usa uma parte de um browser como parte da sua aplicação e pode considerar a aplicação como nativa em muitos casos, exceto a UI. Você não precisa se preocupar em fazer funcionar em diversos navegadores e quando atualizar a versão dele, você pode homologar para essa versão e só atualizar o browser que sustenta a UI da sua aplicação quando você estiver seguro que não vai dar problema. É pesado em todos os sentidos.

Os dois últimos é o caso do Tauri e Electron respectivamente, portanto eles são soluções bem diferentes.

Usar o Tauri é bem válido porque pode atender uma demanda do projeto e ele traz muita coisa pronta que você não precisa se preocupar quando usa uma webview de forma direta. Mas saiba das dificuldades que ele traz.

O Electron elimina algumas dessas dificuldades, mas é um trambolhão que tem que mandar com sua aplicação.

Se considerarmos que rodar direto em um navegador padrão não atende necessidades de aplicações e tem uma outra pegada, sobra a opção do nativo que se a pessoa estudar o assunto verá que atende bem sem alguns os problemas de soluções baseadas em web, e sem ter novos problemas, quando se usa a ferramenta certa do jeito certo.

Vou reforçar: para quem sabe fazer, o nativo é muito mais fácil de lidar, de instalar (nem precisa) e dar manutenção, além de ter garantias que uma atualização de versão do engine não vai quebrar sua aplicação, se comparado com o ELectron e afins.

O mesmo pode ser dito para o Tauri e afins, embora aqui pode ser que não seja tão problemático, tem soluções que colocam pelo menos no mesmo patamar de dificuldade e resultado.

A solução em browser padrão tem uma ligeira vantagem, quase irrisória e tem diversas desvantagens, quando se compara com nativo, é bem melhor que o Electron e com Tauri depende. Claro que para sites ele passa ter uma vantagem enorme. Muitas vezes a pessoa só quer um site para ver ou consultar algo simples ou interagir de forma rápida e pontual.

O grande motivo para fazer uma aplicação com Tauri, Electron e outros produtos dessas duas vertentes é que quem vai programar só sabe ou só compensa fazer com HTML/CSS e mais uma linguagem de programação, grande parte das vezes será JS e eventualmente outra para o backend da aplicação (não estou falando do servidor).

Ainda estou fazendo uma simplificação, apesar de dar informações que olha para o todo.

S2


Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente (não vendo nada, é retribuição na minha aposentadoria) (links aqui no perfil também).

4

Sobre a compatibilidade com outros sistemas, vale ressaltar que como o tauri depende do sistema de render web do OS do usuário você pode acabar tendo algumas surpresas, já que o seu aplicativo vai ser renderizado no Windows pelo blink (motor gráfico do Chrome, mas que o Edge usa tmb e por isso é usado nativamente no windows), porém no MacOS vai ser usado o webkit (do safari, navegador da Apple), já em desktops Linux é cada um por si.

Por exemplo, no meu desktop linux mesmo eu baixando diversas bibliotecas recomendadas pelos devs do tauri, ainda, sim, aplicativos feitos usando tauri praticamente não conseguem interagir corretamente com o sistema, por exemplo, se um aplicativo tenta abrir um link no navegador padrão (para autenticação, por exemplo), nada acontece, assim como o aplicativo não identifica se o sistema é tema claro ou escuro.

Já em dispositivos da Apple (que utilizam obrigatoriamente o WebKit), embora o seu aplicativo consiga interagir melhor, você pode ter problemas de layout já que o css da página da sua aplicação é interpretado diferente. (se você já tiver costume de desenvolver websites compatíveis com os principais motores, não é tão grande o problema, mais ainda sim é meio chato saber que uma certa feature css não pode ser usado porque em computadores Apple mais antigos o safari não renderiza direito).

Então esse peso menor do tauri é uma faca de dois gumes, onde você perde a confiança de que o aplicativo vai rodar bem em todas as plataformas, mas ganha um binário mais leve para ser distribuído.

1

Cara, isso faz total sentido biológico!

E é um baita balde de água fria em... rsrs

Me poupará um bom tempo em um eventual caso onde eu esteja considerando em usar o Tauri em um projeto sério! Obrigado!

Mano, sem querer abusar, vc parece ter um entendimento valioso sobre o assunto, me deixa entender um pouco melhor como vc enxerga isso:

Se fosse fazer um app hoje que precisa rodar 100% bem em Windows, Mac e Linux... ainda escolheria Tauri? Ou iria pra outro stack? Hoje descobrir o Wails tambem, tu conhece? Ve como opção melhor que o Tauri?

4

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?

2

Li tudo! E com muita atenção!

Apesar de longo rsrs, acho que você fez um grande esforço pra sintetizar uma quantidade muito maior de conhecimentos e experiências envolvidas! Há muuuito valor aqui...

(Alívio cômico: Fiquei até curioso pra saber quantas calorias meu humilde app em Tauri teria contabilizado nesse processo)

Honestamente, nessa busca pela melhor stack pra criar seu app, você já foi muuuuuuuuuuuuuuuuuuuuuuuito mais longe do que eu! Tu falou de muita coisa que eu nunca nem tinha ouvido falar e adiantou uma visão sobre coisas que eu já queria testar.

Você meio que traz mensagens do futuro pra mim... fortalecendo uma coisa que eu estou tentando mudar na minha cabeça: feito é melhor que perfeito!

Eu acho que sempre que surge uma nova opção dessas, ela nasce com muitas promessas, o que faz a gente ficar otimista, mas ao longo do caminho, diferentes desafios vão surgindo e isso vai eliminando casos de uso e fazendo a gente "perder" muito tempo...

Tipo, nesses "side projects" eu geralmente trabalho sozinho, e se eu investir muita energia pra testar todas essas coisas, há boas chances de eu perder o fôlego no meio do caminho e terminar com mais um projeto abandonado e engavetado.

Então, estou concluindo que meu bom e velho Electron+Angular pode impor algumas desvantagens, porém é a stack que tenho mais experiência e pode ser melhor investir mais tempo em aperfeiçoar minha entrega com esta stack e conseguir finalizar o projeto... do que ficar tentando encontrar uma "solução perfeita" que sugará as energias do projeto até provavelmente matá-lo.

Acredito que, pra alguém muito técnico, é uma mudança difícil na maneira de pensar (ao menos, tem sido difícil pra mim)... tipo, a gente sempre encontra ótimos motivos pra gastar um pouco mais de energia na busca por melhorar a tecnologia e geralmente conseguimos ser muito convincentes de que isso é necessário, mas em muitos casos não é a coisa mais importante do momento.

Segura aí meus likes!

3

O que não gosto do Rust é toda primeira "sincronização", digamos assim, que ele tem que fazer. É rápido após esse processo. No entanto estou acostumado com velocidade que se propaga de um React por exemplo. Ele é unico que conheço que vale a pena construir desktop usando Tauri. Electron, é justamente criticado por isso, pois o build dele é praticamente um browser instalado e 2x maior que o próprio Chrome! Usuário final pode não entender isso ou não se importar, mas para quem é Dev, cada espaço é valioso ocupado.

2

Decidi testar o Tauri faz dois dias, por causa da documentação acabei caindo no framework Leptos que é o NextJS do universo Rust, comecei um novo projeto e acho que vou postar sobre nos próximos dias, Leptos é um framework que cria SPA (igual o React) só que sem usar JS, usamos Rust para gerar código Webassembler que conversa diretamente com o navegador, ele não utiliza virtual DOM e consegue rerenderizar o InnerHTML da tag sem tocar na tag de fato.

Minha idéia é criar um app de finanças para substituir minha planilha perfeita que uso à quase 3 anos (mas que é muito manual).

1

Muito legal!!!

Eu cheguei a ver esse nome (Leptos) pela doc também, mas confesso que passei direto e não cheguei a ver nada sobre ele! 🫣

Mas pelo que vc descreveu, parece algo muito interessante! Obrigado por compartilhar!

Tu chegou a ver os comentários do @SpaceFox e do @maniero:
➡️ https://www.tabnews.com.br/SpaceFox/c9ee9a74-7b5f-449f-ba95-5d0980aee7ee
➡️ https://www.tabnews.com.br/maniero/697fa4a8-6efc-46dd-b44d-3ff9f47624a2

Se me permite perguntar:

Vc acha que o WebAssembly lhe permitirá contornar as limitações apontadas? Ou vc entende que as limitações não são relevantes pro seu projeto? Como vc enxerga essa questão?

3

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

2

Muito legal seu post! Quanto mais conteúdo sobre tauri, melhor!

Mas sobre a parte de rust, o quanto ele é necessário?? Porque no caso do electron, eu acho que o backend é c++, mas a menos que você esteja sendo muito hacker, não deve precisar usar muito. É uma falta de APIs em JS na parte do tauri??

2

Vlw mano!!!

Então, acho que no Electron uma aplicação tem 3 "camadas":

A primeira seria o "frontend", onde podemos criar aplicações usando JS e seus frameworks.

A segunda seria um "backend local" daquela aplicação, onde você programa em NodeJS e onde vc pode interagir diretamente com recursos da máquina, disponibilizados pelo "core" do Electron, que seria a terceira camada.

Eu particularmente nunca precisei ir nessa terceira camada, só trabalhei nas duas primeiras.

Fazendo um paralelo com o Tauri, baseado nessa minha primeira experiência, estou entendendo que a primeira camada é igual à do Electron, foi onde usei React pra criar meu app.

Já a segunda camada é diferente... para interagir com a máquina, vc precisa programar em Rust.

E eu precisei trabalhar nessa camada pq o contador de calorias precisava ser capaz de ouvir todos os eventos do teclado e do mouse da máquina, mesmo os que acontecem fora do app, ou seja, eu precisava conversar diretamente com a máquina.

Mas assim: essa parada foi nova pra mim, posso ter entendido errado algumas coisas! kkkk

2

Já explorei o Tauri também mas nunca cheguei a fazer nada com ele, no momento estou estudando o Wails que tem a mesma ideia mas com base em Go. Para os projetos que queremos lançar aqui na empresa, pode ser que o Wails faça mais sentido.

1

Caramba, mano...

É muito difícil acompanhar esse mundo... acabei de conhecer o Tauri e já surgiu outra opção kkkk

Vou fazer a mesma coisa aqui, vou deixar esse Wails anotado para uma eventual nova oportunidade!

Poderia me explicar por alto qual tipo de projeto combina mais com Go?

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

6

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!

-2
1

Não conhecia... mas fazendo uma rápida pesquisa aqui cheguei nos seguintes pontos:

Vantagens:

  • Simples de criar (HTML + JS)
  • Acesso direto ao sistema (sem precisar de compiladores)
  • Interface gráfica nativa (sem Electron, sem instalador)

Desvantagens:

  • Grave risco de segurança, pois um .hta pode conter scripts maliciosos e ser usado como vetor de ataque (muito usado em malwares).
  • Obsoleto e desencorajado pela Microsoft em versões modernas do Windows.
  • Não funciona em outros sistemas operacionais (somente Windows).

Casos de uso típicos (no passado):

  • Scripts administrativos com interface
  • Protótipos rápidos de aplicações
  • Ferramentas internas com visual mais amigável que scripts em batch

Parece ser algo bem em desuso, mas de repente pode ser útil pra casos específicos onde vc saiba exatamente o que está fazendo... rsrs

Uma coisa é certa: testei aqui no Windows 11 e ainda funciona... rsrs

explicacao