Keeping Things Simple with Sculpin

Earlier this week I had the pleasure of learning about Sculpin, a sweet PHP tool, from Ben Benesh at the local PHP meetup. Sculpin is a static site generator that takes a bunch of Twigs and/or Markdowns and compiles them into a set of static HTML files for easy deployment. There are some rather cool features, like how the tool has composer dependencies and leans on Symfony's Kernel and has some great shell scripts for easy rsync. The idea behind it, though, is what really got me thinking.

PHP developers (and the general web community) have an unhealthy obsession with complex frameworks. The vast majority of websites out there are little more than a handful of HTML pages, images, and styles, yet we need to build it in ( Wordpress | Symfony | Joomla | etc ). I've seen countless examples where a simple discussion on project specifications and client needs are hijacked by considerations of 'which tool to use' without the briefest consideration on whether or not the client will effectively use it.

Now, I'm not saying that dynamic, CMF-powered sites are bad (after all, I build them for a living). However, I do think that there are really only three good reasons why a website needs to be more than just flat files.

1. Client needs to update the site frequently
   Frequently is a tricky word to use here. Borrowing a string of logic from good ol' master/slave replication systems, its best to compare the number of 'read' vs 'write' hits. A client updating their site (write) a few times a week might sound like a lot, but compared to possibly hundreds (or, possibly thousands) of web visitors (read) per day those few updates are relatively insignificant. Having a hefty tool that renders every page load is overkill for the vast majority of users. If the client is very concerned with full control over the content and real-time updating, though, they may need a CMF.
2. Developer-related concerns
   There are a few (semi-selfish) reasons why the development team may push for using a pre-built framework. There could be concerns about budget, timeline, or even just a certain comfort level. These concerns are valid, though they should be weighed against the long-term debt of over-building a website.
3. Complex web applications
   Some websites are just too complex for flat HTML/CSS/JS. There could be security levels, form processing, data crunching, or some other task that the application needs to do that flat files just can't handle.

Sculpin, and tools like it (Jekyll for the Ruby-inclined), provide a nice solution to the first and second reasons. They offer plenty of shortcuts for developers to shave off redundant steps while offering a possible method for clients to update the site. That is, if the client has a tool that outputs Markdown files and an environment that can detect and publish changes. The benefits of this setup are amazing - serving up flat files from a web server is crazy fast compared to hefty code stacks and with great simplicity comes, well, less errors and concerns.

Again, the main thought process is what will stick with me the most. After years of working in full stacks its easy to forget just how simple a website can be. If a tool is slowing down development time, slowing down response time, or complicating things for the end user, than it probably isn't worth using. Whether going all the way down to flat files via Sculpin or utilizing a handful simple scripts, sometimes the simple approach is better.