Scrappy – Kleine Apps nur für dich und deine Freunde bauen
(pontus.granstrom.me)- Scrappy ist ein Tool zum Erstellen selbstgemachter Software, das auch Nichtfachleuten hilft, ganz einfach kleine Apps selbst zu bauen
- Anders als große kommerzielle Apps oder Enterprise-Anwendungen lassen sich damit persönliche und kreative Probleme im kleinen Rahmen frei lösen
- Es bietet eine canvasbasierte UI, einfache Codebearbeitung sowie Funktionen für Zusammenarbeit und Teilen in Echtzeit, sodass es auch von Nicht-Programmierern genutzt werden kann
- Alle Apps (Scrapps) sind standardmäßig für Multiplayer ausgelegt und können sofort ohne Kontoerstellung genutzt und gemeinsam bearbeitet werden
- Anders als KI-Codegenerierung oder bestehende Tools betont Scrappy die direkte Bedienung und Eigentümerschaft durch den Nutzer
Einführung und Hintergrund
- Die meiste Software ist auf den Verkauf im Massenmarkt oder auf große maßgeschneiderte Anwendungen ausgerichtet
- Kleine, individuell angepasste Apps, die tatsächliche persönliche Bedürfnisse einzelner Menschen erfüllen, sind jedoch sehr selten
- Scrappy ist ein Forschungsprototyp, der es jedem ermöglichen soll, einfache und kreative Apps direkt für Freunde und Familie zu erstellen
- Das Ziel von Scrappy ist es, eine Vision zu konkretisieren, in der mehr Menschen kreative und personalisierte Software erstellen können, auch ohne Programmierexpertise
Was ist Scrappy?
- In Scrappy erstellte Apps werden Scrapps genannt
- Typische Beispiele:
- Kopfrechen-App für Grundschüler: Schwierigkeit anpassbar
- Teilnehmerzähler für lokale Veranstaltungen: Verwaltung von Ein- und Ausgängen an mehreren Eingängen
- Uhr zur Berechnung von Meetingkosten: Berechnet Meetingkosten in Echtzeit
- Wöchentliche Haushaltsaufgaben-Verwaltung: Flexible Terminverwaltung für einzelne Mitglieder
Die Erfahrung, in Scrappy Apps zu bauen
- In Scrappy werden Objekte wie Buttons und Textfelder auf einer unendlichen Canvas platziert, ähnlich wie in Figma, Miro oder Google Slides
- Im Inspector-Panel lassen sich Eigenschaften direkt bearbeiten, und an Buttons usw. kann auch JavaScript-Code gebunden werden
- Die App-Erstellung wird schrittweise durch Wiederholung von Drag-and-drop, Eigenschaftsbearbeitung und Einfügen von Code abgeschlossen
Hauptmerkmale:
- Grundlegendes Verhalten konfigurieren: Felder und Buttons platzieren und sofort mit Verhalten verknüpfen
- Reaktive Formeln: Echtzeitänderungen von Eigenschaften als Reaktion auf bestimmte Bedingungen umsetzen
- Multiplayer-Synchronisierung: Zustand wird jederzeit in Echtzeit gespeichert und synchronisiert
- Live-Bearbeitung: Änderungen sind jederzeit in Echtzeit möglich, ohne Trennung zwischen Ausführung und Bearbeitung
- Selektives Teilen: Nur bestimmte Teile einer App können separat geteilt und verknüpft werden
- Sichtbare Datenmanipulation: Daten lassen sich wie in einer Tabellenkalkulation beim Debuggen ansehen und bearbeiten
Warum Scrappy entwickelt wurde
- Scrappy steht im Zusammenhang mit Trends wie nutzergetriebener Programmierung sowie „small computing“, „casual programming“ und „home-cooked software“
- Anders als bestehende visuelle Programmierung (Blöcke, Node-Wire-basierte Systeme) schlägt es einen anderen Weg ein und kombiniert intuitive Manipulation mit Skripting
- Inspiriert wurde es von HyperCard, Visual Basic und gleichzeitigen Online-Medien; außerdem wird die Erfahrung mit Produktivitäts-Canvas-Tools und Echtzeit-Zusammenarbeit (Google Docs, Figma usw.) hoch gewichtet
- Anders als große kommerzielle Apps oder KI-basierte automatische Generierung setzt Scrappy auf direkte Kontrolle durch den Nutzer und maximiert Personalisierung, Spaß und Kreativität
- Auch ohne selbst Code zu erzeugen, bietet es eine einfachere und menschenfreundlichere Erfahrung beim App-Bau.
Zielgruppe von Scrappy
- Optimierer von Arbeitsprozessen: Menschen, die komplexe Abläufe ohne Hilfe von Experten verbessern möchten
- Lehrkräfte und Schüler: Können sich ohne Nebentechniken wie Kommandozeile oder Umgebungssetup auf das Wesen der Programmierung konzentrieren
- Hobbyentwickler: Menschen, die der Komplexität von Massenmarkt-Apps entkommen und schnell verschiedene Projekte ausprobieren wollen
- DIY-orientierte Nutzer: Menschen, die ihre eigenen Apps so selbst bauen möchten wie Dinge für Zuhause oder Hobbys
Derzeit ist es für völlige Anfänger noch schwierig, mit Scrappy Apps zu bauen (ein gewisses JavaScript-Wissen ist nötig), aber Teilen und Remixen ist auch für Nicht-Programmierer möglich.
Welche Apps eignen sich gut für Scrappy?
- Mit Freunden/Bekannten teilen: Die meisten Scrapps eignen sich für gemeinsame Echtzeitnutzung mit mehreren Personen
- Laufend ändern und verbessern: Selbst während der Nutzung kann eine App sofort geändert werden, ohne Deploy- oder Build-Prozess
- Kleine Berechnungen oder Manipulationen: Eher für geteilte Dokumente plus etwas Computing als für komplexe Systeme geeignet
- Minimale Reibung für Nutzer: Zugriff und Nutzung nur per Link, ohne unnötige Schritte wie Kontoerstellung
- Kleine Gruppe vertrauenswürdiger Nutzer: Weniger geeignet, wenn Rechteverwaltung oder mission-kritische Anforderungen nötig sind
Beispiele für App-Ideen: angepasste Karteikarten, Meeting-Agenda, Verwaltung von Online-Workshops, Familien-Pinnwand, Reiseplaner usw.
Scrappy vs. Massenmarkt-Apps
Wenn sich keine passende populäre App finden lässt, kann man sie mit Scrappy selbst bauen und teilen. Vorteile von Scrappy:
- Nur die nötigen Funktionen: Keine überflüssigen Elemente
- Persönliche Handschrift: Eine selbst gemachte App hat mehr Bedeutung und emotionale Bindung
- Lässt sich mit Spaß anpassen: Farben und Layouts frei gestalten, auch Humor hinzufügen
- Einfaches Remixen/Teilen: Andere Nutzer können sie leicht ändern und wiederverwenden
- Kollaborationszentriertes Design: Mehrere Nutzer können gleichzeitig bedienen und bearbeiten
- Sofort nutzbar: Direkte Verwendung per Linkklick, ohne Registrierung
- Klare Datenhoheit: Daten werden lokal gespeichert und vollständig vom Nutzer kontrolliert
Scrappy vs. KI-basierte App-Erstellung
Auch wenn KI Apps automatisch erzeugen kann, liegen Scrappys Vorteile in Verständlichkeit, Echtzeit-Zusammenarbeit und kreativem Besitzgefühl
- Leicht verständliche Struktur: Visuelle Objektbasis ohne komplexen Code
- Unterstützung für Zusammenarbeit in Echtzeit: Mehrere Nutzer können gleichzeitig kooperieren und Änderungen vornehmen
- Mehr Spaß und Kreativität: Bietet unmittelbares Feedback und die Freude an aktiver Anpassung
Scrappy vs. HyperCard und nachfolgende Tools
- Internetfreundliches Teilen: Scrappy-Apps können online allein per Link geteilt werden
- Echtzeit-Kollaborationsumgebung: Unterstützt gleichzeitiges Bearbeiten und Ausführen
- Moderne UI und Interaktion: Unendliche Canvas, Unterstützung für verschiedene Objekte
- JavaScript-Skripting: Nutzung einer modernen und verbreiteten Sprache
- Vielfältigere interaktive Objekte: Unterstützt Strings, Zahlen, Datum, JSON usw.
- Reaktive Formeln und Zustandsverknüpfung: Dynamische Beziehungen ähnlich wie in Tabellenkalkulationen möglich
Zukunftspläne
- Die Einstiegshürde für nicht-programmierende Nutzer senken
- Code-Autovervollständigung, einfacheres Debugging, Visualisierung von Beziehungen, leichter verständliche Fehlermeldungen, KI-basierter Assistent
- Einfaches und schnelles Teilen, öffentliche Galerie, stärkere mobile Unterstützung
- Funktionen stärken und erweitern
- Ausbau von Sammlungs- und Datenverarbeitungsfunktionen, Verwaltung wiederkehrender Objekte, Einführung wiederverwendbarer Komponenten
- Erweiterbarkeit von Scrappy (Unterstützung neuer Objekte), Verbesserung der konzeptionellen Konsistenz usw.
1 Kommentare
Hacker-News-Kommentare
Ich mag die Ausrichtung dieses Projekts, möchte aber meine Erfahrung teilen, dass ein gehostetes SaaS-Modell nicht das ist, was ich suche. Für Tagesprojekte wie kleine Zähler ist das egal, aber bei kleinen Apps, die ich über Jahre nutzen will, ist die Abhängigkeit aus meiner Sicht problematisch. So niedrig die Lernkurve auch sein mag, sie existiert am Ende trotzdem; lieber hätte ich einen Ansatz mit langlebiger Zugänglichkeit, einer einfachen Sprache und Werkzeugen, auf die ich selbst ein GUI setzen kann. Code muss nicht vollständig verborgen werden; er sollte so leicht zugänglich gemacht werden, dass Menschen tatsächlich damit etwas anfangen können. Wenn man daran denkt, wie viele Leute durch MySpace CSS gelernt haben: Copy-Paste ist zwar der Einstieg, aber am Ende passt man es an und macht etwas Eigenes daraus. Ich nutze persönlich heute vor allem HTML/CSS/JS, und wenn ich wirklich ein Backend brauche, dann pures PHP, ohne Framework. Dieser Ansatz hat zwar den Nachteil, an den Browser gebunden zu sein, aber kleine Projekte, die wir bei der Arbeit auf diese Weise gebaut haben, laufen seit über zehn Jahren mit kaum Wartung gut, inklusive AutoHotKey. Besonders die AutoHotKey-Skripte habe ich vor acht Jahren beim Wechsel zu macOS aufgegeben, aber meine Kollegen nutzen sie noch heute täglich mehrfach. Selbst wenn AutoHotKey irgendwann nicht mehr funktionieren sollte, kann bereits geschriebener Code weiterhin verwendet werden. Bei SaaS-Lösungen besteht dagegen das Risiko, dass man alles neu bauen muss, wenn der Gründer das Interesse verliert. Genau das ist der Punkt: Menschen, die nach solchen „scrappy“ Lösungen suchen, wollen sie nicht jedes Mal neu bauen müssen.
CardStock wurde im Artikel nicht erwähnt, scheint aber Ziel und Ansatz mit Scrappy zu teilen. Anders als Scrappy ist CardStock Open Source und läuft lokal. Siehe CardStock / GitHub-Repository. Decker ist ebenfalls Open Source und hat bereits viele Anforderungen aus Scrappys Roadmap umgesetzt, etwa eine Abfragesprache für Tabellendaten, ein Grid-Widget und die Abstraktion von Bauteilen zu „Contraptions“. Siehe Decker.
Auf der Roadmap steht zwar, dass auf Mobilgeräten erstellte Apps gut funktionieren sollen, aber mobiles Editieren selbst scheint nicht vorgesehen zu sein („ein Touchscreen in Handflächengröße ist unbequem zum Bearbeiten von Scrapps“). Wir leben aber inzwischen in einer Zeit, in der viele Menschen Mobilgeräte als einziges Computing-Device nutzen und sogar Code oder Romane darauf schreiben. Deshalb würde der Einfluss dieses Tools deutlich größer, wenn man auch über ein mobiles Bearbeitungsinterface nachdenkt, selbst wenn es etwas unbequem wäre.
Eines der besten Dinge, die ich je gemacht habe, war eine simple App, die ich innerhalb einer Woche gebaut und in den AppStore gestellt habe, damit sie die Apple-Watch-Gehdaten auf eine einzige große Karte legt und ich sie mit Bekannten teilen konnte. Ein Jahr später schicken mir Freunde und zufällige Nutzer, die die App entdeckt haben, noch immer Nachrichten, dass sie ganze Städte zu Fuß abgelaufen haben. Finanziell hat es nichts gebracht, aber es war unglaublich erfüllend. Wie OP sagt: Aus Spaß einfache Apps für Freunde zu bauen, ist eines der größten Glücksgefühle.
Ich habe noch nie eine Programmierumgebung gesehen, die für Endnutzer in der Praxis so brauchbar ist wie ein Spreadsheet.
Vibe Coding wird Entwickler nicht sofort ersetzen, aber für solche einfachen Systeme ist es der stärkste Konkurrent. Wenn man ein LLM bittet, eine einfache App zu bauen, etwa HTML mit eingebettetem JS, erhält man nach etwas Nacharbeit etwas sehr Fertiges, optisch oft sogar ansprechender. Siehe Beispiel.
Wir betrachten dieses Thema aus der Sicht von Programmierern, aber ich glaube, die eigentliche Chance liegt in Communitys. Man könnte zum Beispiel mit einer Art privatem App-Store für Familien anfangen, im Masterson-Stil. Ohne Sicherheit, weil sich ohnehin alle kennen, und Beiträge nur auf Einladung. Nur so eine Idee.
Wenn das Ende darin besteht, UI-Elemente auf ein leeres Blatt zu ziehen, ständig mit einem Grid-Snapping zu kämpfen, das nicht zu den Größen der UI-Elemente passt, und dann doch rohes JavaScript eintippen zu müssen, ganz ohne Code-Autovervollständigung, visuelles Programmieren, API-Hilfen oder KI-Unterstützung, frage ich mich, ob das wirklich alles sein soll.
Ich stimme dem Ansatz mit „skriptbaren Komponenten“ statt blockbasierter Bedienung für Anfänger ebenfalls zu 100 % zu. Ich bin gerade mobil unterwegs und werde es bald am Desktop ausprobieren. Ein Punkt, der in der Analyse fehlte: Menschen wollen „einfaches Teilen“ und „Nullkosten“. Selbst wenn das Bauen der App in einer Minimalumgebung leicht ist, scheitert es oft an Distribution (App-Store-Hürden) oder Hosting, und sogar Familie oder Bekannte zögern bei 5 Dollar im Monat. Ehrlich gesagt gilt das selbst für professionelle Entwickler.
Als ich solche Aussagen wie „Computer sollten für Menschen arbeiten und zu etwas werden, das alle tun können, wie Kochen oder Textverarbeitung“ gelesen habe, wirkte das auf mich zu allgemein. Und Formulierungen wie „mit Live-Updates, alles kostenlos. Das LLM …“ mit zu vielen Em-Dashes ließen es für mich nach KI-generiertem Text aussehen. Ich bin persönlich jemand, bei dem das Interesse stark sinkt, sobald ein Text erkennbar von KI geschrieben wirkt. Das ist nicht die Schuld des Erstellers, aber solche Copy spricht mich ebenfalls wenig an.