does it mean? We’re the team behind the omnichannel strategies of Walmart, Nike, Starbucks, Hilton & many others, in Europe & China. We ship software solutions at high velocity... For tens of millions of users.
I do… a lot. I adopted it in 2009, I’ve since used it to build sites of all sizes, including more recently for Starbucks and Zalando (shush... it's a secret).
used “traditional” CMS a lot: — They’re mediocre at solving 2 problems. — They break & get hacked. — They’re hard to customize. I like simple tech, separation of concerns… and Liquid!
#1: KISS Most important thing IMHO: — Avoid adding stuff you don’t need. Example: Makefile vs. Webpack & co. — Avoid multiplying layouts; it’s fine to have Liquid code in a page. — Vanilla JS & simple Sass. — Saying no is allowed. — ...
with a proper IA Work on the information architecture early on and define: — Collections: multiple content entries with similar fields and individual pages. — Pages: individual entries (may also include Liquid templating). — Data: everything that does not require its own page (settings, arrays, tables).
are the sh*t — “Functions” (e.g. teaser). — Reusable code (GA, favicons, SEO…). — Helpers (i18n.liquid, path.liquid). Remember that includes share the variable scope of the page. And, you can pass on variables: {% include note.html foo="bar" %}
plugins Plugins are evil: — They can make things (much) slower. — They don’t work on GitHub pages. — They don’t really solve problems that can’t be addressed with vanilla Jekyll, JS or a 3rd party (e.g. i18n, rsz.io…) Also, constraints are good.
As I said, I don’t like plugins. I’ve tried several i18n plugins and none seemed to be radically more elegant than using vanilla Jekyll. What we need: — Localization to translate the UI. — Multilingual content.
— Declare your languages in your config (e.g. lang: [de, en]) — Keep translated strings for each language in its own file (e.g. _data/translations/de.yml) — Add some Liquid magic to assign the magic t variable. — Voilà!
content — Any content has a lang attribute. — Default language is at the root, translated content in a subfolder (e.g. about.md and de/about.md). — Collections have their own subfolders (e.g. _posts/de/2018-07-23-foo.md). — Translated content in collections also doubles lang with categories for non-default languages.
— For collections, folders are “invisible”. — Permalinks can’t use custom attributes. — Permalinks look like /:categories/:title/, with :categories being a merge of categories and category (in that order). — You can still use category for actual categories (works with arrays). — We use lang to filter content: {% assign posts = site.posts | where: ‘lang’, lang %} PS: I never remember that stuff, I leave it to the CMS.
I’ve tried Algolia & co. Meh... Lunr.js with a bit a template logic for the index does the trick and will be fast af: lunrjs.com PS: we’ve added a tokenizer for Chinese: github.com/Wiredcraft/lunr-chinese
complex stuff... — Use a 3rd party service when you can. — Zapier is your friend: zapier.com — If not, now is your friend: zeit.co/now — If not, write your own damn backend. — Embed tiny JS apps (React or Vue.js) to make it work. — As usual, “no” is a valid answer.
with a form — Simple HTML form with jQuery (yuck). — File upload with S3. — Submits to a Zapier webhook. — Triggers a GitHub issue creation and an automated confirmation email. Simple and doesn’t require support. PS: I f*cking love Zapier.
few more things... — jQuery is rarely the answer. — I like CSS/SASS micro frameworks (Tachyons, egg...). Also, grids suck. — Don’t be an asshole: write READMEs and comments (even for Liquid). — Spend time naming things properly and organizing your code. — Say no and refactor.
generation — Avoid plugins (seriously, they suck). — Loops are bad, mm’kay? — Increment build: --incremental. — If you have a lot of posts: --limit_posts. — Debug with --profile. — Avoid too many files (_data is your friend). — Careful with config defaults. wiredcraft.com/blog/make-jekyll-fast/
Loading — Use a CDN. — Optimize your pictures (ImageOptim). — Resize your pictures (rsz.io). — Inline your CSS. — Go easy on scripts, and load them at the end of the page. — All the other shit Google tells you about.
a nutshell 90% of what I talked today is captured in Jekyll Basics: github.com/Wiredcraft/jekyll-basics Just start from this boilerplate and try to keep everything as simple as possible. Say “no” and “why?” often. The rest are common best practices.
(some) constraints is good One of the reasons I love Jekyll is that it imposes an acceptable level of constraints. Too much or not enough of it is terrible for creativity. It’s at the core of our creative and engineering methodologies.