I’ve been interested in developing open web apps (aka the single-page app) for years. But, it feels like the space is really on fire now, since the advent of HTML5 tech and the recent moves by Mozilla and Google toward truly “appifying” these things to compete with offerings from iOS and Android. Lots of pieces have come into alignment, and great things are coming together—never mind what the folks at Facebook say.

So, I think I’m going to build a simple app and blog about it. And, these days, the first thing I think about when starting a web app is: How do I get it onto the web?

Start on the web

Okay, so getting on the web is not the first thing. The very first thing is to create a new github.com repo (complete with README.md and .gitignore) and then:

cd ~/Dropbox/Public/
git clone git@github.com:lmorchard/my-project.git
cd my-project

And then, I start thinking about getting it onto the web.

That might sound backward: If all I have is a README, aren’t I jumping the gun? Well, no—I like to iterate, especially when experimenting with something new. Start simple, try one little thing, repeat. And, because this is a new pan-device world we’re living in, I’m often sitting on my couch hacking with a laptop in front, tablet to the left, and phone to the right.

So, before I even write the first line of “Hello world” in HTML, I want to have a way to get at it from all the gadgets. If it were just my laptop, I could open a file:// URL and be done with it. Oh, but not really: Many of the new HTML5-and-friends technologies depend on things like domain origins and real HTTP connections.

I could start up a disposable HTTP server in the project directory on my laptop and point the other gadgets at that. That works, to some extent. But, that’s limited to my LAN, I can’t share it with others for quick alpha testing, and I can’t check it out when I’m away from home and the laptop is closed.

That leaves me with my own web server. But, you know, that’s a pain in the butt and I’m getting tired of being sysadmin to my own server. Let’s take it to the cloud!

How I (ab)use Github Pages

Since I started with GitHub, my project is already on the web. Or, mostly it is, but just not exactly how I’d like it. To get the project published at a URL, this is what I do:

git co -b gh-pages
git push origin gh-pages
git co master

Give it a few, and you’ll receive an email from Github Pages (re: [my-project] Page build successful). Give it a few more, since this is the first time for the project. Shortly, the README shows up at an URL like the following:

http://lmorchard.github.com/my-project/README.md

After that, whenever I want to publish updates to the app, this is what I do:

git co gh-pages
git rebase master
git push origin gh-pages
git co master

And, within seconds (usually), my app is updated on the web. With free hosting, because the folks at GitHub are really nice.

But, though this works nicely for an app demo or beta, try not to abuse their hospitality by using your GitHub Pages URL as the official distribution point for your app.

How I (ab)use Dropbox

You know, all that committing and pushing and rebasing can really get tiresome. And, it craps up my commit history while I’m just kind of twiddling some bits back and forth to see what happens. We’re living in the future, damn it, I don’t have to put up with this!

And, so, I don’t. Maybe you noticed that I ran git clone from inside my Dropbox Public folder. Anything in that folder is already on the web: Each file has a public URL, and I can acquire it with a right-click in Finder (ie. Dropbox > Copy Public Link). The result is something like this:

https://dl.dropbox.com/u/279855/my-project/README.md

It’s a crufty URL, but an URL nonetheless. Dropbox public links also mirror the folder structure, so that an index.html can load all the CSS and JS it wants from relative URLs just like a normal web host.

With Dropbox, then, my hacking cycle with Dropbox looks like this:

1. Save in MacVim
2. Switch to Firefox
3. Refresh
4. Repeat

More often than not, my app has gotten updated on the Dropbox servers somewhere between steps #1 and #3. That’s a much tighter iteration loop than doing the GitHub dance. In fact, it’s pretty much indistinguishable from just working on my laptop with file:// URLs or a disposable HTTP server on my LAN.

There’s some bad news, though. I’ve just read that new accounts created after 7/31/2012 no longer get a Public folder. So, it would seem that the days of carefree hosting-by-Public-folder are on the way out. But fret not: the folks at Dropbox have provided an alternative for hosting static web apps under development. They’ve also opened up their API for use by open web apps with dropbox-js. In fact, this API will play a part in the app about which I plan to blog.

How I use Amazon S3

So, (ab)using GitHub and Dropbox for hosting your app under development is fine and dandy. But, you definitely don’t want to rely on them for publishing your app for wider distribution. There ain’t no such thing as a free lunch (TANSTAAFL), and someone’s bound to shut you down or send you a bill—best to get that out of the way up front.

As it turns out, Amazon Web Services will happily accept the change from your penny jar to serve up small collections of web content. Well, they will after you’ve turned the physical pennies into numbers in a bank account, but my point is that Amazon S3 is super cheap. And, since I’m talking about a single-page web app here, plain old static web hosting is all you need for now.

In fact, if you own a domain name, you can control the URL from which S3 serves up your content. Basically, you just:

1. create a DNS record with a CNAME to S3 (eg. my-project.lmorchard.com -> s3-website-us-east-1.amazonaws.com);
2. create a bucket named for your domain (eg. my-project.lmorchard.com);
3. check a box in the properties panel to enable static hosting.

The above is vaguely more advanced than either GitHub or Dropbox, but this is playing with power. And, with great power comes great responsibility to read the fine manual. Still, it’s not that hard and it’s not that spendy.

How I make Amazon S3 work like Dropbox

So, great: You’ve got Amazon S3 serving content at a URL of your choice. And, you can upload content using the control panel or one of the many fine desktop clients available. But, that sounds a bit like the GitHub deployment dance, just GUI-er. Not bad for Official Releases of your app—but what a pain for development!

Apropos of that, I have a small trick on OS X that makes Amazon S3 as convenient as Dropbox:

• Install kicker;
• Install s3cmd and configure it with your S3 credentials;
• Run this from your project directory in a terminal: kicker -c -e ‘s3cmd -vfrP –exclude=”swp” –exclude=”.git” sync . s3://my-project.lmorchard.com/’

What this does is start kicker to monitor your files. Whenever anything changes, s3cmd uploads the changes to Amazon S3. After the first run, my content shows up at an URL like:

    http://my-project.lmorchard.com/README.md

So, again, my hacking cycle with Amazon S3 looks like this:

1. Save changes
2. Switch to browser
3. Refresh
4. Repeat

Again, this turns out to be nearly indistinguishable from working on localhost or with file:// URLs, because the kicker-s3cmd team has generally already shipped off my changes before I can get to the browser. I’m sure something similar to the above can be cobbled together on Linux or Windows, but I don’t work there so I’ve not bothered to figure it out.

In conclusion

Developing open web apps on the open web can be fun, fast, cheap, and convenient. I’ve got more posts forthcoming, at least in my head, but hopefully this one gives some starting points.

I may also revise and further develop this post, since I left quite a bit of reading to the reader with links to follow. There are also even more cheap and easy web hosts, so maybe I’ll explore those as well. In the meantime, feel free to leave some comments!