Spinto is Git-based, like Heroku, and uses Jekyll with pre-processors for Sass/Scss (and Compass, Bourbon), Less & CoffeeScript. I agree with Brandon that FTP is hopelessly out of date and frustrating. Even more than that, I think there is madness in the idea that you need a database backend for your website to let somebody else change a comma, or an image (sometimes you need full-blown-CMS, but not always).
I'm trying to make a static websites easier for us to create, deploy, and collaborate on. Feedback _always_ appreciated.
Like some of the commenters here, I looked around for simple static website hosting when I was trying to find a new home for my blog. I considered Heroku, GitHub Pages, and S3. Heroku didn't seem particularly optimized for static hosting (e.g., dyno spin-up time), and GitHub Pages lacked some flexibility (like custom mime types for my extension-less URLs). S3 doesn't handle things like sending gzipped content to only browsers that support it. Ultimately, my cofounder and I decided to build our own solution based on Dropbox: http://www.site44.com.
Site44 is in a private beta now, but we're hoping to move to a public beta very soon. I'd love to get some feedback from HN. The basic idea is that when you create a site (<foo>.site44.com or a custom domain), we create a folder for you in Dropbox, and then you publish by just modifying the contents of that folder.
Another option is Github pages. I host my blog there for free and have had posts featured on HN front page - served with nary a slowdown or github sending me a bill. It's awesome.
You know, static hosting works really great on Amazon S3, as long as you don't need a .htaccess file. On all of my jekyll sites I use S3 now and there's even a jekyll-s3 gem that makes pushing your site up to S3 painless. The nice thing about using S3 is you don't have to wait for Heroku instance start up if it's not a high traffic site.
Oh, I guess I could use GitHub hosting, but I wanted to host it on my own server. (I actually have a good reason to - I needed to access a WebSocket server on the same origin)
I don't see the advantage of that. For small static sites I don't think it's much more hassle to put CloudFlare in front of your server. The advantage of such services is scaling up dynamic sites easily.
Isn't Heroku a mediocre option for a static site unless you're paying? If the site isn't accessed for a while they spin down your EC2 instance, and it takes a few seconds to get it back online.
Ha! I never thought anyone would use that. It's basically a simple fork of their PHP buildpack that stops caring if it's PHP and just serves off of Apache. Perhaps I should clean it up.
I tried a few other buildpacks like the nginx ones, in the end this was the only one that didn't force me to configure or adapt anything, just worked, so thanks a lot! :)
There's an even easier way to do static sites on heroku and have them compiled for you - use stasis (http://stasis.me) - I've built a framework on top of stasis and have been using it for months, as part of very large production sites, and it's been extremely stable and super easy to use.
All you need to do to get them working on heroku is include a super basic config.ru file, and you're all set. The files compile into a public folder which heroku uses to serve them.
I am the creator of Stasis. Compare the sheer length of docs for nanoc (http://nanoc.stoneship.org/docs) to those of Stasis (http://stasis.me), and keep in mind that Stasis can do anything that Nanoc does.
This is not the case, not by far. nanoc is aimed at building complex sites and hence has a lot more features than Stasis. Some examples:
- Items can contain arbitrary metadata in nanoc
- You can trivially build multiple representations of a single item in nanoc (e.g. a PDF/txt/html representation of a single markdown file)
- Dependency tracking in nanoc is fully automatic (no need to specify priorities)
- Nanoc is easily extensible using custom filters, custom deployers, custom helpers and more
Statis and nanoc have a different audience. To me, Stasis seems to be aimed at simpler, smaller sites, while nanoc is aimed at much more featureful sites. It is a good thing to have a lot of documentation (nanoc is frequently cited as a good example of how documentation should be handled).
Doing it with Sinatra w/ no routes and just using the public folder seems easier IMO but the php method another commenter mentioned sounds like the best! I'll be doing that from now on methinks.
http://spintoapp.com
Spinto is Git-based, like Heroku, and uses Jekyll with pre-processors for Sass/Scss (and Compass, Bourbon), Less & CoffeeScript. I agree with Brandon that FTP is hopelessly out of date and frustrating. Even more than that, I think there is madness in the idea that you need a database backend for your website to let somebody else change a comma, or an image (sometimes you need full-blown-CMS, but not always).
I'm trying to make a static websites easier for us to create, deploy, and collaborate on. Feedback _always_ appreciated.