Eleventy is a Static Site Generator.

What does that mean?

Benefits of a SSG:
Speed — Faster load times — no parsing of server side scripts
Simplicity — Easy to deploy — no server configuration, just upload
Security — Can lock down — nothing exposed on website to exploit server side
Savings — Can be run on cheap shared hosting, even free services like Netlify

Let’s take a look at Eleventy:

https://11ty.dev

The first claim — “Eleventy is a simpler static site generator”
Simpler compared to what?

Some popular alternative SSGs include:

Jekyll – Ruby, you’ll need to install a Ruby development environment — and keep it up to date
Hugo – Go language, but you don’t need to have Go installed because it is a static binary — a command line application

On the Javascript site, like everything else, rather than a community coalescing around a single solution there are many alternatives. Which may be good, since it results in experimentation with different methods.

You can see an exhaustive list of SSGs at:

https://www.staticgen.com/

Javascript SSGs tend to coalesce around client-side frameworks, React, Vue, etc.

Popular React based frameworks:

Gatsby – react based
Next.js. — with server side component

React frameworks allow you to use React components and compose them with JSX and then use those components to create a static site. But with a twist that they “rehydrate” a rich client side framework (React) based application.

Vue based SSGs include:

Nuxt.js — inspired by Next.js
Gridsome — inspired by Gatsby
Vuepress — designed for generating documetation based sites, developed by Evan You, the creator of Vue.js and used for the Vue.js documentation

These Javascript frameworks are more heavyweight clients. While they are “static” in the sense that they don’t have a server side component, they’re really more of a “JAMstack” application.

JAM means “Javacript and Microservices” — or rather “Javascript, APIs, and Markup”) meaning that a web application is more like a mobile app, the presentation logic is all handled on the browser, which builds an app using the browser’s Javascript engine, and then fetches data by calling and changes the presentation by adding and subtracting components from the DOM.

The DOM is the “Document Object Model” — how the browser keeps track of your HTML programmatically and renders it. When you click a button, the browser fires an event that maps to the DOM element. Changing the DOM — adding and removing HTML elements dynamically, and attaching events such as “onclick” to elements to trigger those changes or to make AJAX calls to fetch data from the server.

AJAX is “Asynchronous Javascript and XMLHTTPRequest”
XMLHTTPRequest is the way that browsers can fetch data from a web server — like loading a page, but without reloading the page.

That’s the basis of Javascript client-side frameworks like React, Angular, and Vue. A bunch of logic, written in Javascript to execute on the browser, renders in the browser to add and substract elements, fetch data, and update status with the server — all without doing full page loads.

The benefit of doing this — at least theoretically — is that you don’t have to send as much information back and forth from the server to the client on every request. Rather than sending the tags and so forth — as well as all the other elements that don’t change, including images, JavaScript, and CSS, you just send the data that changes, and then update the DOM accordingly.

In practice, well… often the load isn’t that heavy, and static assets like images & libraries are cached on the browser anyway. And updating the DOM via Javascript events can take more time and resources than just re-rendering HTML. But still, client side frameworks give people a way to organize the logic of complex sites, and compose them programmatically.

[Aside] I’m somewhat ambivalent on client side frameworks, but that may be because I haven’t explored them deeply enough, or that I just haven’t found one that’s implemented in a way I like.

Eleventy is also a Javascript based SSG and it would be familiar to someone using Jekyll or Hugo. It was inspired by Jekyll. It doesn’t try to be a full stack Javascript solution, and that’s where the “simpler” claim comes in.

The other claim that Eleventy makes is flexibility. It is agnostic about the template language you use, for instance. You can use Liquid — the template system used by Jekyll (and Github Pages) by default, but you can swap that out for several other Javascript based templates, such has Nunjucks (very similar to Liquid), Handlebars, Mustache, HAML, Pug, or EJS. You can even use plain Javascript objects to “render” content — so you can use programmatic logic and composition to build elements or pages or partial pages. Much the same as you would building Vue or React components. It may even be possible to process React components to generate a static site with Eleventy, although I don’t know if anyone has done it.

Most people who choose Eleventy do so for simplicity and flexibility, so getting tied into a complex framework isn’t their goal. If you prefer one of those, you’re probably better off using one of the other SSGs geared specifically for your framework.

Eleventy is designed to work with static HTML files, and then add simple logic —
conditionals: “if this is true, then display it”
iteration: “render an element for each item in a list”

Another feature of Eleventy (and other SSGs like Jekyll) is that it allows you use plain text files — actually Markdown — and generate HTML pages from them. That way you can write a blog, or documentation, or whatever, by composing a simple text file, with a bit of simplified markup for headings, lists, and so forth, and then add a header, footer, sidebar, etc. and then display them as web pages without having to add all the tags. Or — and here’s the key — without having to use a content management system (like WordPress) and edit all your content in a fancy textarea — and save it to a database.

In the next post, we’ll go ahead and jump in and see how that works.