Static Site Generators?

What’s a dynamic site?

A dynamic site runs a server side scripting language(PHP, Rails, Pearl) to dynamically create the page being requested by each user. The pages on your WordPress-powered blog are built on the fly! Database queries are run to get the different pieces, such as the title, content, or links. These are then returned and processed by PHP for EACH request. Every time a user visits one of your pages fresh HTML, styled by CSS and made fancy-shmancy by JavaScript, is built and served to the user.

In any app, or any part of life, there’s always a problem/limitation. What’s the problem with this? The problem is if you have one particular page getting requested again and again, and nothing is changing on the page itself, all that dynamic creation of that page over and over… can lead to resource usage problems on the server. Let’s say for instance this page you’re currently viewing is getting requested 1,000 times an hour because I dropped some gossip about Justin Bieber. Each time this page is requested the server has to run a script. It’s basically a waste of computing power!

What’s a static site?

A static website is a site in which the information stays the same over a relatively long period of time. With a static website, you simply have the raw HTML that creates your page in a file on the server. A user’s web-browser will just directly request that specific file, and all the server has to due is hand it off as is without running a script. A static website consists of a series of HTML files (that require CSS and JS files), each one representing a physical page of a website. So on static site, each page is a separate HTML file. When you visit the homepage, you are viewing the actual homepage file. Even if two pages contain a chunk of identical content, e.g. a nav-bar, they both contain the same code for the nav-bar. So, if you want to update the nav-bar, you must do so in multiple files. This is fairly straightforward and it’s how all websites were built during the early hay days of web. The days when being an HTML developer meant 6-figure salaries and high potential for start-up immortality. These days no-one will even hire you as a junior developer without a fundamental understanding of multiple languages and frame-works. With my current web-dev skills, I could have probably freelance consulted for Fortune-500 companies in the early 90’s…. sigh, Anywayz.

How are they different?

Static site generators like Jekyll read some local configuration files, and build all of the HTML, CSS, and JavaScript on your local machine before deploying everything to your remote server. This actually makes your server administration much easier, safer, and faster.

Browsers read HTML, CSS, and JavaScript natively. Every other language is used to generate these three types of files. Static sites are created from hard-coded static files that do not rely on any server processes (unlike PHP, Ruby, Python or any other server-side language). Jekyll, a very popular static site generator, relies on the editor’s local environment to generate the static files that will eventually be deployed.

Wait… What?
Say, for example, you have five blog posts in your WordPress blog. When you visit, excerpts from these five posts show up on your home page. You click on a link to take you to the full post page. Each of these pages is served to your browser as HTML, styled by CSS; you may or may not have JavaScript that helps define some interactive behaviors. But every time you/user visit each page a PHP script in being run on the server.

What are my options for a static site?

Too many to list but here are some of the ones I find interested.


Jekyll is a parsing engine bundled as a ruby gem used to build static websites from dynamic components such as templates, partials, liquid code, markdown, etc. Jekyll is known as “a simple, blog aware, static site generator”.

Octopress is a static blogging framework built on top of Jekyll. It uses scripts to build static files to be deployed to a server.

If you’re looking for sheer performance, Hugo should be at the top of your list. It has plenty of features, but its biggest draw is that it’s built with Go — a language famous for its speed. If I were starting a blog with a frequent publishing schedule and the expectation of thousands of pages, I’d choose Hugo.

Hexo is a fast, simple and powerful blog framework powered by Node.js, that supports multi-thread generating, so hundreds of files take just seconds to generate. Your posts are parsed with Markdown which then generates static files, with installation taking just a few minutes.

I’m a Ruby on Rails developer, so tools like Jekyll and Middleman are super attractive to me. If, however, you’re a Python kind of girl, then check out Pelican — the most popular static blog generator built with Python.

Fairly new open source tool that seemlesly integrates with GitHub pages. All you need is a GitHub account and unlike all the other blogs I mentioned, you have access to an online admin panel, where you can write your blog posts. Pretty awesome feature if you ask me.


Your First Sinatra Apps

Sinatra is a DSL (domain-specific-language) for building websites, web services, and web apps in Ruby. A DSL is usually dedicated to solving a particular type of problem. SQL (structured query language) is another example of a DSL. SQL is used to facilitate interaction with relational database systems.

Sinatra is not a Framework like Rails. It doesn’t come with a pre-fabricated file structure or even a project folder. Sinatra is a lean language and is being used by companies like GitHub, Heroku, BBC, ThoughtBot, and Songbird.

The two main approaches to building Sinatra apps are classic and modular. In classic mode you just require Sinatra and start defining end-points. Classic applications are often single-file, standalone apps that are run directly from the command line or with a minimal rackup file. In modular mode you explicitly subclass Sinatra and build your app within that scope. You would take a modular approach if you wanted to build many small apps within a parent app. Think about mixins in Ruby, they’re just little modules(blocks of code) you can use throughout your app or you can have an entire app of just interacting mixins!

So why not use Sinatra for all of your apps and be done with it? Every technology has it’s place. Sinatra is usually reserved for smaller apps. If you want to build the next WordPress you could theoretically do it in Sinatra but using Rails would be more appropropriate. Why not just learn Rails from the outset? Same reason you probably shouldn’t try learning JavaScript as your first programming language. Learning Ruby is more practical and gives you a fundamental grasp of using a language to communicate with a machine. I’m so glad I learned Ruby before tackling other languages. Sinatra is less robust and is great warm-up for learning Rails.

So how do you install Sinatra? Easy! Type gem install sinatra anywhere in your command line. You should also install the Thin web server by typing gem install thin. Why Thin you ask? Thin is a Ruby web server that glues together 3 of the best Ruby libraries in web history:

  • the Mongrel parser, the root of Mongrel speed and security
  • Event Machine, a network I/O library with extremely high scalability, performance and stability
  • Rack, a minimal interface between webservers and Ruby frameworks

Which makes it, the most secure, stable, fast and extensible Ruby web server bundled in an easy to use gem for your own pleasure.

Let’s build our first “Hello World!” App! Jump back to your command line and make a directory for your sinatra app:

Open the folder in your text editor (sublime . ) and type the following:

Now make sure the file is saved and type ruby server.rb back in your command line. By default the application will listen on port 4567 so go ahead and open your web-browser and navigate to http://localhost:4567/ Your sinatra app should respond and you should see “Hello, world!” in the top left of your browser window. Congrats! Your first Sinatra App!

So what’s this sorcery? Sinatra separates the developer from middleware called Rack. No, nothing to do with Tyga’s hit single ‘Rack City.’ Rack provides a minimal interface between web-servers (e.g. Thin) that support DSL’s. Sinatra is going to use Rack to talk to Thin (our web-server). Essentially Sinatra speaks Italian, Rack speaks Italian and German, and Thin speaks German. We have to use Rack as our translator.

Sinatra DSL syntax is typically expressed in the form: verb ‘route’ do. We’re instructing our application to respond to HTTP GET requests to the path ‘/’; our apps response (behavior) is inside of the block. So when a server (Thin) hollers atcha app, your app responds: “Hello, world!” This block is appropriately named a method call. In Sinatra, a route is an HTTP method paired with a URL-matching pattern. Each route is associated with a block:

In Sinatra Routes are matched in the order they are defined. The first route that matches the request is invoked. This means, if you have another get ‘/’ do request beneath your Hello World request, the Hello World will be the only one triggered for this ‘/’ request.


Now let’s put some of what we learned to use and build a simple Rock Paper Scissors web-app! In your command line control-c out of your server connection and rename your server.rb file to game.rb (mv server.rb  game.rb). before we start processing routes we have to set up a before block with plain text responses and a hash with all viable moves:

This code will be stored in memory before our route is processed. Let’s set up our route and set a player_throw:

The most important thing to understand in this program is the params hash, the rest of the code in our block will be basic ruby. You’ll be using params in pretty much every Rails and Sinatra program you write. The params hash stores querystring data. What the heck is querystring? A very simplistic explanation is, it’s the last piece of data in any URL (Uniform Resource Locator). A more accurate definition is: A querystring is a set of characters input to a computer or Web browser and sent to a query program to recover specific information from a database. On the Internet, a querystring (also called an HTTP querystring) is part of the set of characters automatically input in the address bar of a dynamic Web site. For example, consider the following URL:

The querystring in this example consists of one field or variable, technically called a key in this context (the word “sort”), followed by an equals sign (=), followed by the value for that key (the word “date”). A querystring may contain several key-value pairs. When there is more than one key-value pair, they are typically separated by ampersands (&). So params is just a Hash with key value pairs. And we use this hash to pass along information from one request(page) to another. This will make more sense as we finish building our first web game.

The only thing left to tackle that might seem unfamiliar is the ‘halt’ command. It’s pretty simple, processing will stop immediately once the halt command is called. The player_throw will essentially be fixed and placed at the end of your URL. The computer_throw is random (.sample). Yall should be able to work your way through the rest of the logic.

So that’s our basic game! Let’s test it. Jump back into your command line and type ruby game.rb to establish connection with your server. Once you’re connected open your browser and navigate to http://localhost:4567/throw/rock or http://localhost:4567/throw/scissors or http://localhost:4567/throw/paper . Notice how we (the player) is inputing the throw in our URL, and the computer (the program) is generating it’s own throw and comparing it with ours. Keep refreshing your browser and you’ll see different results. What do you think you can do to set off halt 403? Just type anything besides our three set inputs at the end of our URL.