Over the holiday break I decided to give GitHub Spark a try.
GitHub Spark is a new feature in GitHub Copilot that helps you build web applications quickly using AI. The Spark platform is based on React with Tailwind CSS. It also provides user authetication (via GitHub account), and user-specific data storage (via Azure).
At the time of this writing it seems like it’s still an early version of the platform, so depending on when you’re reading this, you may need to do your own research.
The Project
I’ve been looking for a good health tracking app for years, but so far been disappointed with everything I’ve found. They are either too simple, too limited, or too expensive. There are some free ones, but I haven’t found one I like. Even if I did, the free ones are often making their money selling your health data. So I tried making my own with Spark.
The kind of app I’m looking for will provide reminders for medications, track how much I’ve taken and when, and record a few symptoms of interest. With this kind of data available, I can take hard numbers and graphs to my doctor appointments. It’s definitely on the nerdy end of the data collection fad, but I’ve found it helpful and insightful.
Short Version
It took a couple of four-hour sessions, but by the end of it, I had an app that I’m still using today. I like it better than any product I’ve seen. It has a few annoying bugs, some visual inconsistencies, and the layout could be a lot better. Honestly though, it looks and performs better than many cheap mobile apps I’ve seen in the store.
The most interesting part for me is the Spark platform, which is both a strength and a weakness. It’s comforting to have built-in authentication and storage mechanisms instead of depending on AI slop for these core functions. It also takes care of auto-update notifications. It makes it possible to get many simple apps off the ground quickly.
The problem, though, is that once you’re in the platform, you’re in the platform. Spark only makes web apps built on the Spark platform, and you don’t have any other choices for where the data goes or how it gets synced. It also doesn’t make mobile apps. It works fine as a pinned link on my phone, but this limits it’s ability to be used for ad-supported consumer apps.
Notifications
I’ve not yet seen a single notification from my app, even though Spark has assured me that it works. It’s also assured me that it’s fixed it, twice now. Each time, it’s told me that it knows for sure why it hasn’t been working. So this hasn’t inspired a lot of confidence.
This could be a limitation of the platform, or the platform it’s running in, but it is a glaring defect. Even though it can’t do one of the main things I want from the app, I still prefer it over others I’ve used.
To be clear, I haven’t spent much time debugging or diagnosing the issue myself. I might be able to get it to work if it was a significant issue for me, but so far, it hasn’t made the top of the list.
Design Experience
Spark generated a working app that met most of the requirements after just a few minutes. It wasn’t great, but it was usable. Unfortunately, my experience went downhill from there.
The app had a few tabs for the different areas of functionality, but they all worked differently. To make them consistent, I had to keep asking Spark to change things. I found myself getting more and more explicit because I was developing a preference, and I wanted to make sure it took the best approach. This is not what it’s like working with great developers, it’s more like how the relationship goes when I work with sloppy ones.
It produced a clean, modern looking app, but it had a bunch of usability issues. Information density was terribly low, and several iterations trying to improve it resulted in little improvement. I ended up accepting it as it was and moving on to more important things.
One part of the experience I liked was the way the app is constantly running in a test mode while Spark is working on it, so you can keep playing around and testing. Unfortunately, the changes were often so slow that I found myself needed to document all the things I wanted to fix somewhere else. I couldn’t just walk through all the little visual and usability issues and move on, I had to enter them one at a time and wait while it figured out what to change.
The long time between changes quickly became a real drag on the experience. Even simple changes like, “Make the save buttons on every tab have the same padding and style” could take 5 minutes. That’s not long enough to do anything else, but way too long to maintain a state of flow.
Rapid Prototyping & Evaluating Requirements
The work was ultimately very different from normal programming. I wasn’t building an app as much as I was designing a product. It was easy to try things out, to get my hands on it, and see what works. But I had arms-length control in a way that I’m not used to.
To be clear, Spark makes all the code available to you, and editable, but I’m not sure how well it handles it if you start changing code directly. Except for very minor tweaks to wording, I didn’t want to risk losing the AI experience to continue making more fundamental changes.
I think this project turned out well for me because of a few factors:
- I was building something I wanted to use myself. I have a very strong understanding of the problem and requirements. Every reaction I had was a real user reaction. This wouldn’t be true if I was trying to make software for an industry I’m not a part of.
- I had already tested several similar applications, so I had seen a few different approaches to the problem. This allowed me to articulate what I wanted up front, taking the best parts from everything I’d used.
- I’ve been designing and building user interfaces for a long time, so I know the common patterns and have a specific sense of what I like. Also, like any developer, I am particularly well practiced at describing what I don’t like. In this case, it’s actually a benefit.
I don’t think you need to be able to write code to build an app using Spark, but I think it would be hard to build a good one without practice studying them. Spark wasn’t able to suggest approaches, or push back when I asked for things it couldn’t do well, or do at all. I had to give it meticulously detailed descriptions and then inspect everything thoroughly.
That being said, the ability to build, test, and iterate helped me to figure out what worked and what didn’t in an amazingly short amount of time.
Another non-trivial factor was how tiring it was to work with Spark. Between waiting and making decisions (which is surprisingly tiring), I would get tired really fast. I found it hard to motivate myself to go back for the second round to finish the project.
Looking at it from the outside, building a functional-enough app in just 8 hours of labour is an amazing feat. But even as someone who loves using software to help people, I don’t feel any excitement about using it again.
Since those first two sessions I’ve since gone back and tweaked some features and fixed some bugs. I think I made a pretty big improvement with just 30 minutes, and I didn’t feel worn out afterward. Perhaps more short stints spaced out would be a better way to work with this sort of tool.
Next Steps
It was an interesting experience, and helped me prove to myself that a home-made tracking app is something I would actually use. I don’t think I could turn this one into a product though. I’m not even comfortable releasing it freely as open source. It might be possible to hack my code out of Spark since it’s mostly powered by React. It might even be possible to cram in a shim to change where the data goes. My developer instincts tell me that it wouldn’t be worth the trouble it could cause.
I will probably make another attempt at building a similar app with AI, but I won’t use the Spark platform. I’d like to have a bit more control (or any at all) over how the data is stored, how users log in, and to be able to make real mobile applications with platform-native features.
I might use Spark again if I want to try some ideas out quickly, or show someone a prototype. It might be okay for some in-house tools too, but the user-centric data storage would be a dealbreaker for many common scenarios.
It’ll be interesting to see how this technology evolves. I’m sure the AIs will get faster and better over time. The Spark platform could add a native mobile runtime environment and expanded features for managing data. Until it does improve, though, I can’t see myself using it for any serious projects.