Embrace the Static Web with Punch
laktek.com
laktek.com
I had a little blog I posted to every few months, and one day I found it vandalised from my out of date wordpress.
Another reason is the rise of version control for small projects, and the way static sites fit nicely into a Git workflow.
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.
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.
- 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.
- Hard to create feeds
- Search is left to google
- Mostly impossible to use for photoblogging and anything that requires mobile
etc.
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.
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.
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.
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.
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.
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'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).
Be sure to share when you've finished.
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).
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?
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.
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.
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.
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
http://blog.jacobelder.com/2012/03/deploying-octopress-to-am...
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.
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.
http://aaronblohowiak.com/blog_posts/using-amazon-s3-and-clo...
For example, here's a handlebars plugin for Punch - https://github.com/laktek/handlebars