We’re at an inflection point in the practice of constructing software. Our tools are good, our server developers are happy, but when it comes to building client-side software, we really don’t know where we’re going or how to get there.

Happy times upstream · The art and science of building server-side code is just fine, thank you; the technology’s breadth and polish has been ramping for years and still is.

More or less everything is expected to talk HTTP, and it’s really easy to make things talk HTTP.

More or less everything is built with an MVC-or-equivalent level of abstraction, and there are good frameworks to help us work sanely and cleanly. It’s a pity some people still build important apps in PHP and Spring, but those aren’t choices anyone is forcing them to make.

We still have angst over dynamic and static typing, but I think the trade-offs are reasonably well understood, and we have really good programming languages in each flavor. I use both, and in some cases the choice is obvious; check out the Bánffy-Bray criteria.

Concurrency · Functional Programming is getting a foothold on the mainstream, because if you care about performance you care about concurrency, and ordinary humans can’t do concurrency at scale (or really at all) if they’re sharing mutable objects.

A lot of people love Erlang but not that many are using it in production even though it gets concurrency and failover profoundly right, because types and classes.

Clojure’s concurrency primitives are functional, efficient, and beautiful; but being a Lisp is a handicap (empirically I mean, even if unlike me you grant the ineffable wonderfulness of Lisp). Scala discards loads of Java ceremony and has a plausible actor model; but also way too much syntax.

NodeJS isn’t really functional, but if everything’s a callback and you’re single threaded, who cares? Anyhow, my biggest gripe with Node is the JS part at the end; more on that later.

Go has made a deep impression on me, even though it doesn’t make me smile, the way C and Java and Ruby and Clojure did successively over the years. My intuition is that its types offer enough object-flavored utility to get by. And my strong intuition is that Goroutines and typed pipes hit a huge 80/20 point, ushering developers smoothly into writing functional code just because it’s easy and straightforward and readable. The next substantial server-side piece of software I build will be in Go.

And hey, if none of the above quite gets us where we want to go, we’ve got Rust and Elixir and Dart looming over the horizon; none built by dummies.

Storage, oh yeah · The persistence options are so great now. I’ve been sort of cool to relational data stores for decades, particularly at runtime in performance-critical systems. But they have their place, and there are multiple good open-source ones.

And on the postrelational side things are just fine too. Options range from lightweight memory caches to things that can operate at behemoth scale. Like for example Cassandra; If you’ve heard any of the recent presentations by Adrian Cockcroft about what Netflix does with it, your mind will have boggled appropriately.

On top of which everyone’s internalized that disk is the new tape and is using it sensibly in that way.

On the other hand...

The client-side mess · Things are bad. You have to build everything three times: Web, iOS, Android. We’re talent-starved, this is egregious waste, and it’s really hurting us.

Mobile sucks · I’m going to skip the differences between Android and iOS here because they’re just not that significant in engineering terms. Anyhow, here’s the suckage.

First of all, you have to do your mobile development twice.

The update cycles are slow. Days in the case of iOS, hours for Android (compared to seconds for browser-based apps). What’s worse is that you can’t even count on people accepting the mobile-app updates you send them. Got a critical data-losing account-compromising privacy-infringing bug? Sucks to be you.

The devices are memory-starved, CPU-starved, and battery-starved.

There are loads of form factors and it’s getting worse.

You don’t get a choice of languages; if you hate both Java and ObjC, get another job.

Unit testing is a bitch.

Fortunately for your users but unfortunately for you, the UX-quality bar on mobile is high and there is no fast or cheap way through; it requires inspiration and iteration.

The right way to use the Internet is to click in the search box at the top of your browser and type in what you want, and find it, and click on it, and use it. But if the information or service or whatever that you’re looking for has been sucked into mobile, you have to install the app, which means another level of search in the mobile-app store, where search isn’t nearly as good as what Google and Bing provide.

You can’t make money. Seriously, Apple is always talking about the billions and billions they pay out of the app store, so why is it that I don’t know anyone who’s making serious money on mobile apps?

Of course, the HTML5-rocks crowd is at this point rolling their eyes and pointing out that if everyone just built mobile web apps, then all these downsides (especially the first) would melt away.

Except for...

Browsers suck too · This is an unfashionable opinion, but I can’t see why it’s controversial.

JavaScript is horrible.

> [5, 10, 1].sort();

[ 1, 10, 5 ]

Et cetera. Thus Coffeescript and Dart and other efforts to route around TheElephantInTheRoom.js .

The browser APIs suck too. Sufficiently so that jQuery (or equivalent) is regarded as the lowest level that any sane person would program to; in effect, the new Web assembler. Thus, for actually building applications, you’re going to have to pick a higher-level framework. There are lots of them and they compete vigorously, it’s easy to poke around the Web and find knockouts and cage matches; one good high-level comparo is Rich JavaScript Applications – the Seven Frameworks (Throne of JS, 2012) but wait it’s eighteen months old thus probably now wrong, which is a symptom of the problem. “What problem,”you ask, “choice is good, right?” It is, but this isn’t an orderly choice, it’s a Cambrian Explosion. I’m sure the software archeologists of 2113 will enjoy studying it, but it’s a problem. (Oh, and also read Frameworkless JavaScript by Tero Piirainen.)

CSS sucks too. I’d explain why, except for Dan Cederholm wrote Why Sass? so I don’t need to. Also, check out Luke Page’s Less vs Sass vs Stylus; did I mention “Cambrian explosion”?

There’s no app store for your browser-based client with anything like the scale and size and polish of those for mobile apps.

OK, I know that at every big Web-centric conference, bright-eyed enthusiastic young true browser believers show you how HTML5 rocks and they can write apps that use the accelerometer and microphone and (wait for it) are indistinguishable from a mobile app!

Well, then why isn’t everyone just doing that? Hint: See the bullet points above.

When I said “Mobile sucks”, I wasn’t talking about engineering suckage; in fact, Cocoa Touch and the Android app framework are both very decent GUI-building platforms, embodying a lot of history and hard-won lessons. Crucially, for most of the things you’d want to put in a UI, there’s usually a single canonical solid well-debugged way to do it, which is the top result for the appropriate question on both Google and StackOverflow.

But look at all the energy going into browser tech; surely it’s going to catch up with mobile tech any day now? Maybe, except for the mobile frameworks are being polished and expanded by elite teams at Apple and Google, including some of the world’s best GUI engineers. So I’m sort of expecting the picture to remain fairly stable, going forward.

Diminishing returns · I’m an old guy, and I remember the first wave of Web apps going through, and a whole generation of Visual Basic and Motif and Java and Win32 clients being swept out with the trash, because people liked dealing with everything through a browser.

Of course, fifteen minutes later, software VIPs started saying how the browser’s interface was too dumb and insufficiently responsive and we’d have to find plan B, and I couldn’t help noticing that every one of those VIPs was trying to sell a proprietary plan B. Now we have Plan B and at least it’s right there in the browser, and standards-based.

But I’m still dubious. Yeah, I like it when the app is responsive to gestures, and objects slide in and fade out; but all that feels like icing on the cake, and I confess to wondering how far past the 80/20 point — a well-designed Web app with most of the logic on the server — the ROI stays positive. And I totally fucking hate having four independently-scrollable areas on the screen controlled by weird-looking JavaScript-genius-handcrafted scrollbars. And then I’ll be working with some fancy single-page app, accidentally hit the tab key and everything goes a little sideways. I hate it worse when a nontechnical friend or relative gets caught in this sort of strange loop and I have to try to explain what’s going on.

What’s next? · On the server side, no drama I think; everything gets smoother and better. These are the good old days.

On the client, I just totally don’t know. Historical periods featuring rococo engineering outbursts of colorful duplicative complexity usually end up converging on something simpler that hits the right 80/20 points. But if that’s what’s coming, it’s not coming from any direction I’m looking, so color me baffled. Maybe we’re stuck with clients-in-triplicate for the long haul.