Announcing inDIVisible, a new JavaScript framework/library

I am super excited to announce my latest Open Sauce JavaScript framework/library: inDIVisible. Let me tell you why it’s the answer to everything, and you should start using it right now.

Everyone knows HTML is old-skool. All those elements, bleurgh. Boring names, boring properties. And they aren’t dynamic – they just describe content! Clearly they are unfit for use in Modern Web Applications.

Instead, simplify your life AND get all the JavaScript goodness you crave using inDIVisible. Here’s how:

Yo peeps (not hello world)

<div>Yo peeps!</div>

Pretty simple, right? But this doesn’t do anything. Let’s bind it to our JavaScript model called div.

<div #div="div"></div>

Easy! Whenever your model changes your element updates automagically. This should be enough for you to write a Facebook killer, but there’s more!

Handling input

Want to update the div property in your div model? No problem!

<div [div@] ?div="div.div"></div>

This attribute:


Tells inDIVisible to turn the element into an input field. That’s right! No need for pesky input elements.

And this attribute:


Updates the div.div property with the value the user enters. It couldn’t be easier!

What’s that? You need a checkbox? Piffle:

<div [div/] ?div="div.div"></div>

See that /? It looks like a tick, which is like a checkbox. Radio buttons are like this:

<div [div.] ?div="div.div"></div>

And if you want a button, just do this;

<div [div]></div>

But buttons *do* stuff, right? What you need is to call a function.


inDIVisible is a functional framework/library, too. You can invoke functions like this:

<div (div)="div.div"></div>

Just handle the click event (there aren’t any other events worth handling) you want to respond to like this:


Then name the function you want to run:


Woah! Genius!

Advanced usage

Need to handle loops? Behold:

<div #div="div.div" *div></div>

That cheeky little * tells inDIVisible to repeat the element for each item in the model.

And how about showing and hiding elements? It’s as easy as this to show the element only if the element is truthy:

<div #div="div.div" +div></div>

And you do this to hide the element only if the element is falsy:

<div #div="div.div" -div></div>


CLI is a Command Line Interface. But inDIVisible is better than that, so it has CLA – Command Line Awsomeness. Type commands like this in your bishbashbosh shell to make cool stuff happen:

div div /div divdiv-div

Honestly, why are you still here? Use it now, you bunch of hipster sheep.


No-one downloads anything now, so there’s no link to any files. Instead you should type one of these commands, whichever one is going to work for you:

grunt install inDIVisible
gulp install inDIVisible
snort install inDIVisible
sniffle install inDIVisible
fart install inDIVisible
bower install inDIVisible
bowel install inDIVisible
flump install inDIVisible
twerk install inDIVisible
plonk install inDIVisible

Then build it and run it. I’ll leave you to figure out those commands, because I have to go drink some organic kale and quinoa juice.

Technical Credit

There’s a well-known concept in programming that refers to the negative effects poorly-made decisions can have on the quality of software over time: Technical Debt. The Wikipedia article gives some examples of the causes and the consequences of technical debt.

This financial analogy is a useful one, as it nicely describes the long-term impact of debt – the longer you have it, the worse the problem becomes. Conversely you can have credit (e.g. savings) in your account for a long time, waiting for the proverbial “rainy day” to take advantage of your good planning. Want to splash out on a new pair of sparkly galoshes? No problem!

At the An Event Apart conference in Orlando in October 2016, Jeremy Keith spoke about "Resilience: Building a Robust Web That Lasts" which was a talk about progressive enhancement cleverly disguised as it didn’t use the phrase ‘progressive enhancement’. In that talk Jeremy dropped a knowledge bomb, calling building sofware using the principles of progressive enhancement like building ‘technical credit’.

This, in my opinion, is genius. It’s a gloriously positive spin on technical debt, which is too often seen as the product of bad developers. It’s saying “you, developer, can make a better future”. I love that.

It appears there is little online which talks about this “technical credit” concept. In fact, the only decent resource I could find is a 2014 paper from the Conference on Systems Engineering Research entitled ‘On Technical Credit’. The author, Brian Berenbach, gives a brief but eloquent introduction to the idea that we should concentrate on what should be done, rather than what shouldn’t be done to make a system better.

From the abstract:

"Technical Debt" … refers to the accruing debt or downstream cost that happens when short term priorities trump long term lifecycle costs… technical debt is discussed mostly in the context of bad practices; the author contends that the focus should be on system principles that preclude the introduction, either anticipated or unanticipated, of negative lifecycle impacts.

Sounds great; let’s stop bad things happening. How? The abstract continues:

A set of heuristics is presented that describes what should be done rather than what should not be done. From these heuristics, some emergent trends will be identified. Such trends may be leveraged to design systems with reduced long term lifecycle costs and, on occasion, unexpected benefits.

Emphasis mine. I’ll wait here while you to read the rest of the document.

At this point hopefully you can see the clear link to the principles of progressive enhancement. Let’s look at a few examples emergent trends – which I’ll call ‘properties’ as the paper uses this term – and the (un)expected benefits that progressive enhancement may give. But first, a quick refresher on what progressive enhancement is.

The principles of progressive enhancement

I can’t put progressive enhancement in a neater nutshell than Jeremy does in his talk ‘Enhance!’:

  1. Identify the core functionality
  2. Implement it using the simplest technology possible
  3. Enhance!

For websites this boils down to practical principles like these:

But there’s no hard-and-fast set of rules for progressive enhancement, because every site has different functionality. That’s why it’s considered a philosophy rather than a checklist. As Christian Heilmann said, progressive enhancement is about asking "if" a lot.

Emergent properties

Someone once said words to the effect of "the only constant is change", meaning that the only thing you can rely on is that things will not stay the same. That’s good! Progress is positive and brings with it new opportunities.

These opportunities can be seen as emergent properties – new or existing attributes of things which emerge as time goes on. For example, the increasing uses of mobile computing devices and fast home connection speeds are emerging properties leading to opportunities for new types of business. Likewise, the prevalent use of social media and its unprecedented bulk collection of data about its users is allowing new models for advertising – and, unfortunately, more nefarious uses – to emerge.

These emerging properties are often very difficult if not impossible to predict. Progress can lead to unexpected outcomes. Technology in particular is often put to unanticipated uses and exhibits unexpected behaviour when used at scale.

Who, for example, could have predicted the explosion of new devices and form factors just a few years ago. Devices once the domain of science fiction are now commonplace, and the range of new input types – notably touch and voice – is revolutionising how people interact with technology.

While fixed line download speeds are increasing many in developing nations, who arguably are the ones who could benefit the most from widespread Internet access, are stuck with very slow speeds, if any at all. Clearly we have a long way to go to achieve parity in global access to the Internet.

(Un)expected benefits

With such a wide array of both expected and unexpected properties of the current technological revolution, building our systems in such a way to both be resilient to potential failures and benefit from unanticipated events surely is a no-brainer. The ‘On Technical Credit’ paper defines this approach as Technical Credit:

Technical Credit is the investment in the engineering, designing and constructing of software or systems over and above the minimum necessary effort, in anticipation of emergent properties paying dividends at a later date.

This is Progressive Enhancement. It’s about putting some thought in up-front to ask those tricky "what if" questions. Questions such as:

Thinking about these, and many other, potential problems leads you to follow the recipe given by Jeremy which I quoted above:

  1. Identify the core functionality
  2. Implement it using the simplest technology possible
  3. Enhance!

Implementing core functionality using the simplest technology possible – in the case of a website by using well-structured semantic HTML markup generated on the server – gives some expected benefits:

Plus it provides a strong foundation to take advantage of unexpected occurrences; those emerging properties mentioned earlier.

From brand new browsers to old browsers working in a new way, your well-structured HTML will deliver your content even if everything else fails. Support for new input types on a myriad of unimagined devices will be taken care of by the browser – rather than you having to find Yet Another JavaScript Component™ that adds the support you need. And as new APIs are added you can layer on support for these knowing the foundation of your site is rock solid.

Spending Technical Credit

So you’ve built your system carefully, thinking about the many ways in which it could fail. You’ve done ‘over and above the minimum necessary effort’ and can now sit back, confident in the hope that should a rainy day come you’ve accrued enough technical credit to weather the storm.

I Am The Very Model Of A Modern Web Developer

I am the very model of a modern web developer
I build my sites in Ember or in React or in Angular
The download size is massive but development is easier
My grunt and gulp and NPM all prove that I am geekier

I am the very model of a modern web developer
My animations cause offence in anyone vestibular
A carousel with massive pictures should be seen as de rigeur
And light grey text with background white will make my content sexier

Some people say my websites should all be enhanced progressively
But my developmental choices have been made deliberately
A 12 meg payload is a guarantee of exclusivity
I don’t want Luddite users who refuse to upgrade from 2G

I have a brand, you could say I’m an Internet celebrity
But try to load my site on anything but super fast 4G
You’ll just get empty pages on your Android or your iPhone 3
Upgrade your phone, you pauper, or you’ll never get a byte from me

With apologies to Gilbert and Sullivan.

HTML Matters

Rant time. No-one can deny that web development tooling has improved in leaps and bounds over the last few years. I’ll sound like a moaning old man if I talk about how primitive things were in the old days, so I won’t.

But despite this wealth of tools, loads of good quality information online, and access to resources and training why do I still regularly see HTML like this in new web projects:

<div class="footer">
<span><img src="twitter.gif" /></span>
<span><img src="facebook.gif" /></span>
<span><img src="instagram.gif" /></span>

It appears modern web developers have within their grasp a panoply of development and build tools – NPM, bower, gulp, grunt etc – but don’t have access to HTML elements which have been implemented in browsers for years. HTML matters!

It matters because structure matters. Meaning matters. Semantics matter (but don’t go overboard). Accessibility matters. For many projects, SEO matters.

A web page is, at it’s core, a structured document. Pile on all the fancy-pants JavaScript frameworks you want, but you’re still delivering HTML to a rendering engine built in a browser. If you’re making no effort to use appropriate HTML elements to mark up your content then you need to sharpen up your skills.

Wednesday is Link Day

It’s been a while, so here’s a humongous list of goodies for y’all.


Performance Testing Dictionary, a free book (registration required):

Yes, a performance budget builder:

Measuring performance (using the navigation timing API):

Aligning app performance to business success (podcast):

Performance advice from experts:

A good case study on performance improving the bottom line:

The “average page” is a myth:


This 1939 Chart Explains How Color Affects Legibility:

What’s coming up for Microsoft Edge in 2016. Number 2 on the list: Accessibility:

What to do when you get sued for your inaccessible website:

The BBC gives advice on how to design for accessibility:

The business case for issue prevention: Extreme Accessibility:

Accessibility for business and pleasure:

The browser accessibility tree:

Progressive Enhancement

A simple enhancement for ordering items by, who else, Jeremy “My Man Crush” Keith:

“JavaScript web apps considered valuable”:

“Why I hate your single page app”:

“Don’t tell me what my browser can’t do”:

Progressive web apps by Google (I may have linked to this before):


Mobile and Multi-device design: a free e-book (on Apple devices only, bah):

The world’s poorest households are more likely to have a mobile phone than a toilet:

As mobile screen size increases, so does activity:

Launch an Android app from the web and cleanly fallback to web:


Shared before, but still great. Offline access to documentation:

Give developers autonomy. Couldn’t agree more:

Want to write software for your car? It’s coming:

The history of Open Source, and a glimpse at its future:

The woes of date input (yep, got that t-shirt):

“Paid a great deal to be terrible at development most of the time”:

The art of debugging (presentation and video):

Martin Fowler on feature toggles:

Control CSS filters with HTML attributes:

Developer fallacies:

The sad state of entitled web developers:

Most developers have never seen a successful project:


Via Beth: what’s next for manual testers:

On screen reader testing:


“Design without touching the surface”:

Great talk by Jen Simmons about getting out of our design rut:

CSS best practices presentation:

The Goldilocks approach to responsive design:

About notifications and no-UI:

The dangerous UI team:


We need to really understand promises:

Offline with ServiceWorkers and UpUp:

2016 – the year of streams:

Definitive guide on charts in JavaScript:

const and immutable objects in ES6:

Regex in JavaScript made easy:


Old-school PC fonts:

Online regular expression tester:

Stupid hackathon. Featuring my favourite Chrome extension “Non-Ad Block”:

A feature detection library in 1KB:

Images and sketches of popular mobile devices (from Facebook):

And finally…

Remember Command and Conquer? Here it is in HTML5:

A briefish history of the web (in 3 parts):

Play a drum machine with your keyboard. And record it. Yes:

And if that wasn’t good enough, here’s a TR-808:

Free philosophy e-books. Cos I know you love ’em:

What Tor’s data looks like as it flows around the world:

The web is OK: