Forge - app for iOS

[steve]

I wanted to share a preview of this year’s festive time product exploration, something that’s become somewhat of a welcome habit.

It started as simply a faster, simpler way for me to see my Forge projects and sites.

Check the site status, latest version, navigate to a site and click around while on the move.

At the same time, I was inspired by this article by Simon Willison where he talks about his journey in creating many (150!) small single file HTML tools.

This was an itch I wanted to scratch. Simon gave a succinct overview of some of the constraints and workflow steps he used to create the tools that were most productive:

1. A single file: inline JavaScript and CSS in a single HTML file means the least hassle in hosting or distributing them, and crucially means you can copy and paste them out of an LLM response.
2. Avoid React, or anything with a build step. The problem with React is that JSX requires a build step, which makes everything massively less convenient. I prompt “no react” and skip that whole rabbit hole entirely.
3. Load dependencies from a CDN. The fewer dependencies the better, but if there’s a well known library that helps solve a problem I’m happy to load it from CDNjs or jsdelivr or similar.
4. Keep them small. A few hundred lines means the maintainability of the code doesn’t matter too much: any good LLM can read them and understand what they’re doing, and rewriting them from scratch with help from an LLM takes just a few minutes.

The end result is a few hundred lines of code that can be cleanly copied and pasted into a GitHub repository.

I tried it myself, lying in bed one morning, using ChatGPT for code generation, copied and pasted into a Github Codespace and then linked the Github repo to my Forge site for continuous deployment. It worked, but Codespaces on mobile proved extremely clunky and the Git based workflow for this kind of casual usage was overkill.

I wondered, since I was working on a basic Forge iOS app, if I couldn’t make this drastically simpler.

So, I created a simple first workflow:

1. Select and site or create a new one in Forge iOS
2. Copy your code from ChatGPT code block to your clipboard
3. Come back to Forge and edit the code editor, pasting your code fully into the editor.
4. Hit “Deploy to Forge” and wait a second
5. Enjoy! Your site is live…

It works, it’s simple, it’s effective and every so slightly addictive. Of course, this is a crude representation of a happy path workflow - but in reality:

I enjoyed a creative ideation session in ChatGPT, researching the idea, turning it into code drafts, asking questions, making tweaks, exploring options. The final step was the deployment. This process was gold, because I’m really familiar with working with AI like this.

My first real test was at dinner that evening. My youngest son is a raving Disney lunatic. He likes to create quiz games that we play at the dinner table. But this day, I decided to turn the tables - by creating a Disney Quiz generator single file HTML mini tool there and then.

He was delighted, until he got a question wrong (he’s got my competitive streak). We’re on to something here, time from idea to impact was very short and clear…

I put the app on to Testflight and invited my 14 year old son to try it out. Of course, he got the general idea straight away, had a funny idea about making a mini game that dropped a brick on a flowerpot or something - random, but who am I to judge?

But while the general flow was simple and just worked, I noted that his AI usage was a bit different to mine - it was all about the output, less about the journey.

So I started to ask him questions - picked a line of code here and there and quizzed him, asked him why the game rules did X and had he thought about Y? It started to twig with him that he knew some answers, didn’t know others, or formed opinions. The output - the game - was both consequence and reason to continue. He quite enjoyed that, so did I.

The lightbulb went off - what if this simple, casual mechanic, grounded in a focus on the constraints of the format and the native web platform, with clear dopamine fuelled reward loops and hidden creative process could be a very clear path to development - like Duolingo does for language.

We could make it playful and educational. Challenges, streaks of micro-behaviours, knowledge reinforcement and micro-learning but with real, tangible, persisted outputs.

And so I continue to explore this idea and will share progress here as I go. Join in, I’m opening up a external Testflight group if you’d like to participate in the preview… drop a not in thread and I’ll be in touch to loop you in.

[gregraven]

Interesting concept. It would be nice to create a single-line of HTML / JS that would replicate the <!– include virtual –> feature of SHTML, or the <?php include "filename.htm"; ?> feature of PHP. Boilerplate code could be saved in one file, no matter how many pages in the site, and loaded as needed — without requiring that identical code to be included in each and every file on the site. The header, the footer, and the navbar alone would be wonderful to be able to add to web pages without having to have thousands of copies of each littered around the code base. Write once, read many! This would also make it unnecessary for static sites to have “build” and “source” folders. The build folder would have everything, including the files to be included within each page.

My two cents.