I like the idea! Now you're just left with the dilemma of what happens when you reach many people with it - will Scrappy be made for thousands of users, polished and flashy?
I'm on mobile now but I'll try this on desktop ASAP.
But I think one thing missing on the analysis is: people want ease of share and zero cost.
It's surprisingly simple to build a minimal app in some environments but then you get to distribution (app store are a huge gatekeeper) and/or hosting and e.g. my wife or kids won't be bothered to pay 5$/momth for it (and neither will many professional devs).
Decker[2] (which is also open-source) has answers to several of the things outlined on Scrappy’s roadmap, including facilities for representing and manipulating tabular data with its query language and grid widgets and the ability for users to abstract collections of parts into reusable "Contraptions".
[1] https://claude.ai/public/artifacts/bb451732-9559-401a-8000-b...
So it doesn't matter what Apple does because I'm never going to put something like that into any App Store.
OP is right, making simple apps for your friends for fun!
Making it possible to lookup and store data in a spreadsheet (maybe using something like the Google Sheets API) could unlock a huge amount of use cases.
I'll be watching this project with interest!
In the future, optimised open models will enable more people to develop tools locally, and with an open source AIDE (does this term exist yet? Artificial Intelligence Development Environment) publish / share it in different ways.
EDIT also Apple are in full control of what functionality they expose in their web APIs so even then it matters hugely
Swap JavaScript with VBA and this is the MS Access workflow.
I'd only start using this if it became ooensource though, can find anything to suggest it is.
From time to time I come up with micro-projects that solve very particular issues my friends are facing. Ones that are not easily solved with existing apps on the market. When I see my friends use them, it brings me joy!
But! For this I had to use traditional software development tools I was already familiar with - IDE, source control, etc. Scrappy or similar tools would not help me at all. The tool is targeting someone like my non-developer friends, but I doubt they could come up with a design for a solution, implement it in scrappy and then maintain it when something changes in the outside world.
On a separate node, I had great success with spreadsheets as both Frontend and sometimes Backend in various personal projects. And I'm not the only one, my friend made an addon for Google Sheets that pulls data from my specific bank's API - I use it to track my expenses. That's the kind of stuff I wanted to see in the article.
ok where is the scrappy backend? what data do you see? where do i make an account? i wish that this was more transparent/discussed since obviously this software is not entirely local?
> LLMs are getting better and better, and while they are far from able to make a full-fledged app without a lot of help from a software engineer, they can make small apps pretty reliably.
mildly disagree. llm generated apps tend to look better + i dont have to learn or stick to your preset primitives. even nontechnical people run into this pretty quickly
otherwise, nice labor of love. good going OP.
I've found that every few hours I get stuck on an issue that the LLM can't solve and a user with no programming experience would have little hope to crack it either.
I suppose this issue might depend on technology and scope of the project.
Recently I made a diet checklist [1] that I've been following more or less to the letter 5 days out of the week. I have a little Android button that just opens right up to the web page. I click, click, click, then move on with my day. If I feel I need to change something I can copy a plain text screenshot of what's on there currently and chat with Gemini about it.
I'm really liking this new wave of technology.
generic...
"with live updating — all for free. LLMs ar..." also see a fair few of these long dashes (18x) which is either a tell tail of you've used ChatGPT to generate the text or you've started writing like the AI.
I havn't thought about it that hard yet but i don't really like consuming AI generated content at all as soon as i see signs of it part of my brain turns off. And no slight to the creator, I have as much interest in writing this kind of copy as any developer would i'd imagine.
It's also my IRL writing style for the last 10-15 years :P
That said:
> I havn't thought about it that hard yet but i don't really like consuming AI generated content at all as soon as i see signs of it part of my brain turns off.
Likewise.
At least, when someone else did the prompting — I do like what LLMs can output, but when LLM answers are sufficient I prefer to cut out the middle-man and ask the LLM directly myself.
As a developer, I can just make it myself. Now with LLMs, if it's very simple and bounded, I can just vibe most of it with very little to lose.
As a lay person, I don't see what the TAM for this is. Who will spend the time to learn how to drag and drop an application?
https://app.codeboot.org/5.3.1/?init=.fbWF0aF9wcmFjdGljZS5we...
For more complex UIs, CodeBoot provides an FFI for accessing the DOM directly from Python code. For example here is a dice throwing app with a button to roll the dice again. The text in the button has translations to multiple languages and will adjust to the browser's default.
https://app.codeboot.org/5.3.1/?init=.fZGljZS5weQ==~XQAAgADq...
After all that you still control nothing and are vendor locked.
Imagine if you could just AI prompt that up and simply transfer to your open source watches.
What a world that would be.
The target audience problem is immediately apparent: they're building a product for people who can write JavaScript event handlers but somehow can't 'npx create-react-app'. This demographic is approximately twenty-seven people.
More critically, they've confused the problem space, in my opinion. The barrier to personal software isn't the lack of drag-and-drop of JavaScript environments. It's that software, unlike a meal or a home-made sweater, comes with an implicit support contract that lasts forever. When I cook dinner for friends, I'm not on the hook when they're hungry again next Tuesday. When my grandma knits a home-made sweater, she's not expected to keep supporting it in case I want to add a hood.
When the attendance counter has a race condition and the venue goes over capacity, guess who's getting the angry call when the fire marshal shows up for an inspection?
The "redistributing the means of software production" rhetoric rings particularly hollow from what appears to be a proprietary SaaS in the making. You don't democratize software by creating another walled garden. And their claim about "owning your data" while simultaneously offering real-time sync is either technically naive or deliberately misleading. How is the attendee counter example's counter state shared between users, if the data lives in local storage? I don't see how you can have both without server infrastructure that they control.
The actual nearest thing to their vision already exists and has millions of users: Spreadsheets. Non-technical people build complex, business-critical "applications" in spreadsheets every day. No JS required, local-first, and everyone already knows how to use it. But "we made a worse Excel" doesn't sound as revolutionary, I suppose.
The real unsolved problem isn't making it easier to create small apps - I build small tools for myself all the time. It's making them sustainable without creating permanent maintenance burdens. And that is not something you can solve with a new framework or SaaS - it's at it's core, a social issue.
Most of the examples can easily be replaced by pen and paper which is faster than building a app. More complex use cases require more complex solutions which I'm not sure this provides.
One use case could have been an application to study functions in time and frequency space. But does it provide an fft?
I typically end up using basic HTML/CSS/JS for stuff like this today. If I really need backend code, I'll use basic PHP (no frameworks or anything). But this ties me to a browser, which I'm not always a fan of. Some of these fairly scrappy little projects at work (done in the browser like this, and with AutoHotKey) have been going for 10+ years now, with very little maintenance. The AHK script I haven't touched in probably 8 years, since I moved to macOS at work, yet people still use it countless times per day. If AHK decides to stop operating, it's no big deal, the code that exists will still run. The same can't be said for these SaaS solution to this problem. People looking for scrappy solutions aren't looking to remake their solution every time a founder decides to move on to something else more interesting or profitable.
LLM helped me write a python script that searches the root folder, finds the right document (name is always the date of the day), and searches for the right folder in assigned Google Drive repository (and creates a yearly or monthly folder if a new month starts).
It also helped me create a yaml script for Github actions to trigger this once every day.
I felt like a magician. Since then I created second brain databases, internal index of valuable youtube videos, where I call the api to get transcripts and send it to llm, other note taking automations etc etc
As a side note, as I grew up, I realized I genuinely don’t care about the walled garden flame wars, and things alike. Life is pretty simple, I’d rather walked around a new neighbourhood and grab a pint.
One of the difficulties of course is notarizing/signing the apps and so-forth. Perhaps some Web3 solutions could help as well.
OR, another option would be like what PICO-8 does (or flash I guess)—release the runtime and distribute the “carts” or apps. :)
Still, it’s pretty complex creating a trusted distribution network outside of SaaS. Definitely could work though it’s been done before!
[1]: https://penpot.app/
Of course, as it stands, the examples were so simplistic that they could easily be vibe coded. I just tried it with the attendance counter and ChatGPT gave me that's only 50 lines. I'm sure I could make that much shorter doing it manually. Granted, a project like this has to start somewhere, but as it stands it's adding a lot of infrastructure without adding enough value to make it worth it, when AI is pretty good at these really basic things, like "give me a text box with a button to increment it".
I don't have to use a web browser; I want to use a web browser. I'm not in the US, so almost nobody I know uses an iPhone, and I could easily send them APKs, but why go through the trouble?
"A hand-sized touchscreen is too small for editing Scrapps comfortably"
I would encourage them not to underestimate the tenacity of mobile phone users!
For a lot of people these days their mobile phone is their only digital computing device. People write code on mobile phones. People write entire novels.
I think this tool's impact could be greatly increased by taking the time to figure out a mobile editing interface, even one that feels less comfortable than the desktop experience.
Also iPhone is not just a US thing. I’m in Germany and iPhone is very popular here too
View your friend's apps, use your friend's apps, remix your friend's apps to suit your needs.
But it needs to be all-in on speech. End-to-end abstracts away the concept of code. Speech-to-App.
In regards to this question about the "Scrappy backend": Scrappy is local-first, so data is stored locally in your browser, and optionally replicated to a lightweight sync server, to help coordinate syncing between peers. In other words, Scrappy is almost entirely front-end. The only third-party dependencies are Yjs <https://yjs.dev/> and CodeMirror <https://codemirror.net/>. We don’t use any other libraries or frameworks like React. There’s no analytics.
And there's no traditional backend. The only cloud dependency is the sync server, which is a plain vanilla y-websocket-server <https://github.com/yjs/y-websocket-server/>.
https://macosxautomation.com/applescript/develop/index.html
seems to show the current state, which is a heavy lift for most people.
Building a whole platform around self-replicating HTML-files with optional backend-access seems to be the more reliable solution for small personalized stuff. At least it has a strong resilience.
The cool thing is each HTML file is able to modify/overwrite itself, so users can use the app's own UI to modify it (e.g. a dashboard where users can add new fields by clicking a button to clone a DOM node, everything's persisted).
The key insight: collapsing the UI/state/logic layers into a single self-contained HTML file eliminates entire categories of complexity - no build steps, no deployment, no state synchronization. Everything you need is just right there.
https://news.ycombinator.com/item?id=44216943
and my thanks to you for mentioning it --- that it has a desktop app is _huge_.
i either have to: - make something browser-based, register a domain, and then pay somebody to host it. that's a lot of hoops (and unnecessary cost) just to access a little script that's just fine running locally. - make some sort of official developer account[0] for an app store and then jump through hoops to get my app approved. this would let me make a little app that runs locally, but it's even MORE hoops to jump through and it puts you on the hook for support because it's a wide public release instead of just sharing with a couple friends.
[0] tbh, I don't know how this works. I just hear mobile devs complaining about submitting apps for review and know it can be slow and frustrating.
It's a fully client-side Python IDE with single-stepping, a virtual (non-hierarchical) filesystem, an FFI to call JS code and a few other things (see the docs). Sharing apps in CodeBoot is trivial: right-click the "play" button and copy a shareable URL. I have helped people solve data wrangling problems using CodeBoot and they now have their little app bookmarked. It works really well.
I could go on for a while. AMA if you're interested. We're actively working on it and some great new features are on the way!
I'd be very glad to see a platform for the Raspberry Pi (and similar devices) which would simultaneously be simple and easy for folks to access and use _and_ create the kind of sophisticated user interfaces folks are now accustomed to/expect to use for even basic tasks.
The key difference is when you want to share your creation on the web. With TiddlyWiki, you typically share a read-only version, requiring visitors to download and save their own copy. With Hyperclay, you can host that same HTML file on any server and live-edit it directly in your browser (if you're the owner). When people clone it, their clone is shareable and available on the web.
So you get the best of both worlds: the simplicity of a single HTML file that "just works" offline, plus the ability to publish it as a living document that you can edit directly in the browser.
Think of it as TiddlyWiki's philosophy extended to the shared web. Same single-file simplicity, but now your changes can be seen by others.
Sorry but I'm having issues seeing this as a feature. TiddlyWikis can be shared as easily as sending an attachment. Running a server, tho, is not simple at all for the common user.
Depending on your tolerance for basic ai coding, you might enjoy openjam.ai
You can build silly stuff like this (better seen on desktop):
* https://openjam.ai/lonely_ant_702/bajbin4neo
https://www.goodreads.com/book/show/192405005-hypermedia-sys...
(and if not, are you aware of a book which touches on/explains your technique?)
Do you think a visual tool for this could be created? (something like Lazarus or Interface Builder or QT Designer...)
But in Hyperclay apps, the DOM is the source of truth -- there's nothing else. So there's no need for more than a single AJAX call (to save the page). HTMX is built to support a more traditional multi-page stack, whereas Hyperclay is built around single-file HTML apps.
The idea is that every HTML file is its own visual tool for modifying its own UI/data. For instance, you could build a page layout editor that lets users drag-and-drop components, and the editor itself would be part of the saved HTML file. An infinite variety of visual tools can (and will) be built on top of this structure.
As for essays about this vision, I'd recommend "Local-first software" [0] and "Malleable software" [1]
I know almost nothing about the underlying technologies, can barely code JS for the front end. But after about 10 hours of coding, I’ve got a very neat little app - it’s something that would have taken me 2 months then become abandonware after I got frustrated.
This was such a positive experience with vibe coding that it restored my love for code. Resulting quality seems pretty decent - maybe 1200 sLOC with good logging, performance, and what I would say is decent pro-am code quality. (IE above the median quality for typical commercial code, I’d bet)
by api you mean youtube api?
It really is a joy to program with, but we're struggling a bit to communicate everything it can do. We are working hard on that front and should have a landing page and better explanatory material soon. We're very interested in feedback. If anybody wants to learn more, just contact me through the email in my profile.
Cheers!
My use case was a home maintenance wiki/manual, the incredible benefits of something like TiddlyWiki in this use case is the ultimate survivability of it.
Open `HomeManual.html` in any browser and you can read it (and modify it!) and literally File -> Save As... `HomeManual-2025-07-18.html`. For more convenience: `rclone serve webdav` and the "(*) Save..." button works to save in place.
Ultimate survivability. Self-contained, it works on mobile, pairs great with SyncThing, devolves into read only, has a "normie-understandable" option for modifications.
Really, what I'd prefer is a bit less complexity of the wiki itself, and some slightly better integration between `exportAllPages("*.md")` and "AllTogether.html". I'd love to be able to pop open vim 90% of the time and somehow "merge things" as expected (conflict-aware, diff-ish integration).
Take a look at the use cases I've described and it'd be amazing to have a framework "Quine.html" (that can self-reproduce) that was less complicated than all the cruft that's built up in TiddlyWiki.
There's an enormous gap in complexity, required skill, etc between creating these Scrappy applications and building the whole app in React, and then getting it deployed, complete with real time syncing, authorization (as they've implemented with their "frames" and everything. It's at least an order of magnitude greater in effort.
> software, unlike a meal or a home-made sweater, comes with an implicit support contract that lasts forever
I don't think it always has to. It tends to be that way because so far, the lift to create a functioning cross-device multi user application has been high enough that the economics of it requires centralized teams of specialists to build an application for many hundreds of people.
If you lower the stakes really low to the point where the app is as serious as a spreadsheet, then compare it to spreadsheets. Almost everyone has dozens of really casual spreadsheets, many households have shared google sheets for particular, short-lived or casual or constantly changing use-cases. When you slap together a spreadsheet with your partner, you aren't making a promise about long term support and compatibility with the spreadsheet.
Or an other similar thing would just be paper and pen and tape, up on a whiteboard. All kinds of little "hand made" "applications" like this exist in households and in offices. Kanban boards are an example of this but there's and endless different kinds of "board-based physical apps" like chore charts and weekly meal plans. When someone writes on their fridge a list of chores and starts tallying who does what, that is not an eternal promise to maintain the piece of paper with chores and tally marks protocol/system.
The comments about being a SAAS, walled garden, and about the specific implementation here wrt where data's stored etc, this is just a prototype. A POC.
Modern computing badly needs the ability to support building our own local apps without a remote web server dependency. This is how computing worked in the pre-internet age. HyperCard could connect to a database as could Filemaker Pro. Windows had something similar where GUI-based apps could read/write to an Access DB. These tools have been deprecated and only live on in some subscription-based SaaS.
I know several people who do that - non-programmers - with formulas and VBA in Excel sheets.
Browsers are getting more and more aggressive about deleting cookies / making cookies ephemeral, and nothing is more annoying that dealing with one or multiple pop-ups on each page visit.
For an example of how bad it can get, load LMarena in a private window.
Cookie pop-up, agree > type something, press enter > ToS pop-up, agree > press enter again > processing > answer > type somethi- verify Cloudflare, agree > type something
One idea we had early on is the ability to save scrapps as single-page self-contained HTML files. We experimented with this but the functionality isn't currently exposed.
We used AI sparsely for wordsmithing and definitely not for generating the text. Believe me, putting it together was a lot of work (Pontus did the heavy lifting).
cd ~/html
php -S localhost:8000
We don't want to break the current experience but we need to do a better job of explaining what our software can do.
I appreciate your comments!
Scrappy feels like a digital sticky note. It is easy to make, easy to share, and kind of fun to use together. I am excited to try it out and see if it can become our little shared space for everyday stuff.
Otherwise really interesting, thanks for sharing!
I'm not arguing with you. You're arguing with me, and I'm not sure why. I don't give a shit about Apple. I'm not defending them, I don't care.
What's insane to me is that on the Internet, people constantly try to pick fights.
Godot uses a Python-like language instead of Lua, which is good for me. Lots of people groove with Lua, but it gives me the ick.
I did not get very far trying to make 3D or physics-based games with Godot 3. I did not like the 3D interface, and the physics engine was too brittle for e.g. a pinball simulation. Too much tunneling and other inconsistent behavior.
But for 2D applications that are a mixture of text and images, i find it fits the bill quite well.
(For 3D apps and physics, I currently use Unreal Engine 4. Some tunneling, but I know tricks to mitigate that, and I much prefer its 3D interface.)
redbean is an open source webserver in a single-file that runs natively on six OSes for both AMD64 and ARM64. Basic idea is if you want to build a web app that runs anywhere, then you download the redbean.com file, put your .html and .lua files inside it using the zip command, and you've got a hermetic app you deploy and share.
Seriously, if you haven't, go check out the "zen" of tiddlywiki: https://tiddlywiki.com/#GettingStarted
You download "blank.html", make changes, then save it as "mine.html" and you're off to the races. It's pretty wild!
i am one.
;)