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.
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!
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.
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 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".
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).
"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 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.
Readit News
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
https://news.ycombinator.com/item?id=44216943
and my thanks to you for mentioning it --- that it has a desktop app is _huge_.
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.
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!
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.
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.
[0] https://hyperclay.com/
[1] https://hyperclay.com/hyperclay-local
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.
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
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 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)
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.
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
OP is right, making simple apps for your friends for fun!
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.
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.
"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.
[1] https://claude.ai/public/artifacts/bb451732-9559-401a-8000-b...
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.
https://pyspread.gitlab.io/
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?
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.
I disagree with your conclusion of this being a telltale sign of being AI generated.
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).