Scrappy - Crear pequeñas apps para ti y tus amigos

 (pontus.granstrom.me)
8 puntos por GN⁺ 2025-06-19 | 1 comentarios | Compartir por WhatsApp
  • Scrappy es una herramienta casera para crear software que ayuda incluso a personas no expertas a crear fácilmente pequeñas apps por su cuenta
  • A diferencia de las grandes apps comerciales o empresariales, permite resolver libremente problemas pequeños, personales y creativos
  • Ofrece una UI basada en canvas, edición sencilla de código y funciones de colaboración y compartición en tiempo real, por lo que también puede ser aprovechado por personas que no programan
  • Todas las apps (Scrapps) son multijugador por defecto, y se pueden usar y colaborar de inmediato sin crear una cuenta
  • A diferencia de la generación de código con IA o de las herramientas existentes, Scrappy pone énfasis en la manipulación directa por parte del usuario y la propiedad

Introducción y contexto

  • La mayoría del software está centrado en venderse al mercado masivo o en grandes apps personalizadas
  • Sin embargo, son muy raras las apps pequeñas y personalizadas que cubren las necesidades reales de cada persona
  • Scrappy es un prototipo de investigación que busca ayudar a cualquiera a crear por sí mismo apps simples y creativas para amigos y familiares
  • El objetivo de Scrappy es presentar de forma concreta la visión de que más personas puedan crear software creativo y personalizado, incluso sin experiencia profesional en programación

¿Qué es Scrappy?

  • Las apps creadas en Scrappy se llaman Scrapp
  • Ejemplos representativos:
    • App de práctica de aritmética para primaria: con dificultad ajustable
    • Contador de asistentes para eventos locales: para gestionar entradas y salidas desde varias puertas
    • Reloj calculador de costo de reuniones: calcula el costo de una reunión en tiempo real
    • Gestión semanal de tareas del hogar: permite manejar los horarios de cada integrante con flexibilidad

La experiencia de crear apps en Scrappy

  • Scrappy permite colocar objetos como botones y campos de texto sobre un canvas infinito similar a Figma, Miro o Google Slides
  • En el panel Inspector se pueden modificar propiedades directamente y también vincular código JavaScript a elementos como botones
  • La creación de apps se completa repitiendo paso a paso arrastrar/soltar, modificar propiedades e insertar código

Características principales:

  • Configuración de comportamientos básicos: puedes colocar campos y botones y conectar acciones de inmediato
  • Fórmulas reactivas: permiten implementar cambios de propiedades en tiempo real en respuesta a ciertas condiciones
  • Sincronización multijugador: el estado siempre se guarda y sincroniza en tiempo real
  • Edición en vivo: siempre se puede modificar en tiempo real sin separar ejecución y edición
  • Compartición selectiva: se pueden compartir y enlazar por separado solo partes específicas de la app
  • Manipulación visible de datos: permite depurar y editar viendo los datos como en una hoja de cálculo

Por qué se desarrolló Scrappy

  • Scrappy se relaciona con tendencias como user-driven programming, “small computing”, “casual programming” y “home-cooked software”, al buscar hacer realidad una programación guiada por el usuario
  • Toma un camino distinto al de la programación visual tradicional (basada en bloques o nodos y cables), combinando manipulación intuitiva y scripting
  • Se inspira en HyperCard, Visual Basic y medios en línea colaborativos, y da gran importancia a la experiencia de las herramientas modernas de productividad en canvas y de colaboración en tiempo real (Google Docs, Figma, etc.)
  • A diferencia de las grandes apps comerciales o los enfoques de generación automática con IA, Scrappy maximiza el control directo del usuario, así como la personalización, la diversión y la creatividad
  • Incluso sin generar código directamente, ofrece una experiencia de creación de apps más fácil y más humana

Usuarios objetivo de Scrappy

  • Quienes optimizan procesos de trabajo: personas que quieren mejorar flujos de trabajo complejos sin ayuda de especialistas
  • Docentes y estudiantes: pueden centrarse en la esencia de programar sin habilidades secundarias como línea de comandos o configuración de entornos
  • Desarrolladores por hobby: personas que quieren explorar rápidamente varios proyectos sin la complejidad de las apps masivas
  • Personas con mentalidad DIY: usuarios que quieren crear sus propias apps como hacen con su hogar o sus hobbies

Actualmente, sigue siendo difícil que una persona completamente principiante cree una app con Scrappy (todavía se requiere algo de conocimiento de JavaScript), pero compartir y remixar sí es posible incluso para quienes no programan.

¿Qué tipo de apps conviene crear en Scrappy?

  • Para compartir con amigos o conocidos: la mayoría de los Scrapps se presta bien para el trabajo colaborativo en tiempo real entre varios usuarios
  • Para modificaciones y mejoras continuas: se pueden editar al instante incluso mientras la app está en uso, sin proceso de despliegue ni compilación
  • Para cálculos o manipulaciones pequeñas: resulta más eficaz para documentos compartidos con un poco de cómputo que para sistemas complejos
  • Para minimizar la fricción del usuario: se puede acceder y usar solo con un enlace, sin pasos innecesarios como crear una cuenta
  • Para grupos pequeños de confianza: no es adecuado si el control de permisos o el uso mission-critical son indispensables

Ejemplos de ideas de apps: tarjetas de estudio personalizadas, agenda de reuniones, gestión de talleres en línea, tablero familiar, planificador de viajes, etc.

Scrappy vs apps masivas

Si no puedes encontrar una app popular adecuada, o no existe una que te sirva, puedes crearla tú mismo y compartirla con Scrappy. Ventajas de Scrappy:

  • Tiene solo las funciones necesarias: sin elementos innecesarios
  • Toque personal: una app hecha por ti tiene más significado y apego
  • Se puede modificar de forma divertida: puedes decorar libremente colores y layouts, e incluso añadir humor
  • Remix y compartición fáciles: otros usuarios pueden modificarla y reutilizarla con facilidad
  • Diseño centrado en la colaboración: varias personas pueden usarla y editarla al mismo tiempo
  • Uso inmediato: basta con hacer clic en un enlace, sin registrarse
  • Propiedad clara de los datos: los datos se guardan localmente y quedan totalmente bajo el control del usuario

Scrappy vs generación de apps con IA

La IA puede generar apps automáticamente, pero la ventaja de Scrappy está en la facilidad para entenderlo, la colaboración en tiempo real y la sensación de autoría creativa

  • Estructura fácil de entender: basada en objetos visuales, sin código complejo
  • Soporte para colaboración en tiempo real: varios usuarios pueden colaborar y editar al mismo tiempo
  • Más diversión y creatividad: ofrece retroalimentación inmediata y el placer de modificar activamente

Scrappy vs HyperCard y herramientas posteriores

  • Compartición amigable para internet: las apps de Scrappy se pueden compartir en línea solo con un enlace
  • Entorno de colaboración en tiempo real: admite edición y ejecución simultáneas
  • UI e interacción modernas: canvas infinito y soporte para diversos objetos
  • Scripting en JavaScript: funciona con un lenguaje moderno y ampliamente usado
  • Mayor variedad de objetos interactivos: soporta cadenas, números, fechas, JSON, etc.
  • Fórmulas reactivas y conexión de estados: permite relaciones dinámicas similares a una hoja de cálculo

Planes a futuro

  • Reducir la barrera de entrada para usuarios no programadores
    • autocompletado de código, depuración más sencilla, visualización de relaciones, mensajes de error fáciles de entender, asistentes con IA
    • compartición simple y rápida, galería pública, mejor soporte móvil
  • Fortalecer y ampliar funciones
    • mejorar colecciones y procesamiento de datos, gestión de objetos repetitivos, incorporación de componentes reutilizables
    • ampliar la extensibilidad de Scrappy (soporte para nuevos objetos), mejorar la consistencia conceptual, etc.

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-06-19
Opiniones en Hacker News

  • Me gusta la dirección de este proyecto, pero comparto la experiencia de sentir que el enfoque de SaaS alojado no es lo que yo quiero. Para proyectos de un día, como un contador pequeño, no importa tanto, pero si es una app pequeña para usar durante años, la dependencia se vuelve un problema. Por más baja que sea la curva de aprendizaje, sigue existiendo; más bien preferiría algo accesible y con un lenguaje sencillo que pueda usarse a largo plazo, y herramientas a las que yo mismo pueda ponerles una GUI. No creo que el código deba quedar completamente oculto; debería hacerse fácil de una manera que la gente realmente pueda manejar. Si uno recuerda cuánta gente aprendió CSS gracias a MySpace, empieza copiando y pegando, pero al final lo ajusta para hacerlo suyo. En lo personal, hoy uso sobre todo HTML/CSS/JS y, si de verdad necesito backend, uso PHP puro, sin frameworks. Pero este enfoque tiene la desventaja de quedar atado al navegador; aun así, en mi trabajo hay proyectos pequeños hechos así (incluyendo AutoHotKey) que llevan más de 10 años funcionando casi sin mantenimiento. En particular, dejé de tocar scripts de AutoHotKey hace 8 años cuando me cambié a macOS, pero mis colegas todavía los usan varias veces al día. Incluso si AutoHotKey dejara de funcionar, el código ya hecho seguiría siendo utilizable. En cambio, con soluciones tipo SaaS existe el riesgo de tener que rehacer todo si la persona fundadora pierde interés y se va a otra cosa. El punto clave es que quienes buscan soluciones “scrappy” no quieren volver a construirlas cada vez.

    • Para una solución de este tipo, creo que algo como TiddlyWiki tiene más sentido. TiddlyWiki mete toda la webapp en un solo archivo HTML y, antes, cuando cambiabas algo, lo guardaba en el propio archivo HTML, así que se autorreplicaba. Últimamente también soporta almacenamiento en backend y otras variantes. Con un archivo HTML autorreplicable y acceso opcional a backend, puede ser una opción mucho más confiable para proyectos pequeños y personalizados de uso personal. Al menos, su gran ventaja es la resiliencia.
    • Recomiendo codeboot.org. Es un IDE de Python totalmente del lado del cliente, con soporte para ejecución paso a paso, un sistema de archivos virtual no jerárquico, FFI para código JS y varias funciones más (ver documentación). Además, compartir apps es facilísimo: clic derecho en el botón de play, copiar URL y listo. Me ha servido para resolver problemas como limpieza de datos y muchas veces termino guardando como marcador las apps hechas así para usarlas luego. De verdad funciona muy bien, y si alguien tiene curiosidad, AMA. Está en desarrollo activo y vienen funciones nuevas muy buenas.
    • También podría existir una forma de garantizar la usabilidad a largo plazo publicando como open source todo el código del SaaS. Penpot usa bien ese modelo. La mayoría lo usa como SaaS, pero también puede autohospedarse. Claro, hay cosas inevitablemente difíciles, como certificar distribuciones o firmar apps, pero quizá un enfoque tipo Web3 también ayudaría. O bien, como PICO-8 o el Flash de antes, se podría abrir el runtime y distribuir “cartuchos” o apps. Crear un canal de distribución confiable fuera del SaaS es bastante complejo, pero como tiene antecedentes reales en la historia, me parece algo que vale la pena intentar. Ver Penpot / PICO-8
    • Como cocreador de Scrappy, coincido por completo en que la usabilidad a largo plazo del software es importante. Scrappy está diseñado con una arquitectura local-first, sin backend tradicional, así que la dependencia de la nube se limita a un simple servidor de sincronización. (Después de que esta discusión creciera en HN, agregamos apuradamente detalles técnicos al FAQ). Creo que ese es un punto diferenciador frente a las herramientas SaaS low-code/no-code tanto en lo técnico como en lo financiero. Desde el principio experimentamos con guardar scraps como archivos HTML autocontenidos de una sola página, aunque hoy esa función no está expuesta.
    • Yo estoy haciendo este tipo de cosas con Cursor y el enfoque de vibe coding, y la verdad estoy muy satisfecho. Hace poco hice un rastreador de aviones para mi casa: recibe información de rutas por SDR, le agrega datos de vuelos desde el aeropuerto y lo muestra en un espejo mágico con estilo de tablero flip de estación de tren. Del frontend casi no sabía nada de JS, pero tras unas 10 horas de programación terminé una app bastante buena. Antes esto me habría tomado más de 2 meses y probablemente lo habría abandonado, pero con vibe coding fue una experiencia muy divertida y positiva. Tiene unas 1200 sLOC y diría que el código, en logging/rendimiento/calidad, ya es de nivel semiprofesional (creo que mejor que el promedio de mucho código comercial).

  • CardStock no se menciona en el texto principal, pero parece tener objetivos y enfoque parecidos a los de Scrappy. A diferencia de Scrappy, CardStock es open source y también corre en local. Ver CardStock / repositorio de GitHub. Decker también es open source y ya implementa varios requisitos del roadmap de Scrappy (lenguaje de consultas para datos tabulares y widgets de grilla, abstracción de componentes en “Contraption”, etc.). Ver Decker.

    • Llevo mucho tiempo buscando una herramienta así, y para mí el hecho de que CardStock tenga app de escritorio significa muchísimo.

  • En el roadmap está hacer que las apps creadas funcionen bien en móvil, pero parece que editar desde móvil queda fuera de consideración (se menciona que “una pantalla táctil del tamaño de la palma es incómoda para editar Scrapps”). Pero hoy mucha gente usa el móvil como su único dispositivo de cómputo, e incluso hay quienes escriben código o novelas desde ahí. Por eso, aunque sea algo incómodo, si también consideraran una interfaz de edición móvil, el impacto de esta herramienta sería mucho mayor.

  • Una de las mejores cosas que he hecho fue crear, durante una semana, una app simple que pone los registros de caminatas del Apple Watch sobre un único mapa grande, subirla al AppStore y compartirla con conocidos. Un año después, amigos y personas que encontraron la app por casualidad todavía me mandan mensajes de confirmación tras recorrer una ciudad completa, y eso me llena de orgullo. No da dinero, pero fue una experiencia realmente gratificante. Como dice el OP, hacer apps simples por diversión para tus amigos es una de las mayores felicidades.

    • Me dio curiosidad el enlace de la app.
    • Si uno imagina cuántas paredes y cuántos obstáculos hubo que superar para lograr eso, muchísima gente se habría rendido en alguno de ellos. Al final, el usuario sigue sin poder controlar nada y queda atrapado por el proveedor. Dan ganas de imaginar lo bueno que sería un mundo donde pudieras ordenárselo directamente a una IA y luego portarlo libremente a un reloj open source.

  • Nunca he visto un entorno de programación realmente tan útil para usuarios finales como una hoja de cálculo.

    • Como ejemplo de llevar eso al extremo, recomiendo pyspread.
    • Yo paso: no tiene tests, control de versiones ni soporte de bibliotecas.
    • Al final sale mejor aprender a programar directamente. No entiendo por qué aprender una herramienta así. Desde la perspectiva de un desarrollador, simplemente lo haces tú mismo, y con un LLM puedes sacar algo muy simple con vibe coding sin mucho esfuerzo ni nada que perder. Incluso si no eres desarrollador, me pregunto cuánta gente realmente aprendería una herramienta así (me da curiosidad el TAM). Dudo que tanta gente quiera ponerse a arrastrar componentes para hacer una app.

  • vibe coding no va a reemplazar a los desarrolladores de inmediato, pero para sistemas simples como este sí será su competidor más fuerte. Incluso si le pides a un LLM que haga una app sencilla (HTML + JS embebido), con unos pequeños retoques ya queda muy bien, y hasta visualmente salía mejor ejemplo.

    • Yo también tengo un proyecto paralelo con vibe coding. Cada pocas horas me topo con un problema que el LLM no puede resolver, y pienso que un usuario sin experiencia programando quizá ni siquiera podría superarlo. Supongo que dependerá de la tecnología usada o del alcance del proyecto.
    • Reporte de bug: si ingresas un error como 3 + 2 = 5.1, lo toma como respuesta correcta.
    • vibe coding sí apunta al propósito original, y ellos son rivales naturales.
    • Me da curiosidad un stack de sistema simple que pueda autohospedarse. Personalmente necesito Vue con autenticación, base de datos offline multijugador, hosting estático, file hosting y una función de filtros para que los usuarios no puedan ver datos de otros.
    • Quiero reemplazar los signos de interrogación por espacios en blanco o guiones bajos.

  • Estamos abordando este tema desde la perspectiva de los programadores, pero creo que la oportunidad real está en la comunidad. Por ejemplo, podría empezar como una especie de App Store privada para una familia (estilo Masterson). Sin seguridad, porque todos se conocen, y sin posibilidad de contribuir si no hay invitación. Solo lo lanzo como idea.

  • Si terminas arrastrando y soltando elementos de UI sobre una hoja vacía, peleándote porque el ajuste a la cuadrícula no coincide con el tamaño de los componentes, y al final igual tienes que escribir JavaScript puro sin autocompletado, ni programación visual, ni ayuda de APIs, ni soporte de IA, entonces me pregunto si de verdad ese es el final del camino.

  • Yo también coincido al 100% con el enfoque de “componentes con scripting” en lugar de uno basado en bloques para principiantes. Ahora estoy en móvil, pero pienso probarlo luego en escritorio. Algo que faltó en el análisis es que la gente quiere “compartir fácil” y “costo cero”. Incluso en un entorno mínimo hacer la app en sí es fácil, pero distribuirla (la barrera del app store) y alojarla es el problema, y hasta familiares o conocidos dudan en pagar 5 dólares al mes. De hecho, a los desarrolladores profesionales les pasa lo mismo.

    • Basta con autohospedarlo en casa con un servidor web + DNS dinámico.
    • Compartir ideas está bien, pero el hosting/distribución gratis corre el riesgo de ser abusado por usuarios maliciosos.

  • Viendo frases aspiracionales como “las computadoras deberían trabajar para las personas y esto debería ser una actividad para todos, como cocinar o usar un procesador de textos”, me pareció demasiado genérico. Además, el uso excesivo de em dash (-) en cosas como “incluye actualizaciones en vivo, todo gratis. El LLM...” me hizo pensar que se nota demasiado como texto generado por IA. Personalmente, cuando percibo que un contenido fue escrito por IA, pierdo el interés muy rápido. No es culpa de la persona creadora, pero a mí tampoco me atrae mucho ese tipo de copy.

    • Ese estilo de em dash es mi forma de escribir IRL desde hace 10~15 años. A mí tampoco me gusta mucho consumir contenido hecho por IA, y si alguien solo metió un prompt, entonces yo preferiría preguntarle directamente al LLM.
    • Si nos ponemos estrictos con el uso de guion, en dash y em dash, usar el em dash como separador es perfectamente correcto. No estoy de acuerdo con tomarlo como señal de IA.
    • Como cocreador de Scrappy, llevo años siendo usuario de Macintosh, así que tengo clarísima la diferencia entre hyphen, en dash y em dash :) Solo usé IA de vez en cuando para pulir, nunca para generar el texto. Lo escribí yo mismo, así que hubo muchísimo trabajo real (aunque en la práctica la mayor parte del trabajo la hizo Pontus).
    • Para escribir un em dash usa la tecla compose y luego tres guiones. — Así. En Mac es shift-option-hyphen.