The multitude of interfaces

Over the last few years, I’ve taken an intentional direction towards working in distributed systems and cloud computing rather than user interface programming — I almost wrote “web” there, but the aforementioned topics are a HUGE part of the web!

But especially because my language of choice tends to be JavaScript (albeit NodeJS, specifically), it can be confusing to folks that I “don’t really do UI programming” much anymore.

That’s not to say I can’t (“can’t” is a strong word). But much like I can run five miles, that doesn’t mean I necessarily want to or that I enjoy it. Is is possible? Sure! Is someone else likely much better at it than me? Oh, that’s for sure.

I’ve been thinking about how and why I’ve distanced myself from user interface programming (what I’d term “UI programming”). Is it that it’s not as respected as other computing fields? Is it all those darn shiny frameworks (gosh, hate it when people have ideas and explore them and see how they change things, ugh right? </sarcasm>)?

Here’s a thing — UI programming has tired me.

I’ve tired of the hassle of getting a Windows laptop so I could replicate a bug on an old version of Internet Explorer, of course to find that I need to de-tangle an issue without any of the useful, modern tooling that I’m used to to sort it out. I’ve tired of having issues filed because someone looked at a website on their unique flavor of browser/device combination. The issue being: the multitude of interfaces.

In “backend” or as I might prefer, distributed systems, or whatever you feel like calling it, we have interfaces. They’re HTTP calls. Or payloads from a queue. Or a CLI. But there’s generally one, maybe a couple interfaces at play.

If you try and call my API with some protocol that’s NOT what I expect, I, the benevolent API owner, will blame you and that is your problem.

If I write a CLI, okay, maybe I might have a few interfaces if I am supporting multiple operating systems and need to customize some things, but higher-order programming languages will often make that job easier for me, and the bugs will be random and the Linux users will blame themselves (hey, I know this pain).

But open a web application? Has to work on every browser/device combination.

Of course, with good web standards, this issue is greatly reduced, but any UI person would be a lying liar if they say that web standards negate this issue. There’s still an essentially unlimited number of interfaces. It’s almost like its own form of context switching, as far as the cost of conceptualization.

And that’s pretty much why I think I’ve been drawn away from UI programming as a major focus: the complexity grows with the number of interfaces in a way I don’t find enjoyable to work with. Thinking about the number of interfaces as a measure of complexity is something I would like to see more of.

Because it’s not that I don’t like UI programming, then, it’s that I prefer for my UIs to be APIs :) [or their ilk]