Heterogeneous Lists

b8r's demo site uses a heterogeneous list to display source files with embedded documentation, tests, and examples
b8r’s demo site uses a heterogeneous list to display source files with embedded documentation, tests, and examples

One of the things I wanted to implement in bindinator was heterogeneous lists, i.e. lists of things that aren’t all the same. Typically, this is implemented by creating homogeneous lists and then subclassing the list element, even though the individual list elements may have nothing more in common with one another than the fact that, for the moment, they’re in the same list.

This ended up being pretty easy to implement in two different ways.

The first thing I tried was a effectively an empty (as in no markup) “router” component. Instead of binding the list to a superclass component, you bind to a content-free component (code, no content) which figures out which component you really want programmatically (so it can be arbitrarily complex) and inserts one of those over itself. This is a satisfactory option because it handles both simple cases and complex cases quite nicely, and didn’t actually touch the core of bindinator.

Here’s the file-viewer code in its entirety:

<script>
    switch (data.file_type || data.url.split('.').pop()) {
        case 'md':
        case 'markdown':
            b8r.component('components/markdown-viewer').then(viewer => {
                b8r.insertComponent(viewer, component, data);
            });
            break;

        case 'text':
            b8r.component('components/text-viewer').then(viewer => {
                b8r.insertComponent(viewer, component, data);
            });
            break;

        case 'js':
            b8r.component('components/literate-js-viewer').then(viewer => {
                b8r.insertComponent(viewer, component, data);
            });
            break;
    }
</script>

(I should note that this router is not used for a list in the demo site, since the next approach turned out to meet the specific needs for the demo site.)

The example of this approach in the demo code is the file viewer (used to display markdown, source files, and so on). You pass it a file and it figures out what type of file it is from the file type and then picks the appropriate viewer component to display it with. In turn this means that a PNG viewer, say, need have nothing in common with a markdown viewer, or an SVG viewer. Or, to put it another way, we can use a standalone viewer component directly, rather than creating a special list component and mixing-in or subclassing the necessary stuff in.

You’ll note that this case is pretty trivial — we’re making a selection based directly on the file_type property, and I thought it should be necessary to use a component or write any code for such a simple case.

The second approach was that I added a toTarget called component_map that let you pick a component based on the value of a property. This maps onto a common JSON pattern where you have a heterogeneous array of elements, each of which has a common property (such as “type”). In essence, it’s a toTarget that acts like a simple switch statement, complete with allowing a default option.

The example of this in the demo app is the source code viewer which breaks up a source file into a list of different kinds of things (source code snippets, markdown fragments, tests, and demos). These in turn are rendered with appropriate components.

This is what a component_map looks like in action:

<div
  data-list="_component_.parts"
  data-bind="component_map(
    js:js-viewer|
    markdown:markdown-viewer|
    component:fiddle|
    test:test
  )=.type"
>
  <div data-component="loading"></div>
</div>

From my perspective, both of these seem like pretty clean and simple implementations of a common requirement. The only strike against component_map is obviousness, and in particular the quasi-magical difference between binding to _component_.parts vs. .type, which makes me think that while the latter is convenient to type, forcing the programmer to explicitly bind to _instance_.type might be clearer in the long run.

P.S.

Anyone know of a nice way to embed code in blog posts in WordPress? All I can find are tools for embedding hacks in wordpress.

Announcing bindinator.js

Having recently set up bindinator.com, I am “officially” announcing my side-project Bind-O-Matic.js bindinator.js. It’s a small (currently 7kB gzipped and minified) Javascript library that is designed to make developing in vanilla javascript better in every way than using one or more frameworks. It embodies my current ideas about Javascript, Web, and UI development, and programming — for whatever that’s worth.

Also, I’m having a ton of fun hacking on it.

By way of “dogfooding”, I’m simultaneously building a skunkworks version of my main work project (which is an Electron-based desktop application) with it, adapting any code I can over to it, building b8r’s own demo environment, and slowly porting various other components and code snippets to it.

Above is my old galaxy generator, updated with a bunch of SVG goodness, and implemented using b8r (it was originally cobbled together using jQuery).

Why another framework?

I’ve worked with quite a few frameworks over the years, and in the end I like working in “vanilla” js (especially now that modern browsers have made jQuery pretty much unnecessary). Bindinator is intended to provide a minimal set of tools for making vanilla js development more:

  • productive
  • reusable
  • debuggable
  • maintainable
  • scalable

Without ruining the things that make vanilla js development as pleasant as it already is:

  • Leverage debugging tools
  • Leverage browser behavior (e.g. accessibility, semantic HTML)
  • Leverage browser strengths (e.g. let it parse and render HTML)
  • Be mindful of emerging ideas (e.g. semantic DOM, import)
  • Super fast debug cycle (no transpiling etc.) — see “leverage debugging tools”
  • Don’t require the developer to have to deal with different, conflicting models

The last point is actually key: pretty much every framework tries to abstract away the behavior of the browser (which, these days, is actually pretty reasonable) with some idealized behavior that the designer(s) of the framework come up with. The downside is that, like it or not, the browser is still there, so you (a) end up having to unlearn your existing, generally useful knowledge of how the browser works, (b) learn a new — probably worse — model, and then (c) reconcile the two when the abstraction inevitably leaks.

Being Productive

Bindinator is designed to make programmers and designers more (and separately) productive, decouple their activities, and be very easy to pick up.

To make something appear in a browser you need to create markup or maybe SVG. The easiest way to create markup or SVG that looks exactly like what you want is — surprise — to create what you want directly, not write a whole bunch of code that — if it works properly — will create what you want.

Guess what? Writing Javascript to create styled DOM nodes is slower, more error-prone, less exact, probably involves writing in pseudo-languages, adds compilation/transpilation steps, doesn’t leverage something the browser is really good at (parsing and rendering markup), and probably involves adding a mountain of dependencies to your code.

Bindinator lets you take HTML and bind it or turn it into reusable components without translating it into Javascript, some pseudo-language, a templating language, or transpilation. It also follows that a designer can style your markup.

Here’s a button:

<button class="awesome">Click Me</button>

Now it’s bound — asynchronously and by name.

<button class="awesome" data-event="click:reactor.selfDestruct">
  Click Me
</button>

When someone clicks on it, an object registered as “reactor” will have its “selfDestruct” property (presumably a function) called. If the controller object hasn’t been loaded, b8r’s event handler will store the event and replay it when the controller is registered.

Here’s an input:

<inpu type="range">

And now its value is bound to the fuel_rod_position of an object registered as “reactor”:

<input type="range" data-bind="value=reactor.fuel_rod_position">

And maybe we want to allow the user to edit the setting manually as well, so something like this:

<input type="range" data-bind="value=reactor.fuel_rod_position">
<input type="number" data-bind="value=reactor.fuel_rod_position">

…just works.

Suppose later we find ourselves wanting lots of sliders like this, so we want to turn it into a reusable component. We take that markup, and modify it slightly and add some setup to make it behave nicely:

<input type="range" data-bind="value=_component_.value">
<input type="number" data-bind="value=_component_.value">
<script>
 const slider = findOne('[type="range"]');
 slider.setAttribute('min', component.getAttribute('min') || 0);
 slider.setAttribute('max', component.getAttribute('max') || 10);
 register(data || {value: 0});
</script>

This is probably the least self-explanatory step. The script tag of a component executes in a private context where there are some useful local variables:

component is the element into which the component is loaded; find and findOne are syntax sugar for component.querySelector and component.querySelectorAll (converted to a proper array) respectively, and register is syntax sugar for registering the specified object as having the component’s unique id.

And save it as “slider-numeric.component.html”. We can invoke it thus:

<span 
  data-component="slider-numeric"
  data-bind="component(value)=reactor.fuel_rod_position"
></span>

And load it asynchronously thus:

const {component} = require('b8r');
component('slider-numeric');

To understand exactly what goes on under the hood, we can look at the resulting markup in (for example) the Chrome debugger:

Chrome debugger view of a simple b8r component

Some things to note: data-component-id is human-readable and tells you what kind of component it is. The binding mechanism (change and input event handlers) is explicit and self-documented in the DOM, and the binding has become concrete (_component_ has been replaced with the id of that component’s instance). No special debugging tools required.

Code Reuse

Bindinator makes it easy to separate presentation (and presentation logic) from business logic, making each individually reusable with little effort. Components are easily constructed from pieces of markup, making “componentization” much like ordinary refactoring.

A bindinator component looks like this:

<style>
  /* style rules go here */
</style>
<div>
  <!-- markup goes here -->
</div>
<script>
  /* component logic goes here */
</script>

All the parts are optional. E.g. a component need not have any actual

When a component is loaded, the HTML is rendered into DOM nodes, the script is converted into the body of a function, and the style sheet is inserted into the document head. When a component is instanced, the DOM elements are cloned and the factory function is executed in a private context.

Debugging

Bindinator is designed to have an incredibly short debug cycle, to add as little cognitive overhead as possible, and work well with debugging tools.

To put it another way, it’s designed not to slow down the debug cycle you’d have if you weren’t using it. Bindinator requires no transpilation, templating languages, parallel DOM implementations, it’s designed to leverage your existing knowledge of the browser’s behavior rather than subvert and complicate it, and if you inspect or debug code written with bindinator you’ll discover the markup and code you wrote where you expect to. You’ll be able to see what’s going on by looking at the DOM.

Maintenance

If you’re productive, write reusable (and hence DRY) code, and your code is easier to debug, your codebase is likely to be maintainable.

Scale

Bindinator is designed to make code scalable:

Code reuse is easy because views are cleanly separated from business logic.

Code is smaller because bindinator is small, bindinator code is small, and code reuse leads to less code being written, served, and executed.

Bindinator is designed for asynchrony, making optimization processes (like finessing when things are served, when they are loaded, and so forth) easy to employ without worrying about breaking stuff.

Core Concepts

Bindinator’s core concepts are event and data binding (built on the observation that data-binding is really just event-binding, assuming that changes to bound objects generate events) and object registration (named objects with properties accessed by path).

Bindinator provides a bunch of convenient toTargets — DOM properties to which you might want to write a value, in particular value, text, attr, style, class, and so forth. In most cases bindings are self-explanatory, e.g.

data-bind="style(fontFamily)=userPrefs.uiFont"

There are fewer fromTargets (value, text, and checked) which update bound properties based on user changes — for more complex cases you can always bind to methods by name and path.

Components are simply snippets of web content that get inserted the way you’d want and expect them to, with some syntax sugar for allowing each snippet to be bound to a uniquely named instance object.

And, finally, b8r provides a small number of convenience methods (which it needs to do what it does) to make it easier to work with ajax (json, jsonp), the DOM, and events.

The Future

I’m still working on implementing literate programming (allowing the programmer to mix documentation, examples, and tests into source code), providing b8r-specific lint tools, building out the standard control library (although mostly vanilla HTML elements work just fine), and adding more tests in general. I’m tracking progress publicly using Trello.

The New Macbook Pros

As someone who was forced to pick a new laptop about two weeks ago, i.e. just before the new Macbook Pros were announced, I have to confess that I’m a little pleased that the new machines don’t blow my current machine away. But, for all the pissing and moaning on the interwebs about Apple’s underwhelming new laptops, people seem to forget that PC performance has pretty much stagnated for the last eight years.

My 2012 Mac Pro (which was, effectively, a 2009 Mac Pro) still seems perfectly decent compared to the latest and greatest, and if I gave a damn it could be upgraded to give the 2013 Mac Pros a run for the money (in CPU benchmarks at any rate, the 2013 Mac Pros have stunning throughput).

The problem here is that CPU speed has hit a wall, pixel counts have gotten ludicrous (so that people are complaining about game performance on 4K displays), the benefits of GPUs for everyday computing haven’t really materialized, and 8GB of RAM is probably still plenty for most people’s daily use, and 16GB is ample.

Still, what happened last time Apple was forced to release an underwhelming upgrade after a long pause? The Intel transition. So, I’m willing to bet that the “let’s switch Mac OS  — oops macOS — over to our ARM architecture” faction within Apple is now winning a lot of arguments it was losing two years ago. (I suspect that the Macbook is the form factor of the first ARM-based macOS device.)

We’ll see — my predictions are often correct but wildly premature.

Affinity Photo — Redeemed!

Affinity Photos "Assistant Manager" dialog
Affinity Photos “Assistant Manager” dialog

An observant reader has pointed out that Affinity Photo (now?) offers the option of using Apple’s RAW converter instead of its own, which mitigates the single biggest problem with this otherwise excellent and inexpensive tool.

I think this should be (and should always have been) the default or only option until and unless Affinity’s RAW converter is improved to the point of being useful, but in the mean time this allows photographers to use this program for their entire work flow.

To switch to Apple’s RAW converter:

  1. Open a RAW (or DNG) file in the Develop persona.
  2. Use menu item View > Assistant Manager
  3. Set the RAW engine to Apple (Core Image RAW)
  4. Cancel the develop (the change does not take effect immediately)
  5. From now on Affinity Photo will use the far superior Apple RAW converter.

The workaround is documented here.

As a final aside — this process exposes several user interface warts.

First, why the heck is this buried in an obscure, vaguely named dialog you can only reach in one mode?

If you try to quit when you're developing an image you get cock-blocked
If you try to quit when you’re developing an image you get cock-blocked

Second, if you try to quit Affinity Photo when you’re in the middle of a RAW conversion it will simply stop you. (This is why I put in step 4.) You can’t opt to “discard changes to all open files” and get on with your life. This is very un-mac-like. If I were in a hurry I’d probably have been forced to Force Quit.

When you find the Cancel button (at the top left, kind of) you then get this terrible dialog.
When you find the Cancel button (at the top left, kind of) you then get this terrible dialog.

Third, when you Cancel a RAW conversion (which is what you have to do if you get into the situation above) the dialog box offers “Yes” and “No” options instead of useful verbs, such as “Abandon” and “Continue”.

And, finally, could software companies please pull their heads out of their asses and give their applications usefully distinct names? Half the time when I try to launch Affinity Photo via Spotlight I accidentally launch Affinity Designer. Don’t bury the lede.

Tech Free Saturdays with the Kids

Romilly with her iPad
Romilly with her iPad

Like many parents, Rosanna and I are concerned about our kids’ obsession with “technology”, so we tried “tech free Saturdays”, and it worked for about an hour (I — more than slightly ironically — spent that hour with the girls playing with an Elenco electronics set — something far better than the “150-in-one” electronics kit I dreamed of when I was a kid), and then gave up. Short of getting exercise outdoors — which while almost certainly a Good Thing To Do is hardly something of which I am an examplar — what was there to do without “technology”?

I don’t pretend to know what stuff is going to be important to the success of my kids. A lot of the stuff I learned in school has turned out to be useful, or at least makes for interesting conversation (apparently, most people forget almost everything they learned in school, and — having had no interest in it when they were 14, find it intriguing as adults). But the most useful stuff I learned as a kid is the stuff society — i.e. teachers and parents — made me feel guilty about spending time on. And I don’t think this is rare. I think it’s the people who were obsessed with computer games, or Science Fiction, or Dungeons & Dragons, back in 1982, who are creating the world we live in today.

We won (or, at least, we’re ahead — when we all die young from heart disease and diabetes because we never get any exercise, the jocks from high school whose knees still work can gloat).

And having won by willfully ignoring society’s ideas of what a “healthy” obsession was when we were kids, who are we to impose our ideas of what a “healthy” obsession is on our kids? Well, we’re parents, of course, and “a foolish consistency is the hobgoblin of small minds”. Perhaps we’re just that much smarter than our parents and teachers.

Another possibility that occurs to me is that a passion for anything — programming, role-playing games, the collected works of Jack Vance — only turns into something powerful and character-building if it involves pushing against social pressure. In other words, it’s OK for us to try to stop our kids from doing what they want to do, but it’s even better if they defy us and it anyway.

In the end, I don’t mind if my kids are obsessed with Minecraft, or even Youtube. What worries me is that its too easy to feed those obsessions, and I don’t think technology is the problem. But, having said that, my father narrowly avoided the Holocaust and my mother lived through famine and the Vietnam War, whereas I had to cope with the poor selection of science fiction in local libraries and the fact that our school only had one Apple II computer.