Não me parece que seja pular etapas ir para C# no seu caso. pelo contrário, pare · maniero

Em resposta a [INDICAÇÃO] Por onde começar no desenvolvimento Desktop?

Não me parece que seja pular etapas ir para C# no seu caso. pelo contrário, parece o caminho natural. De fato hoje quando se fala em desktop não é tão fácil achar solução melhor pronta (as melhores são para programadores bem hard core).

Dê um passo de cada vez. Não se preocupe com passos que podem nem ser oque deseja depois de dar o próximo. Os passos virão. Ou está fazendo algo errado no seu aprendizado.

Vou indicar o que virá no link abaixo :D Mas pode começar pela documentação já linkada por outra pessoa. Por enquanto é só o que eu digo, farei uma lista curada com responsabilidade daqui alguns meses. Chitar qualquer cosia fácil, eu tenho um compromisso maior.

Por favor, não caia na tentação de alguns. Desktop tem inúmeras vantagens que muitos resolveram ignorar, e as desvantagens podem ser todas solucionadas. Então faça desktop, não faça web fazendo de conta que é desktop (vulgo Electron, se for para fazer web e fingir que é desktop tem até coisas melhores para a maioria dos cenários - Electron só é solução porque a escolha foi porca e causou problemas). Só porque algo é popular não significa que deva fazer. E nem é tão popular assim. Para confirmar isso, web é extremamente popular, se for na popularidade não deve nem olhar para desktop. Popularidade não é tudo, qualidade pode ser mais interessante. Entenda que a maioria das pessoas vão mesmo pela popularidade. Sequer resolveram estudar sobre o assunto para decidir, ouvem influenciadores e acabou.

Ao mesmo tempo tenho que dizer que fazer para desktop é ótimo, mas também vai comprar briga. É como tocar música clássica em festa de pancadão. Ok, estou exagerando também. Se achar seu caminho terá um diferencial incrível.

Observou? Faz sentido para você?

Espero ter ajudado. Em geral estou à disposição na plataforma (sem abusos :D)

Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente. Para saber quando, me segue nas suas plataformas preferidas. Quase não as uso, não terá infindas notificações (links aqui).

NicolasCoiado

1 ano atrás

Cara, você resumiu basicamente o que eu estava pensando, o Electron me pareceu tentador, mas se todo mundo está falando, significa que eu não devo entrar.

taveira

1 ano atrás

Electron é inchado, e ainda tem o Node built-in como dependência, e muito mais complexo que o tauri, apesar de obviamente oferecer mais recurso devido ao tempo de existência também.

Observe que só recentemente o electron adicionou um suporte decente para os ES Modules.

taveira

1 ano atrás

Eu recomendo o https://tauri.app que utiliza WebView por trás e por tanto, o tamanho final do instalador é bem pequeno. Não que isso importe muito, mas tem um brasileiro como cofundador. Acho que para você que veio da Web pode ser uma boa.

A questão é que aqui você vai ter que pensar mais em arquitetura de código para não virar bagunça. O tauri oferece uma API que disponibiliza funções que acessam os recursos do S.O. E é possível executar essas funções direto de um componente, por exemplo. O que para mim é um pouco grotesco, por isso que digo, o tauri não é nada opinativo sobre a arquitetura do código. Eu tentaria distanciar ao máximo essa API tauri do seu código de negócio, Clean Arch pode te guiar nisso.

Te garanto que esse framework é relativamente simples de usar, se você considerar as funções básicas de S.O que um app desktop precisa (por exemplo, enviar uma notificação nativa), a API construida pelo tauri serve bem. Porém, se você deseja desenvolver sua própria função para chamar do seu front-end, terá que utilizar Rust para tal.

O tauri está em desenvolvimento para a versão 2.0, o que vai trazer bastante mudanças.

Outro "problema" também, é o tempo de compilação da aplicação que é grande, mas isso é mais um problema de aplicações Rust com muitas depêndencias. Porém há coisas em desenvolvimento no time Rust pra diminuir esse tempo, pesquise depois.

Outro fato legal do tauri, é que ele foca em pelo menos diminuir os problemas de segurança que existe no electron (ou exista). Tem recursos de isolamento para impedir que libs acesse coisas indevidas do seu S.O.

Ah, e fique de olho também na WebGPU, essa tecnologia pode trazer avanços para aplicações desktop baseadas em tecnologias Web. Já que um dos percalços de tecnologia Web para desktop é justamente o desempenho de renderização dos elementos gráficos. Note que uma aplicação baseada em tecnologia Web, nunca passa uma sensação de uma aplicação nativa com fidelidade.

maniero

Autor

1 ano atrás

De fato é melhor que o Electron em vários pontos. Mas é pior em alguns. As tecnologias web não são lá muito estáveis. Ou seja, mudam alguma coisa no renderizador e seu aplciação pode sofrer. Por isso criuaram o Electron, não muda sem você saber, e essa á uma enorme vantagem que não pode ser desprezada. O prohlema é que ambos tentam dar solução para um problema que nem deveria existir.

Tem várias soluções que usam webview, algumas nem precisam de dependências extras, ainda que isso tenha sua desvantagem também, já que teria que cuidar de várias coisas que não vem prontas.

Porém, no final de tudo ainda é uma aplicação web se fingindo de desktop tirando várias das vantagens da plicação desktop.

WebGPU pode fazer algum sentido, mas eu não tenho informações suficientes ainda. A a questão é que WebGPU não é web, até onde eu sei. Seria uma solução universal que criram para web mas que serve para resolver um problema que desktop também tem. Um dia poderei falar mais disso, inclusive se implementaram tuo certo e vão conseguir fazer funcionar sem depender de nada web, como parece poder.

taveira

1 ano atrás

Realmente, tem esse problema. Cada S.O. vai ter sua versão de WebView, WebView2 (Windows), Webkit2gtk (linux) e WKWebView (Mac). E cada um desses com versões diferentes, no caso do WebView, vem nativo no Windows porém usuários podem ter versões diferentes.

Pra mitigar isso (não solucionar completamente) tem algumas formas. Tem que cravar a versão do WebView com o código do seu APP e recorrer aos testes de software.

Outra é trazer o WebView embutido no bundle, o que aumenta o tamanho final do entregável, tauri da essa possibilidade.

Existe outro problema também, que é cada WebView renderizando componentes de maneira diferente, mesmo problema existente nos navegadores.

Aí o trampo tá na mão do dev mesmo de tomar cuidado com esses pontos.

E sim, de fato ainda será uma aplicação web se "passando" de desktop. E realmente tem desvantagens, como a integração com o S.O será inumeras vezes mais crua do que as tecnologias C# desktop, com documentação melhor e mais tempo de existência. E outras desvantagens que me falta conhecimento pra dizer. Já usei WinForms e WPF, e a produtividade desses caras é algo q a stack web não oferece. Por isso que em um app que pouco importa a riqueza de interface, como um ERP com vários módulos, seria a minha escolha.

As vantagens que vejo da stack web é o reaproveitamento de código fonte e o conhecimento. Fora que a riqueza de interface que JavaScript + CSS oferece, acho difícil uma tecnologia desktop faça o mesmo sem que o código fique gigantesco (as vezes inviável). E por outro lado, também acho difícil algo gráfico que a stack web não consiga replicar. (Ok estou desconsiderando desempenho ruim da web e a necessidade de uma interface com tanta "firula" em apps desktop).

Um app "bem construído" com tauri é o https://www.spacedrive.com

maniero

Autor

1 ano atrás

Que ótimo que você falou da produtividade, porque quase todo mundo fala que web é muito mais produtivo, sem ninguém apresentar provas disso. Minha experiência não é essa. Eu até entendo que fazer desktop errado pode dar trabalho, e muita gente faz assim, entendo também que estão entregando tanta coisa pronta e ferramentas para ajudar com web, que fica até competitivo, mas se fizessem o mesmo com desktop seria ainda mais. Com 10% do esforço que colocam na web o desktop teria todos os problemas resolvidos. Inclusive com códigos curtos. Ah, hoje tem um monte de tecnologia que não é mais a dificuldade das GUIs originais. Rust mesmo tem várias soluções desktop com códigos enxutérrimos (deixa WF, WPF e afins no chinelo). E dá para por abstração em cima e ficar melhor ainda se quiser. Essa coisa de códigos grandes sempre tem solução simples (pode trazer algums desavatagem junto, tudo é tradeoff). Pena que quase tudo é meio experimental, não tem apoio forte para se tornar popular, mas do ponto de vista de engenharia, coisa boa não falta, falta o mercado ver isso e querer.

Só para deixar claro para outras pessoas ainda inexperientes que possam ler aqui, ninguém tá falando de websistes, é de aplicações.