CardStock[0] isn’t mentioned in this article, but seems broadly similar in goals and approach to Scrappy. Unlike Scrappy (so far as I can tell) CardStock is open-source and can be run locally.[1]
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".
I like the spirit of it, but the execution isn't what I'm looking for. With this being a hosted solution, it makes me dependent on another SaaS tool for little personal projects. If it's a little counter needed for an afternoon, that's not such a big deal. However, if I'm looking for a scrappy little app I may use for years, this is a problem. Plus, no matter how low the learning curve gets, it will still exist, so I want something that I can use for the long term for things like this. This makes my mind go to approachable and easy languages that allow the user to easily throw a GUI on it. I don't think code needs to be completely abstracted away, just made easy and tailored to what people will do. Look at how many people on MySpace were able to learn some CSS. Maybe they copy and paste someone else's stuff at first, but that's the foot in the door before they eventually look at how to tweak it.
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.
This looks like something that should be done like a TiddlyWiki. A TiddlyWiki is a whole Webapplication in a single HTML-File. Traditionally, when you change something, you just save the HTML-File and it self-replicates with the new data. There are now also TiddlyWikis which can save to backends and probably some other ways.
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.
I'm building a self-modifying HTML runtime inspired by TiddlyWiki [0]. It lets you build "HTML apps" in a single file with plain CSS/JS.
These apps are shareable and hostable, but you can also download and use them locally as offline apps [1].
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.
It looks cool. Two quick things:
- the pricing page is an unstyled 404 right now
- the docs subdomain requires javascript to display at all which is fine I guess but odd because the examples are viewable without javascript enabled
Yes, there's definitely philosophical alignment with the hypermedia approach: keeping things simple and leveraging HTML's native capabilities. In fact, I use hypermedia-oriented techniques on all the dashboard pages in the Hyperclay web app.
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'm a little experienced with TiddlyWiki, from memory: `rclone serve webdav` in the directory with TiddlyWiki will let you "write in place".
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.
No app installation needed, Hyperclay files are just HTML files, so they work like TiddlyWiki in that regard. You can download them and use them locally with any text editor, or even implement TiddlyWiki's saving mechanism if you prefer that workflow.
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.
> Think of it as TiddlyWiki's philosophy extended to the shared web.
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.
Apps need a local server to work (especially if it writes to a local database), or be shipped in some kind of executable file format for the OS. As someone who can't code native apps but is decent enough in PHP, I've discovered that the way to solve my own problem is to run a bash script that loads an Apache server, then loads the index.php file of my app, all of which is stored locally on my hard drive. Works on mobile too, although I have to manually launch an Apache server first through termux.
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.
Decker works like TiddlyWiki. I agree that a fully decentralized self-replicating approach is the ideal way to distribute this type of application/tool; even very restrictive environments would permit using and sharing single-file apps that run in a web browser.
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!
Really glad you appreciate! We use it to teach introductory programing courses and the simplistic UI is purpose-built for that use-case.
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.
Instead of a landing page, may I suggest a '?' button, or at least putting the landing page on https://codeboot.org/something and redirecting from referrers but not direct loads?
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
Other than that I don't have much comments yet except that it seems a nice product!
It seems the way to go would be to open source the SaaS code to ensure that longevity. The folks at Penpot have a good thing going with that—most people will use the SaaS offering but it’s available for self-hosting.
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!
I was also thinking back to when I used TiddlyWiki almost 20 years ago. If this tool is effectively just HTML, CSS, and Javascript... could they bake it all into a single HTML file. Download a template, design your app offline, and save your work to a file that can run on its own, offline, in a browser window. Maybe the about of JS they need to bake in, or images, would make that impractical.
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".
Vibe coding may get the job done, but it isn't going to be as fun for someone who wants to write a little app for a friend. Also, chances are that the generated code is going to be less friendly for a novice to edit should the want/need to make changes.
I use Cursor and vibe code this stuff, it works great! I just built a flight tracker (I live in a flight path) that uses a SDR to receive ADS-B info from overhead flights and enrich it with flight info from the local airport, then display in a train station style flippy board. My wife loves knowing where the flights are going and so I display on our magic mirror
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)
Scrappy co-creator here. I fully agree that software longevity is important. We designed Scrappy with a local-first architecture, so we have no traditional backend. Our only cloud dependency is a lightweight sync server. (We hurriedly added an FAQ with some more technical details after we discovered that this blew up on HN.) I believe this is an important point of distinction, both technically and financially, from most low-code/no-code tools which are SaaS'es.
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.
Being able to download a self-contained html file would be great. Not only for longevity, but also for situations where internet access may be questionable.
One of the best things that I did was spending a week making a simple app that can put all my Apple Watch walks on a single big map, then sharing it with my friends after it got published on AppStore. It's been a year since I worked on it, but I still get messages from my friends (and some random people who found it!) how they've walked through an entire city or something. Really rewarding experience, despite having zero financial gains from it.
OP is right, making simple apps for your friends for fun!
Here you go — https://apps.apple.com/us/app/mapcut/id6478268682. It’s really not supposed to be super nice, but good enough to have some active users. It’s free, so have fun! Sorry for putting it behind auth gates, I was experimenting with some other features that required webservers running.
Not the OPs app but there's an app doing something similar that I enjoyed for many years, you can also import from GPS trackers and others: https://fogofworld.app
Just think about the thousands of useless obstacles and moats you’ve had to navigate and overcome to make that. How many millions have given up at any one of them.
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.
Fair point, but as I grew up, I realized those things really don’t matter to me. My thought process was — oh, I walk around a lot, I’m curious how much of the city I’ve covered -> oh, there’s no free app for that -> oh, I’ve never made an iOS app and this looks simple -> let’s spend a week making it and share it with friends.
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.
Help build the world you want to see! It will take folks passionately trying to make this open, free, unmonetized vision a reality in competition with the walled gardens you're decrying. I wish you luck if you give it a go!
It looks like getting the apps built with this to work well on mobile is in the roadmap, but not mobile editing itself:
"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.
I think "vibe coding" will not replace developers in the short term, but it will be the strongest competition for such simple systems. I asked a few LLMs to make apps like these (plain HTML with embedded JS), and they got it right after a few edits. They are also visually more appealing [1].
I am vibe coding a hobby project to find out what's the state of things.
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.
Whats your simple system stack, preferably self hostable? I may choose Vue, need auth, a multiplayer offline DB, static hosting, file hosting and preferably filter rows by users (dont allow me to see others data if I fiddle with the api).
If you can get over the critical errors. That's the showstopper for most non-programmers. Perhaps not as much for the so-called "power users" who can hack together some Excel VBA, but even then there's a lot of setup to get simple projects rolling. Down to the little things like knowing that a .js file is a JavaScript file (and what that means). It's obvious to us, but definitely not to the average person, unless they're willing to invest significant time into it - which most aren't.
I feel we are coming at this as programmers, and the opportunity is the community aspect. What about starting with the family run app stores? Masterson style.
No security (you're all friends right) and no way to contribute without an invite. Just a thought.
"We believe computers should work for people, and dream of a future where computing, like cooking or word processing, is available to everyone."
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.
> "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.
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.
Scrappy co-creator here. As an old-school Mac user (from the days of desktop publishing) I do know the difference between hyphen and en-dash and em-dash :)
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).
I am 100% behind the idea of "scriptable components" vs block-based programming for beginners.
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).
Except the OS has no web server, so you have to find and install one, make sure it auto starts, set up port forwarding (which you might not be able to if you're behind CGNAT or your ISP just doesn't let you)... Then you need to explain to your partner that your computer is running 24/7 to host your shared shopping list or whatever, which will definitely cost more in electricity than a 5$/mo VPS, which was already presumed to be unacceptable
So you drag UI elements onto an empty sheet, fight with the grid snap (because it doesn't match the size of your UI elements) and are then supposed to enter raw JavaScript, without any code completion, visual programming, API help or AI support? And that's it?
An alternative to Scrappy is the free CodeBoot web app (https://codeboot.org), which allows you to create web apps in Python that are fully encapsulated in a URL. No installation is required—neither for the developer nor the user. Below is an example of a math practice app with simple user interaction through dialogs. To create a web app URL, right-click the "play" button and choose the type of link you want to generate.
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.
You can make an awful lot of useful little tools with an LLM, vanilla JavaScript, GitHub Pages, and the user's own localStorage as a semi-persistence layer. Two 9s and cross-platform to boot.
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.
+1 over this. As someone without a deep technical background, LLMs enabled me to improve my life unimaginably, being able to quickly sketch and develop small features that remove every day annoyance.
My very first thing was automation of placing my journal entry to appropriate Google Drive folder. I write my brain dump/journal everyday in Google Docs, and if I just click "New document, it places it in the root GDrive folder, and I had to move it manually which I am to lazy to do it.
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
I came here to say exactly this. You can even set up build steps using GitHub Actions if you prefer something beyond vanilla JS, or publish the project for free on Cloudflare, even from private repositories. In addition to localStorage, IndexedDB is also very useful. It's easy to export the app’s data as JSON for better persistence, and you could store it on Google Drive or a similar service.
The main caveat is that you have to enable developer mode on the Android device to load the apps, but that is typical if you are running your own apps.
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.)
I really love these kinds of little tools you build just for friends. They are simple but perfect for things like habit tracking, polls, or quick reminders.
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.
> You drag objects out on the canvas — a button, a textfield, a few labels. Select an object, and you can modify its attribute in an inspector panel. Certain objects, like buttons, has attributes like “when clicked” that contain javascript code.
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.
Google Studio IO apps seems like a step in the same direction. Now if only we could host it on github and take advantage of static github pages.
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.
This is what UI programming should be like. I don't know why we've deviated from developing tools like these in favor of brain-breaking labor work of writing React applications.
Built something like this 8 years ago for hospital in Israel doctors to have simple formula calculator - it was super helpful but I never got to productise it, Love this!
> All Scrappy apps are multiplayer, like a Google Doc is. You can even edit them while they are being used by someone else!
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
Scrappy co-creator here. It was a surprise to us that this blew up on HN. We've hurriedly added an FAQ to the write-up.
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/>.
I love the concept. I think the trick to being successful with a project like this is cracking the user experience in a way that makes it powerful enough to be truly useful, while keeping it simple enough that a child can build (scr)apps (c.f. Super Mario Maker).
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.
Nice, I am in the process of building one with a similar concept but in a single HTML/JS file. Sharing with friends and multi-user. Might release it in a week or two as I am getting closer to put final finishing touches. Not sure if I have to go open source or closed and Freemium. Might ask HN later :)
Although I like the idea in principal, I don't see the real use case here.
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 often create small apps like these for my friends, but 100% of them are written in PHP and plain HTML with some JavaScript. They need to be built quickly, deployed quickly, updated quickly, run on every device, and be runnable by sending a link on WhatsApp.
So it doesn't matter what Apple does because I'm never going to put something like that into any App Store.
Well the reason why you are having to use a web browser rather than sharing the app written using native APIs is because Apple forces you to use the App Store, so you yes did matter what Apple does. They prevent you from using the native toolkit and your use of the browser is partly a workaround for that
EDIT also Apple are in full control of what functionality they expose in their web APIs so even then it matters hugely
> Well the reason why you are having to use a web browser
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?
I mean that’s fine but then you can’t use a huge number of system APIs so it is actually a problem if you want to write software that uses your phones features. It is not okay just because iPhones or androids have a web browser. It’s insane to me that you’re even trying to argue that it’s not a problem that Apple do not let you write native software for iOS for free
Also iPhone is not just a US thing. I’m in Germany and iPhone is very popular here too
Yeah a YouTube video on HyperCard made me realise that Apple just doesn’t care anymore and honestly neither do people, but I honestly think it is brainwashing. If you let people make their own apps then how do you serve them ads and take the 30% revenue cut?
That's an excellent point, that enabling app development by users reduces the monetization potential --- but maybe it's something which would work for opensource?
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.
iPhone Shortcuts can get you surprisingly far. I agree that building hobbyist apps has too high of an entry barrier in the Apple ecosystem but Shortcuts handles CRUD stuff with ease.
I was going to call this "a less-feature rich Delphi without Borland's corporate greed", but then I noticed that Delphi is apparently still alive (somehow?). Delphi was one of my earliest programming experiences in the 90s. Blast from the past.
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?
The core vision here is something I can absolutely get on board with, but the execution fundamentally seems to misunderstand why "home-cooked software" doesn't exist.
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.
> they're building a product for people who can write JavaScript event handlers but somehow can't 'npx create-react-app'
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.
i'd argue that the biggest hurdle to home cooked software is finding a way to distribute/deploy it among your friends. im a backend guy and can easily make a useful li'l executable to run on my work machine. but how do i share that with people that will only use their smartphone for computing?
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.
The easiest I can think of is making a spreadsheet. Share an Excel file over OneDrive or even a Google Sheet. The built-in features/formulas are enough for most of these use cases; if you want to go further, there's VBA (and the nightmare that comes with it - but it's less of a nightmare than paying and setting up a domain and dealing with the security of that).
I know several people who do that - non-programmers - with formulas and VBA in Excel sheets.
Very nice. For me, LLM fills that niche when I need to build something very small. Just built a dumb tiny flashcard webapp (literally a standalone index.html) because I was tired of apps either being either overly complex for my simple use case, or asking me to register/pay/see ads.
It would be nice if we could be successful at doing so, and extend it into the modern world (I asked after it a while back, and this was one of the tools which was suggested). Elsethread, https://cardstock.run/ was mentioned which looks quite promising as well. Curious if any others (which I've not found despite searching) will turn up.
I agree with the title, but not with the article. I expected to see something like how you can make your friends and family lives easier using your skills as a software developer.
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.
Same thing here, one of my first open source projects was to read a public Google sheet to pull the data, both from the frontend and backend. While Google killed the api that made it possible so I deprecated it, it still holds a precious place in my memories as one of the most collaborative projects I've ever made
CardStock[0] isn’t mentioned in this article, but seems broadly similar in goals and approach to Scrappy. Unlike Scrappy (so far as I can tell) CardStock is open-source and can be run locally.[1]
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".
[0] https://cardstock.run
[1] https://github.com/benjie-git/CardStock
[2] http://beyondloom.com/decker/index.html
I've been looking for such a tool for a while now:
https://news.ycombinator.com/item?id=44216943
and my thanks to you for mentioning it --- that it has a desktop app is _huge_.
I like the spirit of it, but the execution isn't what I'm looking for. With this being a hosted solution, it makes me dependent on another SaaS tool for little personal projects. If it's a little counter needed for an afternoon, that's not such a big deal. However, if I'm looking for a scrappy little app I may use for years, this is a problem. Plus, no matter how low the learning curve gets, it will still exist, so I want something that I can use for the long term for things like this. This makes my mind go to approachable and easy languages that allow the user to easily throw a GUI on it. I don't think code needs to be completely abstracted away, just made easy and tailored to what people will do. Look at how many people on MySpace were able to learn some CSS. Maybe they copy and paste someone else's stuff at first, but that's the foot in the door before they eventually look at how to tweak it.
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.
This looks like something that should be done like a TiddlyWiki. A TiddlyWiki is a whole Webapplication in a single HTML-File. Traditionally, when you change something, you just save the HTML-File and it self-replicates with the new data. There are now also TiddlyWikis which can save to backends and probably some other ways.
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.
I'm building a self-modifying HTML runtime inspired by TiddlyWiki [0]. It lets you build "HTML apps" in a single file with plain CSS/JS. These apps are shareable and hostable, but you can also download and use them locally as offline apps [1].
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.
[0] https://hyperclay.com/
[1] https://hyperclay.com/hyperclay-local
It looks cool. Two quick things: - the pricing page is an unstyled 404 right now - the docs subdomain requires javascript to display at all which is fine I guess but odd because the examples are viewable without javascript enabled
Otherwise really interesting, thanks for sharing!
This looks _very_ cool --- does it align with:
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...)
Yes, there's definitely philosophical alignment with the hypermedia approach: keeping things simple and leveraging HTML's native capabilities. In fact, I use hypermedia-oriented techniques on all the dashboard pages in the Hyperclay web app.
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]
[0] https://www.inkandswitch.com/essay/local-first/
[1] https://www.inkandswitch.com/malleable-software/
I'm a little experienced with TiddlyWiki, from memory: `rclone serve webdav` in the directory with TiddlyWiki will let you "write in place".
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.
Hyperclay is quite interesting, well done! But to use it we need to install an app? I think the UX of tiddlywiki that just work is better
No app installation needed, Hyperclay files are just HTML files, so they work like TiddlyWiki in that regard. You can download them and use them locally with any text editor, or even implement TiddlyWiki's saving mechanism if you prefer that workflow.
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.
> Think of it as TiddlyWiki's philosophy extended to the shared web.
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.
Apps need a local server to work (especially if it writes to a local database), or be shipped in some kind of executable file format for the OS. As someone who can't code native apps but is decent enough in PHP, I've discovered that the way to solve my own problem is to run a bash script that loads an Apache server, then loads the index.php file of my app, all of which is stored locally on my hard drive. Works on mobile too, although I have to manually launch an Apache server first through termux.
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.
PHP has its own built-in web server for local dev and testing. I tend to just use that when I need it.
cd ~/html
php -S localhost:8000
Decker works like TiddlyWiki. I agree that a fully decentralized self-replicating approach is the ideal way to distribute this type of application/tool; even very restrictive environments would permit using and sharing single-file apps that run in a web browser.
You should check out https://codeboot.org .
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!
Can I just say I adore the absolute utility of the UX and UI?
No welcome screen, just dropped straight into the main interface which itself has no excess buttons or styling wasted on it.
To me this is beautiful.
Really glad you appreciate! We use it to teach introductory programing courses and the simplistic UI is purpose-built for that use-case.
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!
Instead of a landing page, may I suggest a '?' button, or at least putting the landing page on https://codeboot.org/something and redirecting from referrers but not direct loads?
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.
Other than that I don't have much comments yet except that it seems a nice product!We are thinking about using two domains: codeboot.org for "company" things, and codeboot.app for the actual IDE and user applications. Or vice-versa.
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!
It seems the way to go would be to open source the SaaS code to ensure that longevity. The folks at Penpot have a good thing going with that—most people will use the SaaS offering but it’s available for self-hosting.
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/
[2]: https://www.lexaloffle.com/pico-8.php
I was also thinking back to when I used TiddlyWiki almost 20 years ago. If this tool is effectively just HTML, CSS, and Javascript... could they bake it all into a single HTML file. Download a template, design your app offline, and save your work to a file that can run on its own, offline, in a browser window. Maybe the about of JS they need to bake in, or images, would make that impractical.
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".
Vibe coding may get the job done, but it isn't going to be as fun for someone who wants to write a little app for a friend. Also, chances are that the generated code is going to be less friendly for a novice to edit should the want/need to make changes.
I use Cursor and vibe code this stuff, it works great! I just built a flight tracker (I live in a flight path) that uses a SDR to receive ADS-B info from overhead flights and enrich it with flight info from the local airport, then display in a train station style flippy board. My wife loves knowing where the flights are going and so I display on our magic mirror
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)
Scrappy co-creator here. I fully agree that software longevity is important. We designed Scrappy with a local-first architecture, so we have no traditional backend. Our only cloud dependency is a lightweight sync server. (We hurriedly added an FAQ with some more technical details after we discovered that this blew up on HN.) I believe this is an important point of distinction, both technically and financially, from most low-code/no-code tools which are SaaS'es.
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.
Being able to download a self-contained html file would be great. Not only for longevity, but also for situations where internet access may be questionable.
> I typically end up using basic HTML/CSS/JS for stuff like this today
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://openjam.ai/stupid_coral_852/qg8yembjg5
* https://openjam.ai/stupid_coral_852/y2hj69iqvo
One of the best things that I did was spending a week making a simple app that can put all my Apple Watch walks on a single big map, then sharing it with my friends after it got published on AppStore. It's been a year since I worked on it, but I still get messages from my friends (and some random people who found it!) how they've walked through an entire city or something. Really rewarding experience, despite having zero financial gains from it.
OP is right, making simple apps for your friends for fun!
Wow I’ve had this idea in my pocket for a long time, thanks for making it real!
This sounds great, could you link the app please?
Here you go — https://apps.apple.com/us/app/mapcut/id6478268682. It’s really not supposed to be super nice, but good enough to have some active users. It’s free, so have fun! Sorry for putting it behind auth gates, I was experimenting with some other features that required webservers running.
Not the OPs app but there's an app doing something similar that I enjoyed for many years, you can also import from GPS trackers and others: https://fogofworld.app
I use https://wandrer.earth/ , connected to Strava
Does that work like a game map where the fog disappears where you have been? That would be cool, although the reviews aren't great.
Yea that’s the idea. Worked well for the years where I tried it.
Not OP, but https://dawarich.app/ seems to do the same (open source and self-hostable, also has an iOS App).
Just think about the thousands of useless obstacles and moats you’ve had to navigate and overcome to make that. How many millions have given up at any one of them.
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.
Fair point, but as I grew up, I realized those things really don’t matter to me. My thought process was — oh, I walk around a lot, I’m curious how much of the city I’ve covered -> oh, there’s no free app for that -> oh, I’ve never made an iOS app and this looks simple -> let’s spend a week making it and share it with friends.
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.
Help build the world you want to see! It will take folks passionately trying to make this open, free, unmonetized vision a reality in competition with the walled gardens you're decrying. I wish you luck if you give it a go!
It looks like getting the apps built with this to work well on mobile is in the roadmap, but not mobile editing itself:
"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.
It's nice but I've yet to see a more usable end-user programming environment than the spreadsheet.
For an implementation which pushes that to the extreme see:
https://pyspread.gitlab.io/
No tests, no version control, no library support. Pass for me.
You're making the argument that end-user programming must have the same priorities as professional software development.
Or learning to actually code. I can't see why I would ever learn to use these kinds of tools.
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?
I think "vibe coding" will not replace developers in the short term, but it will be the strongest competition for such simple systems. I asked a few LLMs to make apps like these (plain HTML with embedded JS), and they got it right after a few edits. They are also visually more appealing [1].
[1] https://claude.ai/public/artifacts/bb451732-9559-401a-8000-b...
I am vibe coding a hobby project to find out what's the state of things.
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.
It's got a bug, if you enter a non-integer like 3 + 2 = 5.1 then it marks that as correct
You are right. They are the natural opponents of vibe coding. vibe coding is from a funny X post; this is the OG purpose.
Whats your simple system stack, preferably self hostable? I may choose Vue, need auth, a multiplayer offline DB, static hosting, file hosting and preferably filter rows by users (dont allow me to see others data if I fiddle with the api).
I would change the ? to a blank or underscore
except it's broken
Vibe coding seems to be synonymous with "sort of works, bunch of bugs"
If you can get over the critical errors. That's the showstopper for most non-programmers. Perhaps not as much for the so-called "power users" who can hack together some Excel VBA, but even then there's a lot of setup to get simple projects rolling. Down to the little things like knowing that a .js file is a JavaScript file (and what that means). It's obvious to us, but definitely not to the average person, unless they're willing to invest significant time into it - which most aren't.
love the Comic Sans in here
I feel we are coming at this as programmers, and the opportunity is the community aspect. What about starting with the family run app stores? Masterson style. No security (you're all friends right) and no way to contribute without an invite. Just a thought.
"We believe computers should work for people, and dream of a future where computing, like cooking or word processing, is available to everyone."
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.
> "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.
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.
If you read up on hyphens VS en-dashes VS em-dashes, using em-dashes is actually the correct usage — as a separator — in the case you cited.
I disagree with your conclusion of this being a telltale sign of being AI generated.
Scrappy co-creator here. As an old-school Mac user (from the days of desktop publishing) I do know the difference between hyphen and en-dash and em-dash :)
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).
To type an em dash, an important punctuation mark, press compose and then hyphen thrice. — ←like this. Shift-option-hyphen on Macs, I think.
I am 100% behind the idea of "scriptable components" vs block-based programming for beginners.
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).
You could self host with your OS’s web server and a dynamic DNS service pointing to your home computer.
Except the OS has no web server, so you have to find and install one, make sure it auto starts, set up port forwarding (which you might not be able to if you're behind CGNAT or your ISP just doesn't let you)... Then you need to explain to your partner that your computer is running 24/7 to host your shared shopping list or whatever, which will definitely cost more in electricity than a 5$/mo VPS, which was already presumed to be unacceptable
"... my wife or kids " you already lost them at "... self host"
GP was suggesting that you would self-host for your wife and kids, not that they would self-host themselves.
Sadly, free hosting or distribution for fun ideas like this one leads to bad actors abusing the service.
So you drag UI elements onto an empty sheet, fight with the grid snap (because it doesn't match the size of your UI elements) and are then supposed to enter raw JavaScript, without any code completion, visual programming, API help or AI support? And that's it?
An alternative to Scrappy is the free CodeBoot web app (https://codeboot.org), which allows you to create web apps in Python that are fully encapsulated in a URL. No installation is required—neither for the developer nor the user. Below is an example of a math practice app with simple user interaction through dialogs. To create a web app URL, right-click the "play" button and choose the type of link you want to generate.
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...
I think it's a great demo, it is interesting how harsh the feedback is that you are getting. You are probably just too late to the party.
I also work in this space and the road ahead gets exponentially harder, unfortunately.
You can make an awful lot of useful little tools with an LLM, vanilla JavaScript, GitHub Pages, and the user's own localStorage as a semi-persistence layer. Two 9s and cross-platform to boot.
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.
[1]: https://hiandrewquinn.github.io/diet-checklist/
+1 over this. As someone without a deep technical background, LLMs enabled me to improve my life unimaginably, being able to quickly sketch and develop small features that remove every day annoyance.
examples?
My very first thing was automation of placing my journal entry to appropriate Google Drive folder. I write my brain dump/journal everyday in Google Docs, and if I just click "New document, it places it in the root GDrive folder, and I had to move it manually which I am to lazy to do it.
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
sounds like some cool automations, thanks.
by api you mean youtube api?
In this particular case I call a commercial api by supdata
And I use youtube api to extract metadata of the video(s)
I came here to say exactly this. You can even set up build steps using GitHub Actions if you prefer something beyond vanilla JS, or publish the project for free on Cloudflare, even from private repositories. In addition to localStorage, IndexedDB is also very useful. It's easy to export the app’s data as JSON for better persistence, and you could store it on Google Drive or a similar service.
This reminds me a lot of Visual Basic! Same simple principles and quite similar UI.
Cool but no link for the source code negates entire point of sharing apps.
It absolutely doesn't.
Godot 3 and 4 are very good for bashing out apps for both desktop and Android phone.
I've been thinking about using Godot in this way recently, would you care to say more about what your experience has been like?
The main caveat is that you have to enable developer mode on the Android device to load the apps, but that is typical if you are running your own apps.
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.)
I really love these kinds of little tools you build just for friends. They are simple but perfect for things like habit tracking, polls, or quick reminders.
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.
> You drag objects out on the canvas — a button, a textfield, a few labels. Select an object, and you can modify its attribute in an inspector panel. Certain objects, like buttons, has attributes like “when clicked” that contain javascript code.
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.
Google Studio IO apps seems like a step in the same direction. Now if only we could host it on github and take advantage of static github pages.
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.
This is what UI programming should be like. I don't know why we've deviated from developing tools like these in favor of brain-breaking labor work of writing React applications.
Yes!
Built something like this 8 years ago for hospital in Israel doctors to have simple formula calculator - it was super helpful but I never got to productise it, Love this!
> All Scrappy apps are multiplayer, like a Google Doc is. You can even edit them while they are being used by someone else!
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.
Scrappy co-creator here. It was a surprise to us that this blew up on HN. We've hurriedly added an FAQ to the write-up.
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/>.
Just an anecdote
I remember learning this thing called Touch Develop by MS
Then I realized that was a closed environment/learned to program with programming languages instead, dumped a few months into TD
I love the concept. I think the trick to being successful with a project like this is cracking the user experience in a way that makes it powerful enough to be truly useful, while keeping it simple enough that a child can build (scr)apps (c.f. Super Mario Maker).
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!
Nice, I am in the process of building one with a similar concept but in a single HTML/JS file. Sharing with friends and multi-user. Might release it in a week or two as I am getting closer to put final finishing touches. Not sure if I have to go open source or closed and Freemium. Might ask HN later :)
Although I like the idea in principal, I don't see the real use case here.
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 would if Apple didn’t put such tight restrictions against hobby app creation
I often create small apps like these for my friends, but 100% of them are written in PHP and plain HTML with some JavaScript. They need to be built quickly, deployed quickly, updated quickly, run on every device, and be runnable by sending a link on WhatsApp.
So it doesn't matter what Apple does because I'm never going to put something like that into any App Store.
Well the reason why you are having to use a web browser rather than sharing the app written using native APIs is because Apple forces you to use the App Store, so you yes did matter what Apple does. They prevent you from using the native toolkit and your use of the browser is partly a workaround for that
EDIT also Apple are in full control of what functionality they expose in their web APIs so even then it matters hugely
> Well the reason why you are having to use a web browser
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?
I mean that’s fine but then you can’t use a huge number of system APIs so it is actually a problem if you want to write software that uses your phones features. It is not okay just because iPhones or androids have a web browser. It’s insane to me that you’re even trying to argue that it’s not a problem that Apple do not let you write native software for iOS for free
Also iPhone is not just a US thing. I’m in Germany and iPhone is very popular here too
>It’s insane to me that you’re even trying to argue
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.
I had great hopes for Applescript Studio, and was very hopeful it would grow into a widely-used HyperCard alternative.
https://macosxautomation.com/applescript/develop/index.html
seems to show the current state, which is a heavy lift for most people.
Yeah a YouTube video on HyperCard made me realise that Apple just doesn’t care anymore and honestly neither do people, but I honestly think it is brainwashing. If you let people make their own apps then how do you serve them ads and take the 30% revenue cut?
That's an excellent point, that enabling app development by users reduces the monetization potential --- but maybe it's something which would work for opensource?
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.
iPhone Shortcuts can get you surprisingly far. I agree that building hobbyist apps has too high of an entry barrier in the Apple ecosystem but Shortcuts handles CRUD stuff with ease.
Hypercard vibes
So, just like Delphi?
(I wonder if somebody ported Delphi / Lazarus to WASM)
Seems like it: https://wiki.freepascal.org/WebAssembly/Compiler
I was going to call this "a less-feature rich Delphi without Borland's corporate greed", but then I noticed that Delphi is apparently still alive (somehow?). Delphi was one of my earliest programming experiences in the 90s. Blast from the past.
Yes, it is still alive, it still works great, and if you want something open source, there's Lazarus which is nearly as good.
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?
Where does the data go?
Reminds me of VB6, which was amazing.
I guess this fits into the Google Forms, SharePoint space?
Just trying this out and it appears in Firefox, the drag & drop handle on new elements doesn't cover the whole rectangle, just the label.
I used to use MSHTA with success even though not cross platform - that would be the killer feature
Oh haha, I simply program little apps for my friends to solve their problems. I thought this would be about that
I'd love if this turns into a social platform for apps. Facebook has text, Instagram has images, TikTok has video... Scrappy has apps. Apps. Not code.
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.
The core vision here is something I can absolutely get on board with, but the execution fundamentally seems to misunderstand why "home-cooked software" doesn't exist.
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.
> they're building a product for people who can write JavaScript event handlers but somehow can't 'npx create-react-app'
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.
i'd argue that the biggest hurdle to home cooked software is finding a way to distribute/deploy it among your friends. im a backend guy and can easily make a useful li'l executable to run on my work machine. but how do i share that with people that will only use their smartphone for computing?
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.
The easiest I can think of is making a spreadsheet. Share an Excel file over OneDrive or even a Google Sheet. The built-in features/formulas are enough for most of these use cases; if you want to go further, there's VBA (and the nightmare that comes with it - but it's less of a nightmare than paying and setting up a domain and dealing with the security of that).
I know several people who do that - non-programmers - with formulas and VBA in Excel sheets.
Very nice. For me, LLM fills that niche when I need to build something very small. Just built a dumb tiny flashcard webapp (literally a standalone index.html) because I was tired of apps either being either overly complex for my simple use case, or asking me to register/pay/see ads.
Swap JavaScript with VBA and this is the MS Access workflow.
1. Start up the app 2. Try dragging a block 3. Doesn't work
_nice_
Ok do this apps run on IOS?
I don't have friends so this has no use for me
you could build things for yourself and share them here
A very good idea.
See also: https://www.robinsloan.com/notes/home-cooked-app/
This is just crying out for AI to help you get started.
I use AI for getting started in everything nowadays.
We're just gonna keep re-inventing HyperCard.
It would be nice if we could be successful at doing so, and extend it into the modern world (I asked after it a while back, and this was one of the tools which was suggested). Elsethread, https://cardstock.run/ was mentioned which looks quite promising as well. Curious if any others (which I've not found despite searching) will turn up.
Yes, until we get it right.
I love this.
good
I agree with the title, but not with the article. I expected to see something like how you can make your friends and family lives easier using your skills as a software developer.
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.
Same thing here, one of my first open source projects was to read a public Google sheet to pull the data, both from the frontend and backend. While Google killed the api that made it possible so I deprecated it, it still holds a precious place in my memories as one of the most collaborative projects I've ever made
[dead]
[dead]