If you are going down this route then using a CDN like CloudFlare means you can have the static blog cached globally. We statically generate our blog using Pelican and then have it globally cached with 30 minutes timeouts. The result is almost no load on the origin server at all.
I guess it might work for a static block, but it is a huge amount of stuff to put on top of the blog and it seems entirely unnecessary - after all any computer should be able to fullfil any static request such that it is limited only by the bandwidth.
I find the static blog movement extremly interesting. You'd think with broadband and speedy mobile connectins like LTE it wouldn't matter so much, but those blogs load so amazingly fast, it's just fantastic. I'm thinking of switching my wordpress blog to something static, even if its only to get ouf of the scope of automated attacks.
You'd think with broadband and speedy mobile connectins like LTE it wouldn't matter so much
Quite the opposite. If you optimize the downloading portion of the whole HTTP transaction because of a high bandwidth/low latency connection then the server time (to generate the page) starts to be more and more important.
As connections get better increased pressure is placed on web servers. And there's another subtle effect: faster web sites get more visitors. So if you make your site fast you get more page views.
There's no reason you can't have both the ease of static site generators and the non-coder friendlyness of a CMS.
If anyone is interested I recently launched http://www.webhook.com as a way to have both words. Data is stored in a Firebase so you get clean JSON data so that you don't need to deal with all the bloat for simple content sites. We're currently cleaning the code up and will have it all open sourced by the end of August.
To me, the overriding advantage of the static blog is that it forces simplicity upon you...it distills the site to the simplest form of "web log": if you are one person, wanting to write a series of chronologically ordered posts, then you don't need a database (hence, something like WordPress).
I've rarely found this kind of simplicity to be stifling. For the first 1,000 posts, you can compose and edit in plaintext with minimal difficulty in "envisioning" the post, as you might in a rich text editor. Even better, you don't have to deal with the eccentricities and inefficiencies of RTEs...and if your blog is on a focused topic, where you find yourself re-wording terminology and grepping frequently...it's a simple Ctrl-F in Sublime Text.
Even the HTML and CSS parts are simplified, since you only have to worry about the elements needed to keep a post in single layout (and maybe a sidebar column)...and editing CSS in your editor of choice is far less cumbersome than the out-of-the-box way of WordPress.
The static blog generator (at least Jekyll and Middleman on the Ruby side) then does all the clunk that would be tedious if you were to just upload plaintext to the web: namely, the ordering, timestamping, and internal-linking of the posts, as well as categories/tags, and things such as SASS compilation...and then it's just a CLI-task to update the site on S3.
Sure, after a 1000 posts...you'll see the need for a CMS to better organize and package things (not to mention the ability to update a post without regenerating the entire site)...but that's a long ways off for most would-be bloggers. And if you need to convert to non-static, well, all the metadata that was used in static-generation is easy to parse and import into any blog system.
On a day to day, or week-to-week basis, though, I find that it's the small things that can make a difference...the thought of logging into my old WordPress blog, waiting for my Dreamhost shared hosting to take 1-2min to load up the post-editor page, and then copy-pasting from where I wrote my drafts into the rich-text-editor and hoping nothing got kludged...that's enough to make me not blog...which means I might only blog when I really, really care...and if you only write when you "really, really care", you're just not going to be writing enough to be someone who can do it consistently well.
Does anybody know if there's a blog suite where blog entries/comments/etc are stored on the filesystem as dumb JSON files, and rendered using a client-side javascript framework?
From the server's point of view, it could be all static (both the compressed .js app and the json files are just files on the filesystem that can be cached, no database needed), but you can still update the site dynamically through an API endpoint. The API endpoint can trigger server-side code that writes new JSON files out appropriately, but for all non-comment-posting, non-blog-writing traffic, it's all just plain files.
Of course, a decent caching layer at any point can make any dynamic server behave like this, but it'd be cool to have your entire blog work without any code running other than a simple nginx/apache config that serves out static files (and reverse proxies to you app for any POST requests).
Actually the more I think about this, the more I think this could be a fun weekend project.
I don't mean this in a hipster way at all.. but static blogs have been around and popular for a long time. It's been at least 5 years since Jekyll got popular which is one of the first static site generators that I remember catching on. There were surely ones that came before that that I hadn't heard of. I was building blogs and websites with Hyde (a Python clone of Jekyll) in 2009.
What's old is new again?
It feels kind of silly to call this a movement :).
Blogger was a static blog generator well before this. It launched in 1999 and was around for a few years in that form before it was acquired by Google in 2003 and transitioned . You logged into the Blogger site and wrote your posts and then published them, which would generate your files and then FTP them to your server.
Your site isn't faster because it's only HTML. It took ~360ms for DOMContentReady in average on your site while on pothibo.com (My blog running on Ecrire) took an average of ~260ms.
Your post made quite a lot of emphasis on "speed" but the first argument I checked was false. I used static site generation and it's a very poor choice for your personal website.
Works fine to create a Readme on github. Sucks if you use it to manage your personal website (brand).
With a non-primed cache, your site gave me >1s for DOMContentReady consistently. OP's never reached 700ms. The main HTML page alone of this post[1] takes ~280ms here.
Fresh cache run of your site took me 800ms vs. 400ms for OP.
I suspect you didn't try with a fresh cache for your blog. If all your JS, CSS, etc was cached locally already that would explain your "performance advantage" to me.
Use SSH, write scripts to facilitate bulk changes, do dynamic content with Javascript on the client side. If you need server-side logic, build some APIs and talk to them from the JS. Much cleaner than hacking additional features into off-the-shelf CMS/blog software.
What you are describing sounds like a hodge-podge of workarounds.
Like, one solution is "Use SSH, write scripts to facilitate bulk changes, write multiple backend services and front-end JavaScript to interface with them for any actual functionality you want on the site." The other is "Push a button on your blog software." How is the first one "cleaner"? You're basically re-inventing half of a blog with duct tape and toothpicks.
It's cool, it's trendy, but no. It's not more practical, or quicker to load, or... Maybe more secure, but to make a blog simple dynamic blog secure is easier than to understand how to generate a static blog with something like Pelican.
I actually only see downsides:
* I can't write from another computer easily, or a tablet, or a phone...
* I can't easily add options like a search engine, comments (disqus is pretty bad for SEO I presume), most read post, etc...
* I have to use a setup everytime I want to write. I have to open a text editor, I have to launch a terminal and go through command lines to generate the blog again and I have to upload/commit,push the new generated files.
And you can statically cache pages from a proper blog engine. In fact, that's actually built into some of them, unlike the functionality you describe here for static site engines, which AFAIK all of them require you to write yourself.
And you can statically cache pages from a proper blog engine.
That still requires the blog engine to handle potentially malicious requests, prevents hosting on static services like S3 and increases load time for any non-cached page.
In fact, that's actually built into some of them, unlike the functionality you describe here for static site engines, which AFAIK all of them require you to write yourself.
There are modules like jekyll-hook, which can do it for you.
In my experience, these solutions are like passive income; you spend more effort upfront, but save in the long run.
I've managed dynamic blogs in the past (first using Dotclear, then Wordpress), and I had to be constantly installing security updates and making sure the backups were being correctly made. Backups on Pelican come for free, since it's all on git and on your machine(s) in the first place.
> you spend more effort upfront, but save in the long run.
Not storing data in a database and not having a inside comment system is not what I call saving in the long run.
> and I had to be constantly installing security updates
Why use Dotclear or Wordpress then? If you can do what you said you do with Pelican and cronjobs/pulls on the github to automate the task. You should be able to code the blog yourself.
> making sure the backups were being correctly made.
It's really not that hard to automate backups.
> Backups on Pelican come for free, since it's all on git
You're relying on github for backups where I rely on my server for backups.
And as you said somewhere else, if you want something as practical as a dynamic blog you need to be able to add new post through other devices. Since things have to be (re)generated everytime you post you need a server to watch the changes on your github.
The more I think about it the more I feel like it's complicating things for no upsides at all.
Not storing data in a database and not having a inside comment system is not what I call saving in the long run.
The data is in a hierarchical versioned database called a git repository. As for comments, fair enough. I don't happen to use them; if I did, I might choose a different option.
Why use Dotclear or Wordpress then? If you can do what you said you do with Pelican and cronjobs/pulls on the github to automate the task. You should be able to code the blog yourself.
I thought dynamic engines were supposed to save time? Setting up Pelican was a matter of a couple of hours, if that, and running a command that periodically does git pull and calls the rebuild command takes 5 minutes.
It's really not that hard to automate backups.
Oh, they're automated. But you still have to test the regularly. Having blind faith in a backup procedure is the surest way to lose data when you need it.
http://www.taobackup.com/testing_info.html
You're relying on github for backups where I rely on my server for backups.
Well, no. Git is distributed, so I have a copy on my laptop (which then gets backed up along with all my disk), one on my tablet, etc. Every device where I edit posts is another backup.
The more I think about it the more I feel like it's complicating things for no upsides at all.
As I said, the advantage are mostly not having to worry about security and backups. Since you consider writing your own blog engine a less complicated solution than installing a Python package and writing a simple cronjob, I think we won't reach a consensus.
This.
I used to use Blosxom in static-only mode (a bit of blog rendering software which consisted of a single 200 kilobyte Perl file). At some point I used it to build a seminar page for the department I was in, and it's still happily chugging along, long after updates for Blosxom stopped happening, with no worry for security. And since the blog entries are really just markdown files, it's super easy to port to another system should the desire arise.
It could certainly be faster to load since a server can push out static files far faster and at a higher rate than compared to say Wordpress/PHP (even with heavy-caching of pages).
Do you find that you're limited to using desktops/laptops because of the client requirement, or are there good options for adding posts from phones/tablets?
I use a static personal wiki, and I update it using SGit on my Android tablet (and any text editor, of course). Commit and push is just a couple of taps.
I tried using a static blog for a while, but I found I was spending so much time fighting with the generators out there that it made far more sense to just use WordPress. Plus (I and probably nearly everyone else), hardly get any traffic, so costs aren't an issue (and if it were, there are tons of ways to cache WordPress pages, so you effectively get a static site on top of the WordPress CMS; I'm not sure what else you could ask for).
In my case, because I don't trust any blog engine to remain secure if I can't find the time to update it regularly, and I'd rather pay the $29/month that WPEngine would cost me on other stuff.
The one thing you are definitely not sacrificing is availability. Making static content is far simpler and easier to make highly available via a Push Zone on a CDN. Cheaper too.
I'm asking this question as seriously as you asked yours. There are apps for markdown, ssh, sftp, ftp, and all sorts of related tools that would let you do this from your phone.
I do know how to download apps and I am genuinely curious. The beauty of for instance the wordpress app, is how integrated it is with the phone. Can insert pictures and videos from the camera easily. How would this work from the ssh and ftp apps? Without having tried it out I can't really see how this is anything but cumbersome.
I always figured that static blog generators were big with the developer crowd simply because the creation of a static blog generator is a 'bread-and-butter' beginner CS project.
They are as flexible as you have the capability to make them be. I think that poses a big problem for most.
