Last night (February 13, 2015) I presented at the Boston Node.js Meetup hosted by LogMeIn. I shared an approach I’ve used working to build a static site engine using Node.js for MIT Technology Review. It was a fun experience, I hope to do it again in the future.
Resources
- Slide deck
- Gist snippets
- Project repo (similar system available for cloning)
Transcript
Introduction
This script loosely described what I set out to cover during the talk. It’s not an accurate transcript of the spoken words shared, but the core concepts and structure should still provide value.
Hello, I’m Kevin Leary and I’m a front-end engineer at MIT Technology Review where I write code for technologyreview.com, among other things. Tonight I’ll be presenting a few aspects of a simple static site engine we’ve built with Node + Express.
If you’re familiar with the open-source project Jekyll this is similar. This is currently running on styleguide.technologyreview.com if you want to take a look.
Goals
Initially we had a few goals we wanted to achieve:
- We wanted an easy way to provide international partners with MIT branding and style guidelines for the web
- We wanted it to be as easy as possible for our tech team to write, edit and release additions and modifications
- Once launched, we ideally wanted it to have no maintenance beyond the content
So let’s take a look at how it works.
Routing & Views
We used Express.js to route URL’s to corresponding layout and (sub)templates. For example, visiting “styleguide.technologyreview.com/elements” will load our main layout template, “layout-simple.html”, with “elements.html” included in the main content area (if it exists in the file system). This gives us the ability to rapidly add new pages because the URL directly determines the name of the “content” template that will be used.
Templating
After nailing down the routing logic we needed a way to parse Markdown syntax in our (sub)templates. In order to do this in an efficient way we needed a template engine that provided the flexibility to process this markdown before compiling and caching the final HTML.
Swig proved to be the perfect choice. Swig provides us with the ability to create our own custom template tags and filters in order to customize the HTML output of a template before sending it to cache and subsequently the browser. This serves the HTML parsed from our markdown to the browser fully cached.
Markdown
We chose to use Markdown because it’s a very portable way to write content, and everyone on the team loves it. We went with the GitHub flavored syntax so that we could easily add code blocks to our content.
Combined with the routing approach we discussed this system provides a lean way to map a URL to a specific Markdown template.
In summary, that’s really the core concept of what’s going on here.
Environments
We’re currently hosting this style guide for free at Heroku, which provides us with a very simple approach to hosting a production node instance on the cheap.
Locally we’re using Gulp with Nodemon to:
- Compile, concat and compress LESS, CSS and JS
- Reload the Node server when code changes occur
- Run a LiveReload server for instant browser updates
Thanks!
Thank you so much for listening, I hope you enjoyed it. If you have any questions I’d be happy to chat with you after this. Code samples and the slide deck are all open-source, you can find them online at the following links. I can also be found online at kevinleary.net