How to Build a Composable Blog (opens in new tab)

Is this parody?

> Creating a blog from scratch requires quite a lot.

Quite a lot of what? If I want to create a blog then there are many existing systems that are essentially plug and play.

Perhaps this is an article teaching me about composable whatevers, but I'm not sure this is a great example, or even if it is perhaps a different tone could have helped set the scene. Nobody in their right mind would want to build a blog this way in the real world, I hope.

As someone who has built my own blog (and blog platform) more than a few times, built WordPress themes many times, currently maintains a blog-ish site on Webflow, and used hosted blogging services numerous times...this blog post sounds like the most exhausting possible way to build a blog.

Here is my composable blog with cURL and awk

#!/bin/sh

process() {

  output="${1%.*}".html

  # Convert markdown to html and save
  curl \
    -sS \
    -u "${GITHUB_USERNAME}:${GITHUB_TOKEN}" \
    -X POST \
    -H "Content-Type: text/plain" -H "Accept: application/vnd.github.v3+json" \
    https://api.github.com/markdown/raw \
    --data "$(cat $1)" > $output

  # Apply layout and save
  html=$(awk 'NR==FNR { a[n++]=$0; next } /{{ content }}/ { for (i=0;i<n;++i) print a[i]; next } 1' $output layout.html)
  printf "%s" "$html" > "$output"

  echo "Processed ${output}"

}

for file in *.md; do process "$file" & done wait

This looks like "what if every DOM element was it's own library?". Seems like a total nightmare except in the extremes. For toy projects might be nice to not build widgets yourself, or if you're a large organization with many teams each owning reusable components.

For the vast majority of not-a-toy and not-Amazon projects this seems un-aligned?

It's unclear what this even does to facilitate component development. It doesn't seem to provide any primitives. Most of the docs appear to focus on how this can be your workspace, env management, dependency graph, build system, CI, package repo, and team management. Super over-zealous for a component ecosystem.

What is the ecosystem? A bunch of packages of dubious quality left un-maintained from github? We already have that. Maybe the 'search by feature' aspect is useful.

This feels like an index of NPM packages needlessly masquerading as a framework, but maybe also your whole dev workflow and toolchain, but also an "ecosystem" so there can be a subscription fee tacked on.

To help me think about this, is it like if I built a blog with React, but each major UI component was it's own package that I installed with `npm`?

Is the expectation that I would mix and match UI components out of different projects? Like I want to use Material UI's <Checkbox> component but Chakra's <Banner> component? And they're all independently versioned?

Sounds like a recipe for a lot of complexity to me, but probably I am missing something.

Edit: The homepage actually does a really good job of explaining this. And yes, it seems like it's what I thought.

https://bit.cloud/

A lot of moving parts? Aren't blogs traditionally static sites. Yes you can full MVC your blog and what not but there's nothing complex about an `index.html` page created from one of the many, many, many readily available Markdown parses or straight plain-text.

This article is a lot of busy work.

Parts of the site are jumping and fonts are realigning for more than 10 seconds after loading. Maybe it's just me, though.