Why I Joined the Static Blog Movement
farrellkramer.github.io
farrellkramer.github.io
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.
You can scale anything,just that scaling is expensive.It's stupid to pay for computation if all one needs is serving blog posts that hardly change.
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.
However, I run my sites on my own server. Are you planning to offer a version that you can install on your own hardware?
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.
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 :).
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).
- Refactor your posts' tag? You need to manually edit all your post one by one.
- Refactor your theme? Same thing as above
- You can't have dynamic content, ever.
Not true. OP himself hosts his source on Github, so not only he has access to it everywhere, as he can edit it from any machine with a browser.
- Refactor your posts' tag? You need to manually edit all your post one by one.
- Refactor your theme? Same thing as above
Not true. Static site generation engines like Pelican (which OP uses) can do it for you.
- You can't have dynamic content, ever.
You can with JavaScript (or by integrating a third-party service, though that's cheating a bit).
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.
> - Can't edit anywhere beside the machine that has your source & access to server.
Eh? Use CI and push via Git & a Markdown editor? They have apps for these on your phone? Or just GitHub?
> - Refactor your posts' tag? You need to manually edit all your post one by one.
I can replace all in an entire directory of documents in ~5 seconds. This is a non-issue.
> - Refactor your theme? Same thing as above
I modify two files to refactor all my blog posts.
> - You can't have dynamic content, ever.
Eh? AJAX? Allows you to make calls to another api/domain to throw in dynamic content?
[1] http://pothibo.com/2013/11/rails-journey-dispatch-to-the-con...
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.
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.
Login to Github, edit file?
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.
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.
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.
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.
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).
I think that feeling of speed is because most static blogs don't have a lot of images, javascript, etc...
The only reason I can see for bothering with static blog software is because that in itself might be fun. At least you have something to blog about...
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.
However, if you are comparing it to the Wordpress app? Ya, that is easier. However, you aren't comparing apples to apples at that point.
If I built a purpose built app for my static blog, yes it would be just as easy.
They are as flexible as you have the capability to make them be. I think that poses a big problem for most.