Why you should build a static site with Silex

At the beginning of the summer we decided to redo our website. The design on the old site was looking a bit dated and more importantly the content didn’t really reflect the types of projects we’re looking to work on. From a technology perspective, our old site was built on WordPress with the explicit goal of being able to share the same WordPress theme as our blog. The two sites did in fact share the same theme but looking back, we never updated the main site to really make it “worth it”. With that experience in mind, we started looking around for what we could use to build

Stepping back and looking at our requirements, we really don’t need a CMS. I’d argue this holds true for most website projects when there’s less than 20 pages, everyone who might edit it is technical, and the content isn’t updated frequently. Specifically looking at some major WordPress features, we don’t need the WYSIWYG editor, plugin ecosystem, media handling, or theming capabilities. So what capabilities do we need?

  • Routing / Pretty URLs:
    Serving “raw” URLs like “about.php” hasn’t been OK since IE6 so this is obviously a “must have”. Basically, we need some way to map human readable URLs to specific pieces of content. Sure, you could do all of this with mod_rewrite or nginx’s location directive but that just sounds awkward. Whatever we pick should be able to handle these translations internally.
  • A modern templating engine:
    PHP “grew up” as a web templating system but today it’s missing some key features in comparison to purpose built templating engines. Being handicapped by only having “require” or “include” and being forced to set global variables in 2014 is terrible so “real” templating should be a requirement.
  • Access to a CGI/scripting language:
    I’m sure there’s “razor” of some sort describing a phenomenon where eventually a “static” website will need access to dynamic capabilities. For us, from the outset we knew we’d need to do things like pull in RSS feeds and send contact emails so we knew we needed access to some sort of CGI.

There’s certainly more capabilities static websites could need but I think this is a decent list for the “general” case and it captures our requirements. After doing some research, it looks like there’s currently a few options that would satisfy these requirements:

  • Static site generators: Generally, products like Jekyll or Phrozn will “compile” a set of your templates into static HTML pages which would then just be served by Apache or nginx. These solutions are fine except that they’d make things like integrating a RSS feed awkward.
  • “Lightweight” CMS: There’s a slew of “lighter” WordPress alternatives like Apostrophe or Ghost that check all the boxes but come with their own issues. With any “platform” you’d be back to learning the quirks of another platform and of course keeping the software up to date.
  • Use a micro-framework: Frameworks like Sinatra or Silex would offer the templating and routing features found in a “full framework” without the associated code footprint. In my opinion, this option offers the best combination of familiarity, extensibility, and a small enough footprint that updates shouldn’t be a huge issue.

I ultimately chose Silex because our team has deep PHP experience, especially with Symfony2. Because of that we’d be right at home with the Routing component and of course Twig for templating.

OK so how do you actually get this to work? I ran across Jonathan Petitcolas’s Building a static website with Silex post and used it as a guide. Here are the actual commands you’d need to get this all setup though:

Now, you just need to create a file named “index.php” which contains:

And finally, in the “views” directory add a file called “index.html.twig” which contains some content. If you have a web server setup, just point a vhost at the “web” directory, load it, and you should see the content of your index file.

If you don’t have a web server setup, a nifty trick via Gonzalo Ayuso, create a in the “web” directory named “router.php” containing:

And now, you can start the built in PHP 5.4+ server by running:

You can load your Silex app by loading http://localhost:8888 in your browser.

Anyway, as always questions and comments are welcome!

Posted In: PHP

Tags: , ,

  • Nadir Boussoukaia

    Except that…Silex is not a microframework. Saying this is really a complete intellectual sham.
    I think you should replace Silex by Slim or Fatfree in the title.

    Judge by yourself through SLOC(=source lines of code):
    – Slim 22 files/2630 SLOC (most popular Microframework)
    – FatFree (15 files, 3998 sloc)
    -> Silex: 296 files/18054 SLOC
    Most of Microframeworks are below 5000 SLOC

    and for static sites there is jekyl

  • Honestly I don’t care how many SLOC a “framework” is. I’m more concerned about the number of dependencies, the community surrounding those, and how easy it is to extend the project if need be.

    Looking at Slim, you’re stuck writing your templates in vanilla PHP which isn’t great. FatFree has a custom templating engine so there’s a learning curve there. Jekyl is great but my impression was that dropping into straight Ruby to do things like pull in an RSS feed would be painful.

  • Creating Atom or RSS feeds for static site generators should be as easy as creating another page that generates XML instead of HTML output. I’m doing that for Sculpin for That Podcast’s iTunes feed:

    Full disclosure: I’m the creator of Scupin (

  • Doh, I actually meant displaying the posts from a RSS feed on the site – like “recent posts” on

    Looking at Scupin though, it looks like it would be possible to do that by writing a custom Generator which is awesome.

  • Ah, yeah. That is a little different.

    Sculpin still has some rough edges around it but people are doing some interesting things already. :) Right now there is an open PR to try and add the ability to inject data providers globally which would make doing something like you are suggesting pretty trivial.

    The downside of using dynamic data on every page of a static site is that it requires rebuilding *the entire site* every time you change any of the posts. So although it is possible I’m not sure people would really be happy with the performance. :) So although it might be possible someday very soon I’m not sure how many people will actually want to use it.

    Static generators are nice but sometimes they don’t work like you want. A big reason I started working on Sculpin was for many of the reasons you list here about not wanting to drop down to use Ruby to extend it. Jekyll is a great tool and keeps getting better but at the end of the day it is still a Ruby app and if you’re someone who leans in the direction of PHP having a PHP tool makes a lot of sense if you really have to hack it.

    I’m a fan of Silex, too. :) That is the main reason I ended up here!

  • Ah cool. Thinking about it a bit I guess I should of titled this “mostly static” site.

    Looking at the RSS example, its just our blog and we know it isn’t updated all that frequently so in the worst case we could just rebuild the HTML for the site every night.

    Jekyll is definitely cool – we’ve used it for GitHub Pages but like you pointed out, when you inevitably have to send an email from the “mostly static” site it it’ll leave you in an odd spot.

    Anyway, thanks for stopping by! I’ll definitely keep an eye on Sculpin.

  • Nadir Boussoukaia

    As you like.
    But definetely, Silex is not the right choice for static sites. is.
    there is a php clone:
    (there exist several in PHP :

  • Nadir Boussoukaia

    sculpin fits better obviously.