8 pontos por GN⁺ 2025-06-19 | 1 comentários | Compartilhar no WhatsApp
  • Scrappy é uma ferramenta caseira de criação de software que ajuda até pessoas sem formação técnica a criar facilmente pequenos apps por conta própria
  • Diferente de grandes apps comerciais ou corporativos, ele permite resolver livremente problemas pequenos, pessoais e criativos
  • Oferece UI baseada em canvas, edição simples de código, colaboração em tempo real e compartilhamento, permitindo uso até por quem não programa
  • Todos os apps (Scrapps) são, por padrão, ambientes multiplayer, e podem ser usados e compartilhados imediatamente sem criar conta
  • Ao contrário de geração de código por IA ou de ferramentas existentes, o Scrappy enfatiza manipulação direta e propriedade pelo usuário

Introdução e contexto

  • A maior parte do software é voltada à venda para o mercado de massa ou a grandes apps personalizados
  • Porém, apps pequenos e personalizados que atendem necessidades reais de cada indivíduo são muito raros
  • O Scrappy é um protótipo de pesquisa que ajuda qualquer pessoa a criar diretamente apps simples e criativos para amigos e família
  • O objetivo do Scrappy é apresentar de forma concreta uma visão em que mais pessoas possam criar software criativo e personalizado, mesmo sem especialização em programação

O que é o Scrappy

  • Apps criados no Scrappy são chamados de Scrapps
  • Exemplos representativos:
    • App de treino de aritmética para crianças do ensino fundamental: com ajuste de dificuldade
    • Contador de participantes para eventos locais: controla entradas e saídas por várias portas
    • Relógio calculador de custo de reuniões: calcula o custo da reunião em tempo real
    • Gerenciamento semanal de tarefas domésticas: permite gestão flexível da agenda por membro da casa

A experiência de criar apps no Scrappy

  • O Scrappy posiciona objetos como botões e campos de texto em um canvas infinito semelhante ao Figma, Miro e Google Slides
  • No painel Inspector, é possível modificar propriedades diretamente, e também conectar código JavaScript a elementos como botões
  • A criação do app é concluída repetindo passo a passo ações como arrastar e soltar, alterar propriedades e inserir código

Principais características:

  • Composição de comportamento básico: coloque campos e botões e conecte ações imediatas
  • Fórmulas reativas: implemente mudanças de propriedades em tempo real que respondem a condições específicas
  • Sincronização multiplayer: o estado é sempre salvo e sincronizado em tempo real
  • Edição ao vivo: tudo pode ser modificado em tempo real, sem separação entre executar e editar
  • Compartilhamento seletivo: partes específicas do app podem ser compartilhadas e vinculadas separadamente
  • Manipulação visível de dados: é possível depurar e editar vendo os dados como em uma planilha

Por que o Scrappy foi desenvolvido

  • O Scrappy está relacionado a tendências como programação orientada pelo usuário, “small computing”, “casual programming” e “home-cooked software”
  • Segue um caminho diferente da programação visual tradicional (baseada em blocos ou nós e conexões), combinando manipulação intuitiva e scripting
  • Foi inspirado em HyperCard, Visual Basic e mídia online colaborativa, e valoriza a experiência de ferramentas de produtividade em canvas e colaboração em tempo real (como Google Docs e Figma).
  • O Scrappy, diferente de grandes apps comerciais ou abordagens de geração automática por IA, maximiza o controle direto do usuário, a personalização, a diversão e a criatividade
  • Mesmo sem gerar código diretamente, oferece uma experiência de criação de apps mais fácil e mais humana.

Público-alvo do Scrappy

  • Otimizadores de processos de trabalho: pessoas que querem melhorar fluxos complexos sem ajuda de especialistas
  • Professores e alunos: podem focar na essência da programação sem depender de habilidades secundárias (linha de comando, configuração de ambiente)
  • Desenvolvedores por hobby: quem quer explorar rapidamente vários projetos longe da complexidade dos apps de massa
  • Pessoas com espírito DIY: usuários que querem criar seus próprios apps para casa, hobbies e afins

Atualmente, ainda é difícil para um iniciante absoluto criar apps completos no Scrappy (é necessário algum conhecimento de JavaScript), mas compartilhar e remixar já é possível mesmo para quem não programa.

Que tipo de app combina com o Scrappy?

  • Compartilhar com amigos/conhecidos: a maioria dos Scrapps é adequada para trabalho colaborativo em tempo real entre vários usuários
  • Modificação e melhoria contínuas: dá para ajustar o app imediatamente enquanto ele está em uso, sem processo de deploy ou build
  • Cálculo ou manipulação em pequena escala: funciona melhor como documento compartilhado + um pouco de computação do que como sistema complexo
  • Mínimo de atrito para o usuário: acesso e uso só com um link, sem etapas desnecessárias como criar conta
  • Pequeno grupo confiável de usuários: não é indicado quando controle de permissões ou criticidade de missão são essenciais

Exemplos de ideias de apps: flashcards personalizados, agenda de reuniões, gerenciamento de workshops online, mural da família, planejamento de viagens etc.

Scrappy vs apps de massa

Quando não existe um app popular adequado, ou quando nenhum se encaixa bem, é possível criar e compartilhar um diretamente com o Scrappy. Vantagens do Scrappy:

  • Só tem as funções necessárias: sem elementos desnecessários
  • Toque pessoal: um app feito por você tem mais significado e apego
  • Divertido de modificar: é possível personalizar cores, layout e até adicionar humor livremente
  • Remix/compartilhamento fácil: outros usuários podem modificar e reutilizar com facilidade
  • Design centrado em colaboração: várias pessoas podem manipular e editar ao mesmo tempo
  • Uso imediato: basta clicar no link, sem cadastro de conta
  • Propriedade clara dos dados: os dados ficam armazenados localmente, sob controle total do usuário

Scrappy vs geração de apps com IA

A IA pode gerar apps automaticamente, mas as vantagens do Scrappy estão na facilidade de entendimento, na colaboração em tempo real e no senso criativo de propriedade

  • Estrutura fácil de entender: baseada em objetos visuais, sem código complexo
  • Suporte à colaboração em tempo real: vários usuários podem colaborar e editar simultaneamente
  • Mais diversão e criatividade: oferece feedback imediato e o prazer de modificar ativamente

Scrappy vs HyperCard e ferramentas posteriores

  • Compartilhamento amigável para a internet: apps do Scrappy podem ser compartilhados online apenas com um link
  • Ambiente de colaboração em tempo real: suporta edição e execução simultâneas
  • UI e interação modernas: canvas infinito e suporte a vários tipos de objetos
  • Scripting em JavaScript: funcionamento com uma linguagem moderna e amplamente usada
  • Objetos interativos mais variados: suporte a string, número, data, JSON etc.
  • Fórmulas reativas e conexão de estado: permite relações dinâmicas semelhantes às de planilhas

Planos futuros

  • Reduzir a barreira de entrada para usuários que não são programadores
    • autocomplete de código, depuração mais simples, visualização de relações, mensagens de erro mais fáceis de entender, assistente baseado em IA
    • compartilhamento fácil e rápido, galeria pública, reforço do suporte mobile
  • Fortalecer e expandir funcionalidades
    • ampliar recursos de coleções e processamento de dados, gerenciamento de objetos repetitivos, introdução de componentes reutilizáveis
    • expansão do Scrappy (suporte a novos objetos), melhoria da consistência conceitual etc.

1 comentários

 
GN⁺ 2025-06-19
Comentários do Hacker News
  • Gosto da direção deste projeto, mas já passei pela experiência de sentir que o modelo SaaS hospedado é diferente do que eu quero. Para projetos de um dia, como um contador simples, tudo bem, mas se for um app pequeno para usar por anos, a dependência vira um problema. Por mais baixa que seja a curva de aprendizado, ela sempre existe; eu prefiro acessibilidade, uma linguagem fácil e ferramentas nas quais eu mesmo possa colocar uma GUI, algo que dure por muito tempo. Não acho que o código precise ficar totalmente escondido; ele deveria ser fácil de usar de um jeito que as pessoas realmente consigam fazer coisas. Basta lembrar quantas pessoas aprenderam CSS no MySpace: começa no copiar e colar, mas no fim a pessoa ajusta até ficar com a sua cara. Hoje em dia, pessoalmente, uso principalmente HTML/CSS/JS e, se realmente preciso de backend, uso PHP puro, sem framework. Mas essa abordagem tem a desvantagem de ficar presa ao navegador; ainda assim, no trabalho, pequenos projetos feitos assim, inclusive com AutoHotKey, funcionam há mais de 10 anos quase sem manutenção. Em especial, larguei meus scripts de AutoHotKey há 8 anos, quando mudei para macOS, mas meus colegas ainda os usam várias vezes por dia. Mesmo que AutoHotKey deixe de funcionar, o código que já foi criado continua utilizável. Já com soluções em estilo SaaS, se o fundador perder o interesse e partir para outra coisa, surge o risco de ter que refazer tudo. O ponto central é que quem procura esse tipo de solução “scrappy” não quer ficar reconstruindo tudo toda vez.

    • Para esse tipo de solução, acho que algo no estilo TiddlyWiki faz mais sentido. O TiddlyWiki coloca o app web inteiro dentro de um único arquivo HTML e, antigamente, quando você mudava algo, ele salvava no próprio arquivo HTML, se auto-replicando. Mais recentemente surgiram várias opções, inclusive suporte a armazenamento em backend. Com arquivo HTML auto-replicável e acesso opcional a backend, parece uma escolha muito mais confiável para projetos pequenos e personalizados de uso pessoal. No mínimo, a grande vantagem é a resiliência.
    • Recomendo codeboot.org. É uma IDE Python totalmente client-side, com suporte a execução passo a passo, sistema de arquivos virtual não hierárquico, FFI com código JS e vários outros recursos (veja a documentação). Também é muito fácil compartilhar apps: basta clicar com o botão direito no botão de play e copiar a URL. Já usei para resolver vários problemas, como limpeza de dados, e muitas vezes acabo favoritando e usando os apps feitos assim. Funciona de verdade muito bem e, se alguém tiver curiosidade, AMA. Está sendo desenvolvido ativamente e há novos recursos bem legais a caminho.
    • Outra possibilidade seria abrir todo o código do SaaS como open source para garantir usabilidade no longo prazo. O Penpot usa bem essa abordagem. A maioria das pessoas usa como SaaS, mas também dá para fazer self-hosting. Claro que certificação de distribuição e assinatura de app continuam sendo partes inevitavelmente difíceis, mas talvez um modelo no estilo Web3 também ajude. Ou então algo como o PICO-8 ou o antigo Flash: abrir o runtime e distribuir os “cartuchos” ou apps. Criar uma cadeia de distribuição confiável fora do SaaS é bem complicado, mas como há precedentes históricos, acho que vale tentar. Veja Penpot / PICO-8
    • Como co-criador do Scrappy, concordo totalmente com a importância da longevidade do software. O Scrappy foi projetado com arquitetura local-first, sem backend tradicional, então a dependência de nuvem se resume a um simples servidor de sincronização. (Depois que essa discussão cresceu no HN, corremos para adicionar detalhes técnicos ao FAQ.) Acho que isso é um diferencial técnico e financeiro em relação às ferramentas SaaS low-code/no-code. No começo, experimentamos salvar scraps em um único arquivo HTML autocontido, mas esse recurso não está exposto atualmente.
    • Tenho feito esse tipo de coisa com Cursor e vibe coding, e estou muito satisfeito. Recentemente, criei um rastreador de aviões para meu espelho mágico que recebe as rotas da minha casa via SDR, acrescenta informações dos voos a partir do aeroporto e exibe tudo no estilo de um painel flip de estação de trem. Eu quase não sabia JS no frontend, mas em umas 10 horas de código consegui terminar um app bem decente. Antigamente isso teria levado mais de 2 meses e provavelmente eu teria desistido no meio; com vibe coding, foi uma experiência muito divertida e positiva. Tem cerca de 1200 sLOC, e me orgulho de dizer que o código está em um nível quase profissional em logging, performance e qualidade, melhor do que muito código comercial médio.
  • O CardStock não foi mencionado no texto, mas parece ter objetivos e abordagem parecidos com os do Scrappy. Diferente do Scrappy, o CardStock é open source e roda localmente. Veja CardStock / repositório no GitHub. O Decker também é open source e já implementa vários requisitos do roadmap do Scrappy, como linguagem de consulta para dados tabulares, widget de grade e abstração de componentes em “Contraption”. Veja Decker.

    • Eu procurava uma ferramenta assim há muito tempo, e o fato de o CardStock ter um app desktop faz uma diferença enorme para mim.
  • Está no roadmap fazer os apps criados funcionarem bem no mobile, mas parece que edição no próprio celular está fora de cogitação (“uma tela sensível ao toque do tamanho da palma da mão é desconfortável para editar Scrapps”). Só que hoje muita gente usa o celular como único dispositivo de computação, e há quem escreva até código ou romance no mobile. Então, mesmo que seja um pouco desconfortável, se eles pensassem também em uma interface de edição para mobile, o impacto dessa ferramenta seria muito maior.

  • Uma das melhores coisas que já fiz foi passar uma semana criando um app simples que coloca os registros de caminhada do Apple Watch em um único mapa grande, publicar na AppStore e compartilhar com conhecidos. Um ano depois, amigos e até pessoas que encontraram o app por acaso ainda mandam mensagens mostrando que caminharam a cidade inteira, e isso me deixa muito feliz. Não deu dinheiro, mas foi uma experiência realmente recompensadora. Como o OP disse, fazer apps simples para os amigos por diversão é uma das maiores alegrias.

    • Fiquei curioso pelo link do app.
    • Se você imaginar quantas paredes e quantos obstáculos tiveram que ser superados para colocar isso no ar, dá para ver como muita gente teria desistido em alguma etapa. No fim, o usuário continua sem controlar nada e preso ao fornecedor. Dá até para imaginar como seria bom um mundo em que você pudesse simplesmente dar a ordem para a IA e portar livremente isso para um relógio open source.
  • Nunca vi um ambiente de programação realmente tão útil para usuário final quanto uma planilha.

    • Como exemplo de alguém que levou isso ao extremo, recomendo pyspread.
    • Para mim, passo longe por falta de testes, controle de versão e suporte a bibliotecas.
    • No fim, é melhor aprender a programar direto. Não entendo por que aprender essas ferramentas. Do ponto de vista de um desenvolvedor, é só construir; com LLM, coisas bem simples saem fácil no vibe coding e não há muito a perder. E, mesmo para não desenvolvedores, quantas pessoas de fato vão aprender uma ferramenta dessas? Tenho curiosidade sobre o TAM. Fico me perguntando quem vai querer se dar ao trabalho de montar um app arrastando peças.
  • Vibe coding não vai substituir desenvolvedores agora, mas para sistemas simples assim será o concorrente mais forte. Se você pedir para uma LLM criar um app simples, com HTML + JS embutido, com alguns ajustes o resultado já fica muito bom e até visualmente melhor exemplo.

    • Também estou tocando um side project com vibe coding. A cada poucas horas esbarro em problemas que a LLM não consegue resolver, então imagino que usuários sem experiência em programação talvez simplesmente não consigam passar disso. Acho que depende da stack usada e do escopo do projeto.
    • Relato de bug: se você digitar algo como 3 + 2 = 5.1, ele aceita como resposta correta.
    • Vibe coding corresponde exatamente ao objetivo original, e eles são antagonistas naturais.
    • Fiquei curioso sobre uma stack simples que permita self-hosting. Pessoalmente, preciso de Vue com autenticação, banco de dados offline multiplayer, hospedagem estática, hospedagem de arquivos e um recurso de filtro para que usuários não vejam dados de outras pessoas.
    • Eu gostaria de trocar o ponto de interrogação por espaço em branco ou sublinhado.
  • Estamos olhando para esse tema do ponto de vista do programador, mas acho que a oportunidade real está na comunidade. Por exemplo, talvez desse para começar com algo como uma app store pessoal para famílias, no estilo Masterson. Sem segurança, porque seria só entre conhecidos, e sem contribuição sem convite. Só jogando a ideia.

  • Se o processo é arrastar e soltar elementos de UI numa folha em branco, brigar com grid snapping porque ele não bate com o tamanho dos elementos, e no fim ainda ter que digitar JavaScript cru sem autocomplete, sem programação visual, sem ajuda de API e sem suporte de IA, fico me perguntando se isso é mesmo o estado da arte.

  • Também concordo 100% que, para iniciantes, a abordagem de “componentes programáveis” é melhor do que algo baseado em blocos. Estou no celular agora, mas pretendo testar no desktop em breve. Um ponto que faltou na análise é que as pessoas querem “compartilhamento fácil” e “custo zero”. Criar o app em si é fácil mesmo em ambientes mínimos, mas distribuir, por causa da barreira das app stores, ou hospedar é o problema; até família e amigos hesitam em pagar US$ 5 por mês. Na verdade, isso vale até para desenvolvedores profissionais.

    • É só fazer self-hosting em casa com servidor web + DNS dinâmico.
    • A ideia de compartilhar é boa, mas hospedagem/distribuição gratuita corre risco de abuso por usuários mal-intencionados.
  • Ao ler objetivos como “os computadores deveriam trabalhar para as pessoas, e isso deveria ser uma atividade para todos, como cozinhar ou usar um processador de texto”, achei tudo genérico demais. E aquele uso excessivo de em-dash, como em “tudo grátis, com live updates. LLM...”, me fez achar que tinha cara de texto gerado por IA. Pessoalmente, quando percebo que um conteúdo foi escrito por IA, meu interesse cai muito. Não culpo o criador, mas esse tipo de texto promocional não me atrai.

    • Esse estilo de em-dash é o jeito como eu escrevo na vida real há 10 ou 15 anos. Eu também não gosto muito de consumir conteúdo feito por IA, e se alguém só digitou um prompt, eu preferiria perguntar diretamente a uma LLM.
    • Se formos ser rigorosos sobre hífen, en dash e em dash, usar em dash como separador está perfeitamente correto. Não concordo com tratar isso como um sinal de IA.
    • Como co-criador do Scrappy, sou usuário de Macintosh há muito tempo, então sei muito bem a diferença entre hífen, en dash e em dash :) Às vezes usei IA só para polimento, nunca para gerar o texto. Escrevi tudo eu mesmo, então houve bastante trabalho real ali. (Na prática, a maior parte do trabalho ficou com o Pontus.)
    • Para digitar em dash, use a compose key e depois três hífens. — Assim. No Mac é shift-option-hyphen.