figmascope vs Plugins do Figma
Runtime de Plugin ou Export pelo Browser?

O ecossistema de plugins do Figma é enorme. Existem plugins para exportar tokens, anotar código, gerar guias de estilo, verificar acessibilidade e gerar código. Quando alguém fala "ferramenta Figma-para-código", quase sempre está se referindo a um plugin. O figmascope não é um plugin. Veja por que isso importa — e quando não importa.

O modelo de plugin

Plugins do Figma rodam dentro de um iframe em sandbox no app desktop ou web do Figma. Eles têm acesso à API de plugins do Figma — uma interface JavaScript que expõe a árvore de nós do arquivo atual, estilos, componentes e variáveis. O plugin pode ler esses dados, transformá-los e escrever os resultados de volta no arquivo ou exportar arquivos para o sistema local do usuário via diálogo de salvamento do Figma.

A API de plugins é rica. Você pode percorrer cada nó, ler estilos computados, acessar definições de componentes, consultar variáveis e até fazer requisições de rede da camada de UI do plugin. Para a maioria das tarefas de "ler dados do design e fazer algo com eles", a API de plugins é suficiente.

Plugins são distribuídos pela loja Figma Community ou como plugins privados de equipe. Usuários os instalam via interface do Figma. Atualizações vêm pelo sistema de hospedagem de plugins do Figma. O desenvolvedor que publicou o plugin pode enviar atualizações; os usuários as recebem na próxima vez que rodarem o plugin.

Plugins Figma-para-código populares: Locofy (coberto na comparação com Locofy), Tokens Studio (sincronização de design tokens), Figma to Code (Flutter/SwiftUI/Jetpack Compose open source), e dezenas de ferramentas mais especializadas.

Limitações dos plugins

Roda apenas dentro do Figma. Para rodar um plugin, você abre o Figma, abre o arquivo, abre o plugin, dispara o export. O plugin não pode ser chamado de um terminal, uma tarefa de CI, um script ou qualquer contexto fora do app do Figma. Não há CLI. Não há uma API que você possa chamar. O contexto de execução inteiro é a UI do Figma.

Execução apenas em tempo de uso. Plugins não rodam em segundo plano. Eles rodam quando um humano os abre e clica no botão. Exports agendados, pipelines automatizados e integração programática não são possíveis pelo modelo de plugin.

Guardiões da loja de plugins. Publicar um plugin público do Figma exige revisão e aprovação do Figma. Atualizações exigem nova revisão. Se o Figma mudar sua política de revisão ou decidir que um plugin conflita com seus interesses, o plugin pode ser removido ou restrito. Plugins privados de equipe contornam a loja, mas ainda rodam no sandbox do Figma e dependem da infraestrutura de plugins do Figma.

Restrições de recursos. O sandbox de plugin tem memória e tempo de execução limitados. Arquivos Figma grandes com hierarquias complexas podem atingir timeouts ou travar o plugin. A UI do plugin roda em um iframe com acesso restrito — sem acesso ao sistema de arquivos local exceto pelo diálogo de export do Figma, sem acesso arbitrário à rede a partir da thread principal.

Inconsistências entre plataformas. O app desktop do Figma e o app web têm comportamentos ligeiramente diferentes da API de plugins em alguns casos extremos. Plugins que funcionam perfeitamente em um podem apresentar problemas no outro.

Fricção de instalação para distribuição em equipe. Todo desenvolvedor que precisa rodar o plugin o instala separadamente. A consistência de versões numa equipe depende do mecanismo de atualização automática do Figma. Se você precisar fixar uma versão específica, isso não é simples.

A abordagem externa do figmascope

O figmascope não toca no sistema de plugins. Ele roda em uma aba normal do browser — qualquer browser, sem necessidade do app Figma — e chama a API REST do Figma diretamente usando um Token de Acesso Pessoal (PAT) que o usuário fornece. O PAT fica apenas em memória, nunca é enviado para nenhum servidor.

A API REST do Figma é a mesma fonte de dados que a API de plugins usa, mas acessada externamente. O figmascope busca o JSON do arquivo, processa a árvore de nós no lado do cliente (toda a computação acontece no seu browser) e produz o bundle de contexto. As chamadas à API vão diretamente do seu browser para os servidores do Figma. A própria infraestrutura do figmascope não está no caminho dos dados.

Isso tem várias implicações:

Sem instalação. Abra uma aba, cole sua URL do Figma e seu PAT, clique em exportar. Não há nada para instalar, nenhuma conta para criar, nenhum plugin para encontrar na loja Community. Qualquer pessoa com um browser pode usar — incluindo desenvolvedores que não são usuários do Figma e não têm o app instalado.

Scriptável em princípio. Como o figmascope é construído sobre a API REST, as mesmas chamadas que ele faz podem ser reproduzidas programaticamente. O código MIT está aberto para inspeção. Se você quiser construir um script que exporte um bundle pela linha de comando sem abrir um browser, o código-fonte do figmascope mostra exatamente como chamar a API e processar a resposta.

Compatível com CI/CD em princípio. Um pipeline de export headless é alcançável: chamadas à API REST do Figma, mesma lógica de processamento de IR, mesmo formato de bundle. O app de browser do figmascope não roda em CI diretamente (é uma ferramenta de browser), mas a abordagem arquitetural — API REST, processamento determinístico, saída em arquivos simples — é amigável a CI por design. Nada no modelo requer uma GUI.

Sem dependência da loja de plugins. O figmascope é hospedado em um domínio, open source no GitHub. Não depende da infraestrutura de plugins ou do processo de revisão do Figma. O Figma não pode removê-lo de uma loja. Se o domínio cair, você pode rodá-lo localmente a partir do repo — é inteiramente HTML/JS estático.

Sem necessidade do app Figma. Um desenvolvedor pode exportar contexto para um arquivo Figma que nunca abriu no app, usando apenas uma URL compartilhada do Figma e um PAT. Isso importa para fluxos em que engenheiros não usam o Figma diretamente mas precisam da spec de design.

O que os plugins fazem melhor

Sendo honesto: plugins têm vantagens reais que a abordagem de API externa não replica.

Anotação no canvas. Plugins podem escrever de volta no arquivo Figma — adicionar anotações, definir propriedades de componentes, marcar frames como prontos, publicar comentários. O figmascope é somente leitura. Se você precisa de uma ferramenta que faz trabalho no lado do design dentro do Figma, você precisa de um plugin.

Contexto de canvas ao vivo. Um plugin sabe o que está selecionado. Ele pode responder a mudanças de seleção, observar atualizações de nós e reagir a trabalho de design em andamento. O figmascope tira um snapshot. Não tem acesso ao canvas ao vivo.

Distribuição para equipe via org do Figma. Se toda a sua equipe está num plano de org do Figma, enviar um plugin privado para a equipe é simples. Todos o têm na sua instância do Figma. Para distribuição entre equipes dentro de uma org, o modelo de plugin é bem suportado.

Interação mais rica na UI do Figma. Um plugin pode renderizar UI customizada dentro de um painel, responder a interações do usuário e fornecer feedback imediato dentro do fluxo de trabalho existente do designer. A interface do figmascope é uma aba separada do browser — uma troca de contexto.

Comparação

O ângulo da privacidade de dados

Quando um plugin do Figma faz requisições de rede, seus dados de design podem sair do seu browser e ir para os servidores do fornecedor do plugin. Você está confiando na política de privacidade e infraestrutura do plugin. Para muitas equipes, isso é aceitável. Para algumas — equipes enterprise com designs cobertos por NDA, agências trabalhando com arquivos de clientes sensíveis — é uma preocupação significativa.

A abordagem externa do figmascope é diferente. Todo o processamento acontece na sua aba do browser. As chamadas à API REST vão do seu browser para os servidores do Figma (as mesmas chamadas que seu browser faz quando você usa o Figma normalmente). Os próprios servidores do figmascope não estão no caminho. Seus dados de design não vão para lugar nenhum além da API do Figma. O PAT fica em memória e é limpo quando você fecha a aba.

Esta é uma vantagem estrutural da abordagem de browser externo sobre plugins que dependem de um servidor backend do fornecedor.

Quando escolher qual

Use um plugin do Figma quando: você precisa anotar ou escrever de volta no arquivo, quer interação no canvas como parte de um fluxo de designer, sua equipe está totalmente no Figma e a distribuição via mecanismo de plugin é conveniente, ou o plugin que você precisa tem uma UI específica no Figma que a abordagem REST API não pode replicar.

Use o figmascope quando: você precisa de um bundle de contexto portátil e versionável para codegen com agentes de IA, quer sem instalação e sem dependência de loja, se preocupa com privacidade de dados e não quer dados de design enviados para um fornecedor de plugin terceiro, quer que a saída viva no seu repositório git junto com seu código, ou quer que o processo de export seja explicável e reproduzível.

Para a maioria dos fluxos de produção de codegen de UI com agentes de IA, o modelo de plugin adiciona fricção que não consegue recuperar. O plugin roda no Figma. O agente roda no seu editor. Levar a spec de design de um para o outro através de um plugin exige either copiar e colar manualmente ou um plugin que escreve em disco — e então você tem um arquivo opaco de um pipeline opaco. A saída do figmascope é inspecionável, estruturada e explicitamente projetada para esse handoff ao agente.