There's this really ~~cool~~ annoying feature of Chrome's Lighthouse tool that nags you about unused code in a project. Here's the report I just generated from ui.xinjs.net—a site that Lighthouse gives a score of 100 (desktop) and 89 (mobile) to that is hosted on Github.

Now a lot of this stuff is kind of wrong (the fact that a piece of code hasn't been used yet doesn't mean it won't be used, and it's inefficient to load everything in pieces), but underneath it all, when you're looking at real projects (vs. demo sites intended to exercise pretty much everything in a package), dead code stripping works really badly and there are deep issues with the way packaging code handles dependencies.

If you write a package, foo, that uses some stuff from another package named bar then there's a pretty good chance most or all of whichever version of bar you used will end up embedded in the distributable version of foo.

This is fine—possibly even good—for small things. E.g. if you use someone's leftpad function in your library it gets broken in a way that would destroy your code, your code will be fine until you update it, and then presumably your tests will discover the issue and you can fix it before you ship a new version.

But when you're writing very popular foundational code, like, say, ReactComponent it could mean that a project that uses many differently sourced subclasses, e.g. UI components, built at different times by different people, you may get many copies of the same code (inefficient) or even versions (scary) in the same codebase.

Both b8rjs and xinjs have an additional problem with this because they rely on the Singleton pattern to manage application state. The basic idea is that if you look at app.user.name you'd prefer it to be the only app.user.name. And if you've somehow spun up multiple registries, you no longer have a single source of truth. This is both inefficient (waste of memory etc.) and bad (bugs!).

The problem manifests in React in a more subtle, but actually far worse, way. In React, if there are breaking changes in React then components built on one version will not play nicely with one another, either obvious or (worse) subtle ways. This leads to React projects getting "stuck" on certain weird collections of dependencies.

xinjs blueprints

As xinjs-ui has evolved, it has grown quite big, and dead code stripping just doesn't seem to work properly, so if I want to use one or two components from xinjs-ui you end up with all of it in your packaged code. The more I've looked into it, the gnarlier it seems to get.

So, I wanted to allow components to be built in as lightweight a fashion as possible, and the solution I came up with was to turn the class definition inside out. Instead of importing the base Component class and subclassing it, export a function that expects to be passed the base Component class and anything else that seems handy (since none of it costs anything). Then you just import the function, pass it to makeComponent and voila!

But this idea turned out to be even better. E.g. if you wanted to use two components with the same name (because how many different ways are there to name a popup-menu component?) you could take the function and pick a name for it.

Old way (without blueprints)

import { Component, elements } from 'xinjs' // congratulations, you just got a copy of xinjs!

export class MyComponent extends Component {
  content = () => elements.div('hello, world')
}
export const myComponent = MyComponent.elementCreator({tagName: 'my-component'})

New way

import { XinBlueprint } from 'xinjs' // just a type declaration!

export default myBlueprint: XinBlueprint = (tag, factory) => {
  const { Component, elements } = factory
  class MyComponent extends Component {
    content = () => elements.div('hello, world')
  }
  return {
    type: MyComponent
  }
}

At the cost of a little boilerplate (sigh) you get a component that has zero dependencies and whose tagName is chosen by the consumer. But, it gets better…

Consuming Blueprints

If you just want to bundle everything together, you can just do the usual stuff.

import { makeComponent, elements } from 'xinjs'
import myBlueprint from 'my-blueprint'

const { creator } = makeComponent('foo-bar', myBlueprint)
document.body.append(creator())
// same as document.body.append(elements.fooBar())

But if you want to load a component from a cdn or a service endpoint on demand, you can use the new xin-loader and xin-blueprint components:

<xin-loader>
  <xin-blueprint 
    tag="my-container" 
    src="path/to/my-container/blueprint.js"
  ></xin-blueprint>
  <xin-blueprint 
    tag="my-widget" 
    src="path/to/my-widget/blueprint.js"
  ></xin-blueprint>
</xin-loader>
<my-container>
  <my-widget></my-widget>
</my-container>

All the blueprints inside a loader will be loaded asynchronously in parallel, and of course you can generate them in code:

import { blueprint, blueprintLoader, myContainer, myWidget } from 'xinjs'
document.append(
  blueprintLoader(
    blueprint({tag: 'my-container}, src: '.../my-container.blueprint.js'})
    blueprint({tag: 'my-widget}, src: '.../my-widget.blueprint.js'})
  ),
  myContainer(myWidget())
)

create-xinjs-blueprint

And to wrap all this in a nice developer experience, there's create-xinjs-blueprint.

The goal here starts with wanting to break xinjs-ui into a collection of easily integrable lightweight blueprints, which means I want to be able to:

minimize friction to ship a component done
self-hosted demo done
selt-hosted tests in the browser done
playwright support done
provide self-hosted documentation with live examples etc. (which, basically, becomes trivial once xinjs-ui is turned into a collection of blueprints)

While playwright is a fantastic tool for end-to-end testing, having tests run right in front of you on refresh during development is simply amazing, and this was accomplished by turning the test component I use internally for xinjs development into a standalone blueprint.

It's also incredibly liberating to be able to just build something cool without worrying if it is going to add fat to a component library. (There used to be a bunch of babylonjs-based 3d components in xinjs-ui but I removed them because no-one needed them and they bloated the library.)

The first non-trivial blueprint I built was based on the SVG clock demo from b8rjs. Thing is, this demo lives inside b8rjs, but it isn't exported to prevent bloat. But here's the xin-clock component, and here's the live demo.

The Bottom Line

You're currently looking at the xinie project, which is my current side-project. Among other things, it replaced wordpress as my blog engine. I'm dogfooding it.

xinie is a brand new soup-to-nuts, service compris application framework, (initially build on Google Firebase) and it supports code-as-a-service out of the box, and blueprints are just code, of course.

Already, you can import a module directly into xinie and then embed it in a page, but ultimately you'll be able to create and edit them, add tests, and so forth. And all of it lives inside the fine-grained access framework baked into xinie.