Why?

Let’s start with some his­tory. Back in 2002, when I star—

Eh, every­body already heard this. Old man yells at cloud. Com­plain­ing that be­fore a webpage had 50 kB, now it has 5 MB, still tak­ing ten seconds to load, even though the con­nec­tions are hun­dreds times faster. But why is that? Be­cause nobody cares.

I am a GPU de­veloper. My usu­al Mondays are about hav­ing a hand­ful of mil­li­seconds to do com­plex im­age pro­cessing in real time. So I am furi­ous if a page that presents mainly text takes seconds to ap­pear on my screen. And I would des­pise my­self for present­ing GPU-re­lated con­tent us­ing such tools. So I made this thing. This thing has no JavaS­cript, just a few kilo­bytes of pure CSS and is meant to be used with stat­ic site gen­er­at­ors.

Why no JavaScript?

Re­spons­ive page lay­out? Yes! Popup menus? Check! Ex­pand­ing ham­burger nav­ig­a­tion? Sure! With pure CSS fea­tures, sup­por­ted for years by all browsers. The goal of this frame­work is present­ing con­tent in the most un­ob­trus­ive and light­weight way pos­sible — if you are look­ing for some­thing that would dis­play a spin­ner while the mega­bytes are load­ing, some­thing that can open a “SIGN UP” popup on page load or in­ter­rupt the read­ing ex­per­i­ence with a noisy full-page ad every once a while, this is not what you are look­ing for.

Why no CSS preprocessors?

The stylesheets con­sist of only three files, writ­ten in pure CSS. No CSS pre­pro­cessor needed — in my ex­per­i­ence the main reas­on for a pre­pro­cessor was an abil­ity to use vari­ables, but that’s im­ple­men­ted in CSS it­self with uni­ver­sal sup­port across browsers, so why both­er? Be­sides that, the files are so small that there’s no need for any mini­fic­a­tion — serv­er-side com­pres­sion is simply good enough.

Why a static site generator?

If you are like me, you want a web­site that presents your main work, not that your main work is present­ing web­sites. So re­move the un­needed hassle of pay­ing ex­tra for a dy­nam­ic web­host­ing, in­stalling and main­tain­ing a huge CMS and patch­ing it twice a month for a nev­erend­ing stream new CVEs. To­geth­er with Pel­ic­an, m.css provides a solu­tion har­ness­ing the end­less pos­sib­il­it­ies of your loc­al ma­chine to gen­er­ate a bunch of stat­ic HTML files, which you can then up­load any­where. And as a bo­nus, you have the full con­trol over your con­tent — noth­ing’s hid­den in opaque data­bases.

Why Pelican and not Jekyll or …?

I love Py­thon and while I’m prob­ably not very good at it (hav­ing spent over a dec­ade writ­ing purely C++), I wanted to fi­nally put it in­to prac­tic­al use, in­stead of learn­ing a com­pletely new lan­guage. There I also dis­covered re­Struc­tured­Text, which, com­pared to vari­ous fla­vors of Mark­down, is very well thought out, amaz­ingly flex­ible and eas­ily ex­tens­ible to sup­port everything I need.

Why the name?

To un­der­line that this pro­ject is driv­en by a need for a simple, tiny, name­less low-main­ten­ance thing to power my web­sites. That my fo­cus is on present­ing con­tent with it, not on shift­ing my ca­reer back to web de­vel­op­ment to flesh this thing out to be the Greatest Web Frame­work Ever™.