Como aprendi com os erros do meu game para criar um editor de imagens "escalável" (Electron + React) · GabrielBorgesWeb

Oi pessoal! Este é o meu segundo post aqui e queria contar como a frustração de "bater no teto" com ferramentas e algoritmos antigos me levou a construir o OpenCreate Forge.

Se você já desenvolveu algo maior que um "Todo List", sabe do que estou falando: você começa com uma ideia simples, o código flui, mas de repente o projeto cresce e aquela solução "elegante" do início vira o seu pior pesadelo.

1. O Trauma: A lição do "ALONE"

Eu havia compartilhado minha experiência com o meu jogo, o ALONE. Lá, eu sofri muito com o sistema de eventos. Começou com uma variável int, passou por um Object (que corrompia saves) e só no "Omega" virou um Array de strings versátil.

Essa dor me ensinou uma lição valiosa: Estado é tudo.

Se você não tem uma fundação sólida para gerenciar como os dados fluem, você vai passar mais tempo consertando o passado do que criando o futuro. E foi com essa mentalidade que decidi enfrentar um dos maiores "chefões" do desenvolvimento web: um editor de imagens profissional.

2. A Evolução: Por que um novo editor?

Sempre usei ferramentas de edição de imagens, como Photoshop, Photopea, Krita e GIMP. Mas sempre senti que havia um abismo entre o "web dev" e o "creative pro". Ou a ferramenta é pesada e fechada, ou é leve mas falta poder. Eu queria algo que fosse:

Open Source de verdade: Para que qualquer dev pudesse estender.
Tecnologia de Ponta: Usar o que há de mais novo para não nascer com "dívida técnica".

Foi assim que nasceu o OpenCreate Forge.

3. O "Omega" do Forge: A Stack e o Motor

Desta vez, não quis cometer os mesmos erros. Em vez de variáveis soltas, foquei em uma arquitetura que aguenta o tranco:

Electron: Para ter acesso ao sistema de arquivos e recursos nativos, sem abrir mão da flexibilidade da web.
React & Tailwind: Estou usando as versões mais recentes para garantir que o projeto seja moderno por anos. O Tailwind, em especial, limpou muito o meu CSS.
Zustand (O sucessor das gambiarras): Para evitar o caos que tive no meu game, usei o Zustand para gerenciar camadas, ferramentas e histórico de forma atômica e performática.
ForgeEngine (O Canvas customizado): Não é só um <canvas> solto. Desenvolvi um motor que lida com transformações em tempo real, hierarquia de camadas (Raster e Texto) e renderização otimizada.

4. Desafios Atuais

O maior desafio hoje não é mais "adicionar o evento 30", mas sim manter a performance quando temos 50 camadas com filtros e transformações aplicadas. O Forge já salva e carrega arquivos nativos .ocfd (JSON-based), e tem as ferramentas essenciais, como (em ordem) o Move, Select, Transform, Crop, Brush, Pencil, Eraser e Text.

Pergunta para a comunidade:

Para quem já mexeu com Electron ou manipulação pesada de Canvas: qual foi a barreira que vocês sentiram quando a performance da web começou a gargalar? E como vocês lidaram com o "Undo/Redo" de grandes massas de dados? Pois atualmente o Canvas usa getContext("2d") e toDataURL().

Vou ler todos os comentários.
Qualquer feedback é bem-vindo.
Agradeço desde já pela leitura!

Repositório para quem quiser bisbilhotar o código: https://github.com/gabrielborgesweb/opencreate-forge

Interface do editor OpenCreate Forge mostrando a barra de ferramentas lateral, réguas de medição e uma tela em branco de um novo projeto.

Jamais imaginei que um dia veria na mesma frase "escalável" e "Electron". Todo mundo deve estar fazendo algo muito errado, porque nunca vi uma aplicação escalável dependendo de tecnologias web. Tem muita coisa aceitável.

É verdade que o canvas ajuda muito, e ajudará mais o dia que não precisar passar pelo Javascript para usar as primitivas de desenho, mas já é um ganho em tanto não ter que passar pelo DOM. Então, sim, é uma solução mais escalável, embora provavelmente uma solução nativa funcione melhor em todos os aspectos (claro que feito por quem sabe fazer isso direito , o que está rareando, está quase virando feitiçaria). Não deixa de ter seu valor. E não vejo a hora do WASM poder acessar recursos de forma direta, o que parece que não usa, e isso torna um pouco menos escaável e poderá ter uma diferença muito maior quando darem o acesso ao WASM.

Se eu precisasse por razões "políticas" fazer algo para a web eu tentaria fazer algo que pudesse funcionar no browser (provavelmente WebGPU) e fora dele de forma nativa, assim atende quem quer algo pior e quem quer o melhor.

Bons tempos quando o Windows ocupava 100MB de memória e as pessoas jogavam pedra, tomate e coisas mais mal cheirosas, hoje tem aba do browser que ocupa múltiplos GB e as pessoas acham normal.

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