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.

Yeah I think it's an article about "components". As far as I can tell the product is essentially a component library that treats components as completely standalone, so that they can be developed and versioned independently.

I agree building a blog isn't a great example. They were off to a bad start by saying it's hard to create a blog. Then they introduce a solution that seems to require existing knowledge of

- "forking"

- Typescript

- React

- components and props

- MDX

- The Bit platform

I feel like if you know all this stuff then you aren't going to have a problem building a blog.

And I feel like I could swap "The Bit platform" for Material UI or whatever and by the end of the post I'd be in the same place: not having a working blog :D

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.

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.

Fair, but also besides the point, the post is just trying to illustrate their system, and it does it well in my view.

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.