Embrace the Static Web with Punch(laktek.com)
laktek.com
Embrace the Static Web with Punch
http://laktek.com/2012/11/04/embrace-the-static-web-with-punch/
12 comments
I've gone back to static generators almost exclusively - full circle really as some of my first web pages were generated with Userland Frontier (anyone remember Clay Basket?) nanoc (http://nanoc.stoneship.org/) is currently my tool of choice. WordPress and (popular) plugins are a huge target these days - happy to not be worried about security with static pages. Comments can be handled by Disqus, mobile publishing with dropbox and some plumbing. Certainly not as easy as a "one click install" at a webhost, but fast, scalable and infinitely configurable. Generating feeds in the build process is not difficult either.
[deleted]
This seems to be the Node equivalent of Jekyll in Ruby. Pretty awesome!
The use of Mustache is a bit off putting. I'd prefer a template language that lets me put all the gory code I like in my templates.
You have the option of changing the template engine to any one you prefer - https://github.com/laktek/punch/wiki/Adding-a-New-Template-E...
For example, here's a handlebars plugin for Punch - https://github.com/laktek/handlebars
For example, here's a handlebars plugin for Punch - https://github.com/laktek/handlebars
As everyone has, I built my own static site generator called Fairytale (https://github.com/46Bit/fairytale). Unlike a lot of them, it wasn't intended as a simple magic-incantation tool: I reimplemented the relevant parts of Sinatra for static-site compilation. You program everything and in development can just use the sinatra gem instead of the fairytale one to get a server.
I've been using it on https://46bit.com for something like a year now, and the thing I've realised is that it's largely a luddite thing. The movement is a rebellion against POS software like Wordpress, but ignores the fact that building a nice, Markdown-driven app with caching and a lovely interface is actually quite easy & friendlier in the long run.
It might be great for people afraid of servers, but I'm not. I don't want to be - I'm still serving a bunch of dynamic apps off the same two servers I use for a few static sites, and I enjoy learning how to tune them.
I'm planning to transition away from static sites. Initially to just serving a Sinatra app, then later to a custom Padrino or Rails blog engine. Would love to hear if anyone's got any suggestions for something off-the-shelf and hacker friendly in Ruby though.
I've been using it on https://46bit.com for something like a year now, and the thing I've realised is that it's largely a luddite thing. The movement is a rebellion against POS software like Wordpress, but ignores the fact that building a nice, Markdown-driven app with caching and a lovely interface is actually quite easy & friendlier in the long run.
It might be great for people afraid of servers, but I'm not. I don't want to be - I'm still serving a bunch of dynamic apps off the same two servers I use for a few static sites, and I enjoy learning how to tune them.
I'm planning to transition away from static sites. Initially to just serving a Sinatra app, then later to a custom Padrino or Rails blog engine. Would love to hear if anyone's got any suggestions for something off-the-shelf and hacker friendly in Ruby though.
I think calling it "a Luddite thing" is perhaps a little overkill.
Sure, it's easy enough to scale Wordpress, but I literally won't use 99% of the features that Wordpress offers, and all those features are potential attack vectors. On top of that, with every blog engine / CMS I've ever used (including the ones I'd custom-written), at some point I end up needing to use an iframe with static content because a CMS is only so flexible.
Instead of all that, I can put up a static page that is infinitely flexible, use Disqus for comments, and be pretty much free of risk. No database to hack into, no patches to apply, etc. On top of all that, it's even easier than using Wordpress.
So, while I don't disagree that there are people using Jekyll and ilk to rebel against Wordpress, an equally valid wonderment would be in trying to figure out how Wordpress got so carried away.
Editing to add that your approach is pretty much the same thing I did, but in Django instead of Ruby. I kept using the "CMS"-like methods of Django, but then completely render them out as static pages to be published to S3.
Sure, it's easy enough to scale Wordpress, but I literally won't use 99% of the features that Wordpress offers, and all those features are potential attack vectors. On top of that, with every blog engine / CMS I've ever used (including the ones I'd custom-written), at some point I end up needing to use an iframe with static content because a CMS is only so flexible.
Instead of all that, I can put up a static page that is infinitely flexible, use Disqus for comments, and be pretty much free of risk. No database to hack into, no patches to apply, etc. On top of all that, it's even easier than using Wordpress.
So, while I don't disagree that there are people using Jekyll and ilk to rebel against Wordpress, an equally valid wonderment would be in trying to figure out how Wordpress got so carried away.
Editing to add that your approach is pretty much the same thing I did, but in Django instead of Ruby. I kept using the "CMS"-like methods of Django, but then completely render them out as static pages to be published to S3.
You sum up exactly why I've long since not cared about WordPress, but you seem to assume anything dynamic has to have an admin interface.
The ideal engine for me still uses flat files for content, but doesn't compile the files to HTML. Let a cache like Varnish handle the load. That way I can implement things like comments without running off to the latest service-of-the-month that might shut down and take everything with them.
I've spent enough time dealing with third-party javascript and issues on their end screwing up the first-party to want no part of a remote comment service.
The ideal engine for me still uses flat files for content, but doesn't compile the files to HTML. Let a cache like Varnish handle the load. That way I can implement things like comments without running off to the latest service-of-the-month that might shut down and take everything with them.
I've spent enough time dealing with third-party javascript and issues on their end screwing up the first-party to want no part of a remote comment service.
So what's an example of a flat file that isn't HTML? If you have flat files, what value does Varnish provide?
If you're accepting use input to write files, then you have vulnerability. I'm not saying you do or don't, but it's an attack vector. As for Disqus, sure, I'm at their whimsy when it comes to security, but they haven't bitten me yet, and I'd hardly consider them fly-by-night as they've been around for years now, and has been profitable since their first year.
For what it's worth, I wasn't considering the admin site as vulnerable, as those are generally disabled before deploying, but if you're running a database, or varnish, or Apache, or whatever, your risk is increased for vulnerability, but I suppose that's neither here nor there really, as I think it comes down to a matter of taste and, as you said, I'm trading system vulnerability for third party vulnerability. The upside though is that while sure, somebody could munge my site up, fixing it is just uploading another copy.
If you're accepting use input to write files, then you have vulnerability. I'm not saying you do or don't, but it's an attack vector. As for Disqus, sure, I'm at their whimsy when it comes to security, but they haven't bitten me yet, and I'd hardly consider them fly-by-night as they've been around for years now, and has been profitable since their first year.
For what it's worth, I wasn't considering the admin site as vulnerable, as those are generally disabled before deploying, but if you're running a database, or varnish, or Apache, or whatever, your risk is increased for vulnerability, but I suppose that's neither here nor there really, as I think it comes down to a matter of taste and, as you said, I'm trading system vulnerability for third party vulnerability. The upside though is that while sure, somebody could munge my site up, fixing it is just uploading another copy.
> So what's an example of a flat file that isn't HTML? If you have flat files, what value does Varnish provide?
Sorry, that's probably confusing language here. I was referring to structuring Markdown files in a flat-file database, not the concept of compiled HTML files.
Sorry, that's probably confusing language here. I was referring to structuring Markdown files in a flat-file database, not the concept of compiled HTML files.
I've written something similar in 150 lines of code, if anyone is interested: https://github.com/olegp/mcms
Here is a list of static site generators (you should add your own):
https://gist.github.com/2254924
I'm big fan of Jekyll. I use it intensively on my binaryage.com site: https://github.com/binaryage/site
I also started working on my own client-side static-site post-processor: https://github.com/darwin/terraform
This is not yet another static site generator. The idea is to have browser-based editor for static site with live preview. Saving your changes would go directly to github, which will trigger site regeneration.
Right now I'm waiting for PhantomJS to upgrade internal webkit version. Terraform depends on the new DOMMutationObserver API (resp. on http://code.google.com/p/mutation-summary).
I'm big fan of Jekyll. I use it intensively on my binaryage.com site: https://github.com/binaryage/site
I also started working on my own client-side static-site post-processor: https://github.com/darwin/terraform
This is not yet another static site generator. The idea is to have browser-based editor for static site with live preview. Saving your changes would go directly to github, which will trigger site regeneration.
Right now I'm waiting for PhantomJS to upgrade internal webkit version. Terraform depends on the new DOMMutationObserver API (resp. on http://code.google.com/p/mutation-summary).
Aww, I thought I was gonna be the guy who talked about my server-side static site generator first. Haha, anyway, what I like about generating static sites on the server, at least for my situation, is that you can hand over control to anyone and they're immediately familiar with how it works from having used Wordpress or some such for years.
I won't like to mine because it's still full of code written for the original use case but mine started as a blog engine for a few of the non-technical people in my department. They needed a blogging engine but because of some stupid beaurocratic reason we couldn't use a database. So the options were to add blog posts manually and fake it, teach them to use Jekyll (that would never happen), or, what I chose, a static site generator on the server that no one would ever think is a static site generator. They love it and think I'm a genius (and it only consists of like 3 files which I think is funny).
I won't like to mine because it's still full of code written for the original use case but mine started as a blog engine for a few of the non-technical people in my department. They needed a blogging engine but because of some stupid beaurocratic reason we couldn't use a database. So the options were to add blog posts manually and fake it, teach them to use Jekyll (that would never happen), or, what I chose, a static site generator on the server that no one would ever think is a static site generator. They love it and think I'm a genius (and it only consists of like 3 files which I think is funny).
This is an interesting idea. I have a wordpress blog and would be very interested to switch to static. However, my wife uses the blog and really needs something more WYSIWYG than markdown.
Be sure to share when you've finished.
Be sure to share when you've finished.
I really like Middleman for my static websites because of the livereload support: http://middlemanapp.com/
I still prefer LAMP. One trick to improving cache on LAMP is converting or caching files into HTML. I know there are a number of templating engines like Smarty out there that will do just that, but what I mean is actually converting dynamic parts of the site that only change when an admin writes new content. Convert those pages into static HTML files when the admin adds new content, etc.
For example, a number of ecommerce website run off shopping cart systems that use a database. Why not have them convert into a HTML version of the site after the admin adds new products, edits products, ect. That would take a huge load off the server and database.
For example, a number of ecommerce website run off shopping cart systems that use a database. Why not have them convert into a HTML version of the site after the admin adds new products, edits products, ect. That would take a huge load off the server and database.
You can do that with nginx very easily with the Proxy module. Something like this http://mark.ossdl.de/2009/07/nginx-to-create-static-files-fr...
Anyone have thoughts on deploying static sites to S3?
I have a few static sites and single-page JS apps, and right now I just serve them with Nginx off a shared server. I've tried looking for a definitive answer on "Where should I host static sites?" but it hasn't appeared yet.
I have a few static sites and single-page JS apps, and right now I just serve them with Nginx off a shared server. I've tried looking for a definitive answer on "Where should I host static sites?" but it hasn't appeared yet.
Easiest option would be to use GitHub pages - http://pages.github.com/
But if you prefer to have more control and availability, you can use S3. Punch makes publishing process to S3 really easy - https://github.com/laktek/punch/wiki/Publishing-a-Site
But if you prefer to have more control and availability, you can use S3. Punch makes publishing process to S3 really easy - https://github.com/laktek/punch/wiki/Publishing-a-Site
I've been playing around with something around this lately, and have found that S3 works pretty well as-is - throw your stuff into a bucket, configure it for a website, and you're pretty much done. The performance is acceptable (IMO) and it's cheap (12c/gb transferred, about the same per gb stored/month). You don't really get too much control though (though you can set bucket policies that IIRC can filter on IP, referrer, host headers).
At the moment, I've gotten to the point where I have Varnish running on an EC2 micro instance serving data from S3 (I have a couple of reqs that prevent S3 from supporting my usecase out of the box [mostly to do with having too many buckets, not being able to use bucket folders]). There are issues I need to resolve with invalidation as well as the latency of the first request with this approach, but it does look promising.
At the moment, I've gotten to the point where I have Varnish running on an EC2 micro instance serving data from S3 (I have a couple of reqs that prevent S3 from supporting my usecase out of the box [mostly to do with having too many buckets, not being able to use bucket folders]). There are issues I need to resolve with invalidation as well as the latency of the first request with this approach, but it does look promising.
I have an Octopress site that I generate locally and sync up to S3, this blog outlines how to get it setup. Once you've created the Rake task it's as simple as "rake deploy" and everything is uploaded to S3.
http://blog.jacobelder.com/2012/03/deploying-octopress-to-am...
http://blog.jacobelder.com/2012/03/deploying-octopress-to-am...
S3 is fine, except that dealing with anti-hotlinking through bucket policies has been unsuccessful at least for me now. But if that's not a concern, I say go for it.
You'll have to write or pay for a tool to push your posts to Twitter, though. It can also be a bit of a bummer to not have an ID to map to shorturls and such.
You'll have to write or pay for a tool to push your posts to Twitter, though. It can also be a bit of a bummer to not have an ID to map to shorturls and such.
I was just experimenting with it now, actually. If you're willing to accept that you have to use a subdomain it should work fine. Just set up your S3 bucket to host a website, set the index and error documents properly, and set www.yoursite.tld to a CNAME pointing at the website domain S3 generates for you.
It works, is cheap and pretty simple. Using cloudfront (the CDN) in front of S3 gives you much better performance.
http://aaronblohowiak.com/blog_posts/using-amazon-s3-and-clo...
http://aaronblohowiak.com/blog_posts/using-amazon-s3-and-clo...
I experimented with S3 but found Rackspace CloudFiles better for my needs. S3 does not serve content compressed, where CloudFiles does. CloudFiles is automatically served through an Akamai CDN, while S3 can be served through CloudFront but needs configuration to do so.
https://www.nearlyfreespeech.net or even github pages ?
This trend, hosting blogs on static html, is kind of ironic, given how popular it is among developers. I can't make up my mind whether it's some sort of hipsterish-nostalgic thing, a general distrust of running other people's dynamic blog code, or just plain Occam's razor (stick to barebones).
On of the main reasons I like static site generators so much is that it makes maintaining a website more like developing software. I have 'sources', which I keep in a Git repo for powerful versioning, I 'build' the website from the sources, and then I 'publish' the final product... which is the user facing HTML website.
Developers just find that workflow sublime, and since we're often making websites for ourselves or for our companies, it only makes sense that we've started to use tools that fit our mentality.
Developers just find that workflow sublime, and since we're often making websites for ourselves or for our companies, it only makes sense that we've started to use tools that fit our mentality.
For me, it's a way of avoiding having to trust / pay for someone else's server, but also avoid worrying about keeping my wordpress install up to date.
I had a little blog I posted to every few months, and one day I found it vandalised from my out of date wordpress.
I had a little blog I posted to every few months, and one day I found it vandalised from my out of date wordpress.
I think this is a huge reason for the popularity of static blogs. For dynamic blog software, your choice is basically WordPress. Unfortunately, WordPress has a pretty bad security track record. Things might be different if there were a reliable second-place blogging engine, but as far as I know there isn't.
Another reason is the rise of version control for small projects, and the way static sites fit nicely into a Git workflow.
Another reason is the rise of version control for small projects, and the way static sites fit nicely into a Git workflow.
I use DotClear instead of Wordpress for the blog of a local non-profit, and it's nice, and according to them, easier to manage.
There is nothing "hipster" about it, it's a perfectly valid technical decision for someone who doesn't want to fuss with a janky, complicated WordPress installation or writing raw markup for each blog post or writing their own CMS. Frees up more time for developing things which are of any actual interest.
It makes getting good, scalable performance basically trivial. Static content distributed across CDNs means someone else solves that problem for you at low cost. Forget SQL injections and usually forget XSS. If you need a comments section, you realistically need outside help to filter out spam anyway, might as well use something like Disqus. Also, very few moving parts to break after deploy.
It makes getting good, scalable performance basically trivial. Static content distributed across CDNs means someone else solves that problem for you at low cost. Forget SQL injections and usually forget XSS. If you need a comments section, you realistically need outside help to filter out spam anyway, might as well use something like Disqus. Also, very few moving parts to break after deploy.
It is popular among developers because:
- you can source control your blog content
- update your blog without ever leaving command line terminal or having to use less productive web interface
- use markdown, textile, html or whatever suits you
- easy to host and easy to scale
- no need to feel obligated to apply security patches
For me these are great reasons to migrate away from WordPress, Drupal and so on.
- you can source control your blog content
- update your blog without ever leaving command line terminal or having to use less productive web interface
- use markdown, textile, html or whatever suits you
- easy to host and easy to scale
- no need to feel obligated to apply security patches
For me these are great reasons to migrate away from WordPress, Drupal and so on.
Yet all of these (but scaling) could be subserved by a dynamic website. Static sites have drawbacks too:
- Hard to create feeds
- Search is left to google
- Mostly impossible to use for photoblogging and anything that requires mobile
etc.
- Hard to create feeds
- Search is left to google
- Mostly impossible to use for photoblogging and anything that requires mobile
etc.
Why would it be hard to create feeds? It's just a matter of adding a template and letting the static generator create an XML file from the same content.
I was developing a (java|coffee)script-only full text search engine (not just some simple regex match, but something memory efficient with succinct data structures) to have an answer for search, but than it occurred to me that I rarely, and in general never, use search on someone else's blog.
A static site on s3 or similar is essentially infinitely scalable: you never have to worry about whether it can stand up to some publicity and its performance will always be snappy no matter what. It's cheap. It's controlled in source control and backed up. Achieving those same things using other configurations instead of static files takes an order of magnitude more work and complexity.
Fair, but most programmers blogs have very little traffic
Until you write a post that ends up on the front page of HN and it brings your server down. The chances of that happening are small, so it's probably not worth optimizing a dynamic site for that use case, but with a static site you don't have to do any additional work or introduce complexity.
I am not a developer and I don't grow my own food or use typewriters (much).
My small vanity site has an update once a month or so. I use Linux at home. I hacked a few bash scripts to get a basic flow going...
What I do find amusing is the range of really heavy duty technology that some of the static Web site generators are using.
My small vanity site has an update once a month or so. I use Linux at home. I hacked a few bash scripts to get a basic flow going...
* edit text file with markdown (vim or gedit). Save to a directory in dropbox that has images and files under it
* run a script that runs markdown and adds a header and footer
* run a script that adds the new page to an index
* run a script that invokes lftp that uploads the changed files to server space
What I do find amusing is the range of really heavy duty technology that some of the static Web site generators are using.
It appears to me that your workflow is missing several pieces. You are missing RSS, which will keep some people from following what you write on your website. You are missing a sitemap.xml file, which search engines care about. You could add support for these to your work flow, but they are pieces that require very little work to enable support for in wordpress (RSS is just there, and sitemap just requires enabling the add-on), and I presume are trivial to enable in some of the static generators like jekyll or hyde.
Neither of these technologies are in my use case, but rss would be easy to add, so I'll have a look, thanks.
Personally I wrote my own markdown-rendering static blog because it was something to do. I've stuck with it because I prefer the workflow to a more dynamic application.
Previously on HN about 195 days ago : http://news.ycombinator.com/item?id=3877954
But why the repost - I ask? The last time it was arunoda, who seems to be a friend.
As somebody who'd love to post a pet project on HN sometime in the hopefully-not-too-distant future, I sorta get that you might want people to try your software and that maybe you'd like more eyeballs than you got the first time around; but couldn't you be explicit about it? I'm sure that something like "Guys, I know this has been posted before, but I'd like you look at it once again" would be more welcome and transparent.
Update: I read through the comments on that thread. THAT was a repost. This is the original: https://news.ycombinator.com/item?id=3862269 (199 days, poster: you)
Whats going on? Have you changed anything since then that you'd like to highlight?
But why the repost - I ask? The last time it was arunoda, who seems to be a friend.
As somebody who'd love to post a pet project on HN sometime in the hopefully-not-too-distant future, I sorta get that you might want people to try your software and that maybe you'd like more eyeballs than you got the first time around; but couldn't you be explicit about it? I'm sure that something like "Guys, I know this has been posted before, but I'd like you look at it once again" would be more welcome and transparent.
Update: I read through the comments on that thread. THAT was a repost. This is the original: https://news.ycombinator.com/item?id=3862269 (199 days, poster: you)
Whats going on? Have you changed anything since then that you'd like to highlight?
Yes. This was not actually a project announcement, but a tutorial published on Appliness.
Of course, there had been lot of new features and changes to the process since the initial release.
Also, it's up to you to decide whether to vote it to the frontpage or not.
Of course, there had been lot of new features and changes to the process since the initial release.
Also, it's up to you to decide whether to vote it to the frontpage or not.