suji - substituto do Electron
(github.com/ohah)É tipo um Electron feito em Zig.
O título ficou bonito, mas na prática é só um framework desktop feito com Zig.
Acho que o Electron é, na verdade, algo inevitável quando se desenvolve apps de desktop.
Especialmente quando é preciso considerar ao mesmo tempo os ambientes Mac e Windows e manter alta produtividade, acho que não existe framework tão atraente quanto o Electron.
Ele permite aproveitar todo o ecossistema JS e já foi validado pelo mercado (vscode, slack, discord etc.).
Justamente por ter tanta versatilidade e tantos pontos fortes, também é um framework com muitos casos de uso, então seus defeitos são bem conhecidos e ele recebe muitas críticas.
Eu também sou um dos usuários que tinham esse tipo de insatisfação.
Por não gostar disso, experimentei o Tauri, mas no Tauri também não gostei da limitação crônica (?) do system webview,
assim como do fato de que, ao usar Tauri, a linguagem de backend fica limitada a Rust,
com Electron fica limitada a Node,
e com Wails fica limitada a Go.
Claro, usando FFI dá para integrar outras linguagens também...
Mas, principalmente hoje em dia, quando as barreiras entre linguagens diminuíram bastante, eu não gostava da ideia de haver restrições de linguagem por causa do framework.
zig, rust, go, lua, node
podem ser escolhidas individualmente como linguagens de backend, e também é possível selecionar várias ao mesmo tempo e configurar múltiplas linguagens de backend.
Pretendo continuar adicionando mais linguagens de backend.
python e Ruby também.
Como várias linguagens podem entrar ao mesmo tempo, cada backend pode se comunicar com os outros via IPC.
Por exemplo, para chamar SQLite no Node,
normalmente é preciso instalar better-sqlite3, mas no caso do SQLite ele já está incluído como plugin embutido e o Node o utiliza fazendo chamadas diretas ao Zig.
Já é possível compilar também para mobile, mas por enquanto tudo, exceto Mac, ainda está instável.
No iOS, por política da plataforma, não é possível usar Node como linguagem de backend.
Atualmente, no Mac já está em um estado em que builds reais e produção de produto são possíveis; no Windows e no Linux ainda faltam alguns ajustes.
Também há suporte móvel planejado.
Por causa das desvantagens do system webview que enfrentei no Tauri,
no Mac não pretendo usar system webview.
A API e o modo de uso foram alinhados o máximo possível com a API do Electron,
e há documentação e especificações fáceis para IA desenvolver. Na prática, basta passar o link da documentação que ela faz até a validação E2E sozinha, então dá para ver este como um framework cuja produtividade com IA é esmagadoramente superior (?) à de outros frameworks concorrentes.
Na real, eu só fiz isso porque fiquei de saco cheio de Electron e Tauri, e
pessoalmente hoje, quando vou criar ferramentas de DX ou apps desktop, desenvolvo usando o suji.
Posso ter medido errado, mas estou mais satisfeito porque essa estrutura permite comunicação entre linguagens mais rápida do que chamadas via FFI.
Para criar apps simples e produzir algo rapidamente sem ficar preso a uma linguagem, sinto que ele é mais rápido do que Electron ou Tauri, então pessoalmente estou satisfeito.
Mas também fico curioso para saber se isso é só eu ficando satisfeito por ter feito, ou não. Queria ouvir o que outras pessoas acham dessa ideia e dessa abordagem, por isso estou postando aqui!
Ainda não há comentários.