Why?

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

Eh, ev­ery­body al­ready heard this. Old man yells at cloud. Com­plain­ing that be­fore a web­page had 50 kB, now it has 5 MB, still tak­ing ten sec­onds to load, even though the con­nec­tions are hun­dreds times faster. But why is that? Be­cause no­body cares.

I am a GPU de­vel­op­er. My usu­al Mon­days are about hav­ing a hand­ful of mil­lisec­onds to do com­plex im­age pro­cess­ing in re­al time. So I am fu­ri­ous if a page that presents main­ly text takes sec­onds to ap­pear on my screen. And I would de­spise my­self for pre­sent­ing GPU-re­lat­ed con­tent us­ing such tools. So I made this thing. This thing has no JavaScript, just a few kilo­bytes of pure CSS and is meant to be used with stat­ic site gen­er­a­tors.

Why no JavaScript?

Re­spon­sive page lay­out? Yes! Pop­up menus? Check! Ex­pand­ing ham­burg­er nav­i­ga­tion? Sure! With pure CSS fea­tures, sup­port­ed for years by all browsers. The goal of this frame­work is pre­sent­ing con­tent in the most un­ob­tru­sive and light­weight way pos­si­ble — if you are look­ing for some­thing that would dis­play a spin­ner while the megabytes are load­ing, some­thing that can open a “SIGN UP” pop­up on page load or in­ter­rupt the read­ing ex­pe­ri­ence with a noisy full-page ad ev­ery once a while, this is not what you are look­ing for.

Why no CSS preprocessors?

The stylesheets con­sist of on­ly three files, writ­ten in pure CSS. No CSS pre­proces­sor need­ed — in my ex­pe­ri­ence the main rea­son for a pre­proces­sor was an abil­i­ty to use vari­ables, but that’s im­ple­ment­ed 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­fi­ca­tion — serv­er-side com­pres­sion is sim­ply 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 pre­sent­ing web­sites. So re­move the un­need­ed has­sle 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­i­can, m.css pro­vides a so­lu­tion har­ness­ing the end­less pos­si­bil­i­ties of your lo­cal ma­chine to gen­er­ate a bunch of stat­ic HTML files, which you can then up­load any­where. And as a bonus, 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 Python and while I’m prob­a­bly not very good at it (hav­ing spent over a decade writ­ing pure­ly C++), I want­ed to fi­nal­ly put it in­to prac­ti­cal use, in­stead of learn­ing a com­plete­ly new lan­guage. There I al­so dis­cov­ered re­Struc­tured­Text, which, com­pared to var­i­ous fla­vors of Mark­down, is very well thought out, amaz­ing­ly flex­i­ble and eas­i­ly ex­ten­si­ble to sup­port ev­ery­thing I need.

Why the name?

To un­der­line that this project is driv­en by a need for a sim­ple, tiny, name­less low-main­te­nance thing to pow­er my web­sites. That my fo­cus is on pre­sent­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 Great­est Web Frame­work Ev­er™.