Change, shit
I guess change is good for any of us

– Tupac Shakur

Yesterday, I returned from NIPS 2016. It’s the world’s preeminent machine learning conference.

What was I doing there? To be fair, it was probably not the conference I would have picked, but it was a very interesting conference to attend (the first of its kind I’ve ever been to, to boot). The reason I was there was because on 1 November I started a new job, working for Danish startup Sportcaster. This also means that after almost four years, I have left PDC, where I started working when Ovivo was acquired. (I realise I’ve been horrible at updating the blog with this information, but better late than never, I suppose.)

Working for PDC has been a great experience. I’ve felt welcome in all my years there, even though I got into the company by untraditional means, and even though – as I have joked many times over the years – I would never have been able to land a job there by sending a regular application. (The company values educational credentials very highly, so my B.A. in English and Communication & Rhetoric is basically useless as an engineer.) I would encourage anyone wanting to work with Microsoft technologies or, especially, Prolog in Copenhagen to take a look PDC’s way, it’s a great place to work.

For me, however, Sportcaster presented the complete package: The company’s goal is making a product aimed at filming grassroots association football, and I will be doing their web platform. This allows me to combine my interest (OK, let’s just call it ‘obsession’) with football as well as doing web development in Python. If someone had asked me what I wanted to do that would basically have been it.

My first month there has been excellent, and I look forward to spending a long time there, and I’ll try to make an effort updating this space with news of development.

Tonight I’ve published Mediany, a small JavaScript library I’ve been working on. It’s released under the MIT License.

Mediany allows you to declare behaviour at different media query breakpoints. This allows you to e.g. have one thing happen when a button is clicked at one screen size, and something else (or something additional) happen when it is clicked at another screen size.

I built this to scratch my own itch. With responsive web design, it has become customary to transform the design based on the screen size of the user’s viewport – rearrange elements into columns, show things that were previously hidden, etc. (Media queries have a great many additional things to check for, but checking screen size – and width in particular – is the most common use case.)

As one transforms the design to fit larger sizes, I found that I also need to modify the behaviour. Clicking a button might require some set of changes at a small size, and something else entirely at a larger screen size. Mediany helps this process by declaring behaviour at specific media queries.

What’s in a name

I initially wanted to name the library responsive.js, because my research back then had indicated that was an unused name. As it turns out, it isn’t.

I still think responsive.js would be a great name for it. It is, in my estimation, the JavaScript library I’ve seen that comes closest to the principles of Responsive Web Design. There are a lot of libraries that will allow a mix of dynamic rendering (see aforementioned responsive.js project) and more complex break point handling. What I wanted was very simple: When a media query is true, perform this behaviour. I don’t want to handle the transition between two queries, and indeed I point people towards BreakJS for that functionality, I just want simple, declarative behaviour.

Developing a library

This is the first JavaScript library I’ve ever published. A lot of best practices were new to me (and I might indeed have missed many). I settled for a very conservative behaviour: there is no ES6-style encapsulation, only a simple bootstrapping function and one intended-for-public-consumption function: mediany.

It was also the development of Mediany that had my thinking so much about mustard. In the end, after a back and forth with Jeremy Keith, I settled for checking for features I reasonably expect aren’t present, but not all (Object.prototype.hasOwnProperty and Array.prototype.push not being feature-checked, although I technically could do it).

Mediany is available on npm, and I welcome any feedback.

I raise havoc, like giving Mobb Deep a booster chair

‘Cutting the mustard’ is the term the BBC News web developers use for what in other circles is called ‘feature detection’: Programmatically checking whether a given feature is available in the user’s browser.

The technique can be summarised succinctly as:

if (feature in element) {}

Where feature is the feature to check for (like ‘querySelector’) and element is the element you will be accessing said feature on (often window or document, though it can be any DOM element).

This is a crucial component of progressive enhancement, adding features to users whose browsers can support them, in a layered manner where said features are considered additions.

The problem I have encountered is of a philosophical nature: What features should one cut the mustard for?

If we take BBC’s opening statement (‘The browser is a hostile development environment’) to its extreme conclusion, a browser could theoretically support no JavaScript APIs. Thus, to cut the mustard, one would have to feature detect everything.

Now, this is probably overkill. Aside from the obvious fact that if the browser doesn’t support the controls if and in feature detection isn’t even possible, there are softer features to check for that are probably overkill. Object.prototype.hasOwnProperty() has been part of JavaScript since the beginning, and is implemented in all browsers known to MDN, so it can probably be assumed to be present.

But this still leaves the question: What features should one cut the mustard for? If we can assume some features are present, but not others, how do we determine which ones to check for? The only good rule of thumb I can think of is consulting implementation tables such as the ones on MDN and Can I use…, and drawing the line somewhere. And although better than outright user agent detection, it veers too close for my liking.

This might be me being too idealistic, but I am still unsure of the right approach.