You just create a folder called "yourdomain.com" and put your static files in there, upload, done. All URLs are rewritten (/foo/bar/ resolves to /foo/bar.html or /foo/bar/index.html) and you can host multiple domains on the same GAE instance. I use it for various static sites, such as my company's site (http://www.stochastictechnologies.com/) and my resume (http://resume.korokithakis.net/). They're all pretty much hosted for free, since they're static files on a single app on AppEngine, and migration is almost free (you just upload the whole thing to the host of your choice).
You can also assign multiple domains to one site, or rewrite your URLs to custom files.
I think the main itch being scratched here, is the problem of templating.
Those that grok file systems, might be happy assembling content into an appropriate folder structure, and hitting a 'publish (to html)' button. You could use a little metadata - such as summaries and keywords to string it all together.
I know there are systems such as Pelican already out there, but it's still too complicated for Joe Blow to produce a site with the tool.
Frames were a pretty simple alternative to elaborate CMS's that have been employed to pretty much solve the same problem.
So much wasted CPU time and money. So called professionals cashing in while presenting building web sites as mystical and technically difficult (I realise the tech is difficult - but why should it be?). It goes so against Tim Berners-Lee's vision of publishing easily and straight from the browser.
Not having some dead simple web page editor, has ended in sites such as Facebook becoming 'the web' to so many people.
It maybe isn't simple enough for Joe Blow to use (yet?), but I started working on Serif[1] specifically to get away from having to manage the filesystem, without losing the simplicity of everything just being files. Having a web interface to edit content makes a big difference. (It still supports ignoring the interface entirely, while keeping certain things automatic like fine-grained timestamps.)
Jekyll, which it is similar to, had stagnated by the time I'd first put it up on GitHub, but it's probably closer in "philosophy" to Statamic[2].
I have been seeing a lot of static blog generators being paraded around lately. I seriously think that static blog generators should be the next "hello world" when learning a new language. It seems to be useful in doing just that.
Oh I mean it as a way to know how the language works.
EDIT for more information:
Being able to write a static blog generator means you have to learn most of the basic skills in a language from the data structures to objects/functions (whatever floats your boat). You have to also most likely interact with outside systems like I/O and databases (if your static blog generator is db driven). You get to familiarize yourself with packaging/modules that the language uses. So yea, I think creating a static blog generator as a next step after hello world would be great
It does seem to make more sense to just roll your own static site generator rather than try to learn a whole new framework and language like Jekyll, which then might not even give you everything you want. This is particularly true if you where to use a robust templating engine like Jinja2.
I like the idea of generating as many of our site pages as 'static' as we can. We created our own system for our needs but I am seeing a lot more of this as I look around. What I'm curious about is how people tend to handle dynamic content?
If you put Varnish in front of your site you can use edge side includes to populate the dynamic fragments of your site. Since it is Varnish you can also cache the fragments themselves.
I love seeing the source for such elegant single-purpose projects like this. I'm in the middle of writing my own static site generator for Python; it's a bit more feature-rich, but it's up at something like 800 LOC for the minimum feature-complete implementation. Great to see evidence that I have a long way to go..
Yes, I've learned a lot seeing how different people are approaching the static web page publishing job. I'm at the other extreme, a couple of bash scripts to push markdown files through markdown and add header/footer then push the changed ones out to the Web.
Seems nice but at first sight the code needs a bit more checks. There is a rmtree on a config parameter that could delete all your content if the tool is misconfigured.
I thought about mitigating that, as it could definitely have some nasty effects, but couldn't come up with a decent way to do so. Hopefully, people won't misconfigure it too often!
Rather than a web app that runs and serves up content dynamically, this just spits out HTML that your webserver can serve up. No additional surface area for attack, no need for caching to keep things efficient, etc. Super simple.
Cool. So there is no DB involved at all for the content? When you edit, the old file is replaced by the a new one?
I guess there is a backend you log in to and a wysiwyg for editing?
Nope, no DB at all. The way you edit the content is 100% up to you, but at the end of the day, your entries are just Markdown files in a directory. You can see my whole blog setup at https://github.com/daeken/Benjen/tree/master/daeken.com
If you don't mind a local backend that you access on the command line, you can host the blog itself (or any static site) directly on Github with no further ado. I recently moved my since-1997 site Vivtek.com to Github and freaking love it. It's never down, no matter how much I neglect my active server!
when you edit an article file, you also want to regenerate index, sitemap, rss feed, ... etc. or any pages that depend on the modified article.
when you edit a template or configuration, you need to regenerate entire site.
even if you blog very often, say 10 times a day, in 10 years, you only have 36k articles. Probably it shouldn't take too long to regenerate entire site for any kind of modification or addition of pages.
or, you can try to be smart and draw dependency graph (maybe using Makefile) and update what's only needed. basically you're solving caching problem, one of the hardest thing in programming.
You could have your static generator create symlinks for each post at the short url pointing to the actual page at the canonical url to handle this, and set your server up to follow symlinks.
Alternatively it could generate a table of redirects for you to put in your server config/htaccess.
No idea I'm afraid, it depends on their setup. I used it as one approach when generating a static blog a while ago under Apache, but there are plenty of options (using config redirects, using symlinked pages or dirs, using duplicate html pages with rel=canonical, using js redirects in extra html pages), and I'm sure some if not all of them would work on S3. As long as you're generating statically anyway, you can always add another step to generate all your short links automatically too in whatever form works on your server...
Generally, a typical blogging engine is made up of templates, your database of entries, and some sort of logic that stitches them together on the fly when a visitor hits your website.
A static blog is run through a processor once, and plain html pages are generated and stored on the server. When a visitor requests a page, they're served one of those static pages.
WordPress has caching plugins that allow your blog to serve static pages (helpful when traffic surges and your database might be overwhelmed), but, by default, a WordPress blog serves content dynamically (meaning it isn't cached).
Cool. Any plans to add an RSS feed? Your blog is really interesting, so I'd like to subscribe, but I probably won't remember to come back and check it manually.
The only Jekyll-specific stuff is the first three lines and the `{{ .. }}` and `{% .. %}` templating code.
(For those who don't know, Atom is the better, cleaner replacement for RSS, supported by virtually all RSS readers. I like to promote RSS since people know what that means, but when I go and actually implement it, I spell RSS "Atom".)
I have mixed feelings about static site generators on one hand i really like the geeky approach where you make everything yourself and build it all from scratch and you fiddle around in the terminal ... on the other hand im really lazy and just want to push a button and it just runs.
And I think that is why I love the idea and concept of Kirby. It's PHP yes, but I this case I don't really think that, that is a bad idea. I wan't my blog to be easy and cheap to host. And a PHP hotel is easy and cheap. With Kirby you build your site and upload it to some random host and it just runs. No need to setup S3 or Github commit and push.
https://github.com/stochastic-technologies/static-appengine-...
You just create a folder called "yourdomain.com" and put your static files in there, upload, done. All URLs are rewritten (/foo/bar/ resolves to /foo/bar.html or /foo/bar/index.html) and you can host multiple domains on the same GAE instance. I use it for various static sites, such as my company's site (http://www.stochastictechnologies.com/) and my resume (http://resume.korokithakis.net/). They're all pretty much hosted for free, since they're static files on a single app on AppEngine, and migration is almost free (you just upload the whole thing to the host of your choice).
You can also assign multiple domains to one site, or rewrite your URLs to custom files.