The Bitcoin.org website is built using Jekyll and the source code is available on GitHub which is a great move for a community website. In this showcase we're deconstructing their site, let's get into it.
Bitcoin is a cryptocurrency created in 2008 by a mysterious person or group by the alias Satoshi Nakamoto. It was the first decentralized cryptocurrency and is currently the most valuable, with a market cap of over $2 trillion.
With such a large amount of wealth and people involved with the network, Bitcoin needs a website with comprehensive information for everyone, including individuals, miners, and software developers. The problem with an online presence for Bitcoin is no one owns the network, so there can’t be an “official” website. The closest we have is Bitcoin.org which provides high-quality content for the community.
The site has a blog with the latest news, arranged in alternating left/right blocks.
The left/right blocks are a neat way to organize posts I haven’t seen before. The implementation is actually super straight forward. The posts output in a list:
Then each list item has an alternating left/right float with some margin. Applying a style to only even (or odd) elements is something I used to do directly in Jekyll. Using the cycle tag in Liquid was a great way to do this:
Browser support for
nth-child has become much better since the early days of Jekyll. A more elegant way to do this now is pure CSS like the Bitcoin.org team have:
The posts themselves are fairly standard. At the top of each post, there are four links: Blog Home, Subscribe to RSS feed, Post History, and Report Issue. Blog Home is fairly self-explanatory. Post History and Report Issue are interesting because they’re linking directly to GitHub. Post History to the commit history on a particular file:
And Report Issue to open an issue on GitHub.
It’s clever using GitHub in this way for a developer-focused community site. It allows the team to have a completely static website and still have deep interactions and conversations about the site’s content with the community.
The RSS feed is manually generated. Typically I would recommend using jekyll-feed to generate an RSS feed because it’s set and forget it. Getting one tiny bit of the XML wrong will cause the entire feed to be invalid. The Bitcoin.org team has a number of RSS feeds across the site, which is likely why they’ve opted to generate them manually.
Diving into the source code for a post, the front matter looks pretty standard with one minor oddity, the author is a snippet of HTML:
Using the HTML snippet makes the author easy to output as they do after a post:
The problem I can see, is say you want to add a profile image to the author, you would have to update the front matter on every single post. A more flexible way to accomplish this is to store the author information in a data file and reference that from the post. It would work something like this:
In the post front matter, we reference the key in the data field:
Then in the layout, we take the author, match it to a key in the authors data file, then render the author however we’d like.
Now there’s a single place to update the structure of an author.
The last thing I’ll mention on the blog is excerpts. Jekyll automatically creates an excerpt variable for posts which contains a small snippet of content. It’s often used on a blog list page to give a preview of the content. Something like this:
They can insert this separator in the post content to determine the end of the excerpt. It could be after a few words, or perhaps they want the first three paragraphs. Like this:
A portion of the site is translated into an impressive 28 different languages. The way the site does this is pretty interesting. They have built a translation engine using a Jekyll plugin. The way it works is they have a translation tag which they pass a key:
There’s a translation file for each language which has a list of keys and the translation in that language:
On build, the plugin iterates over languages, grabs content from the translation file and outputs the file with a prefix of the language code (
/es/ in the example above
It’s similar to a strategy to a translation engine we’ve built at CloudCannon called Rosey. The main difference is Rosey runs after the Jekyll build, where this Jekyll plugin runs as part of the Jekyll build. Personally, I’m a fan of keeping translations out of Jekyll because translating in Jekyll adds a lot of complexity as we’ll see later in the showcase. There are situations where it might make sense to keep the translation logic in liquid. If you have complex logic around specific translations, you have complete control over how each translation is rendered. However, the majority of the time, that level of control is not necessary.
Selecting a digital wallet to store your Bitcoin can be overwhelming with the number of options available. The bitcoin.org site has an interactive questionnaire to help you find the perfect Wallet.
It’s well designed and easy to use. Filling this out takes you to a table of wallets matching your criteria:
The data for the wallets comes from a Jekyll collection. Here’s the document for the Wasabi Wallet:
If you haven’t seen the anchor and alias syntax in YAML before, it’s a great way to keep your YAML files DRY. In this example
&DEFAULT defines an anchor,
*DEFAULT refers to an anchor and essentially replaces the value with the anchor when it’s parsed.
Each Wallet has its own page with in-depth information.
There’s a plugin which generates these pages:
Collections have output behavior built in so I’m curious why they’ve opted to generate these pages through a plugin. My guess is translations.
The other place that uses the Wallet collection is the table of wallets shown above. Here’s the code that generates the table, I’ve simplified it to make it easier to follow the gist of what it’s doing:
This is where we really see how much complexity the translation engine is adding. It’s a lot of logic to essentially output a tick in one of four states. If we ignore the translations, I would structure it something like this:
I’ve changed the values of the checks to make them easier to understand. When we’re outputting the checks, the logic can now be simplified in a big way:
Isn’t that easier to read?
--author= doing here? Send us a Tweet if you have any ideas, I’m curious.