I mentioned the other day how much I prefer a fat-client approach to today’s standard and largely unquestioned reliance on browser-based solutions. I want to step into it, even knowing I’m gonna get yelled at.
Freely made admissions to start: 1) I admit there are situations where a browser is best. 2) I admit that some modern internet-stack environments are better than others. 3) I admit that most of what I’m critiquing is today’s typical practice, not necessarily "what is possible".
Please. I make these admissions to forestall yabbitting around exceptions. I am talking here about mainstream software development practice as it is justified and executed. Your mileage, in special circumstances mentioned above, will almost certainly vary. That’s ok.
My contention is that browser-solutions are ubiquitous, everyone’s first response to every problem, but that this default answer is based on deep overestimation of benefit and deep underestimation of cost. The overwhelming theory of the benefit of the browser solution: write once, run anywhere. Secondary benefits include "skinnability" and "uniformity". I would like to consider all three.
First, write once, run anywhere.
Well reader, it is to laugh.
Write once run anywhere HAHAHAHAHAHAH.
It can be done, almost, if you’re a highly skilled HTML+CSS jock, who knows their CSS at the master level. You can make a 3-case pile of CSS that formats to fit big, medium, and small screens.
If you’re very good at it. And you only focus on a single browser. But there isn’t just one browser. There’s, what, five? Oh, and don’t forget versions. let’s say maybe 8-10 total, and to hell with the rest of those weirdo-browser/ancient-version users.
And there we go. Right there, as soon as you say "to hell with" you’ve done two things. You’ve admitted it’s not write-once run-anywhere, and you’ve admitted that you’re perfectly willing to force users to install an app on their device for no other reason than to use your service effectively.
Which app do I mean? I mean the browser that works, for whatever value of works is important to the user. If they want your service, they have to install and/or update the browsers you support.
And, this is key: all of this happens at time T, and lasts just as long as the update stream for your browser/version set is stable. Please to note you don’t control the stability of your b/v update stream. Your write-once-run-anywhere has become write-when-you-don’t-necessarily-want-to-run-on-your-bv-set.
I hope my meaning is obvious. That’s a big blow to the biggest benefit.
One more point about runs-anywhere: even if you pull it off, for the majority of services, you don’t need it. Most enterprise apps are run by people in the enterprise. Most other apps have far smaller audiences. That’s not remotely "anywhere". That’s "my user base".
Next is skinnability. The idea here is that we don’t have to have geeks design our look and feel. We can let geeks write code, and we’ll use web designers to put a skin on it, enterprise or other. The official rationale here is division of labor. The unofficial rationale: artists are silly-willy aesthetes with no mind for computers, and geeks are logic-mavens with poor personal hygiene and a fondness for comic sans.
This is nonsense, and it’s insulting nonsense at that.
I know of not a single serious front-end designer who isn’t every bit as much of a geek as any serious back-end designer. It’s a matter of specialty and skill inside a broad umbrella of technicality, not two readily separable disciplines or populations.
Besides which, skinnability is a lot like runs-everywhere. It is needed occasionally, it’s not a universal value that all applications need to have, especially given how very not free it is to get.
And my third alleged benefit, uniformity, more specifically uniformity of company practice, skillsets, knowledge. As usual, an overrated benefit.
First, uniformity is simply unrealistic. Large apps rest on dozens of technologies, all of which are changing constantly, and many of which are being replaced by far more effective technologies. You still have huge variation in talent and skillset and knowledge. And guess what: that’s meet and just. It is exactly what you want, especially if you want high productivity.
That’s the benefit side of the story: the three big browser-solution benefits, the ones that make us reach for a browser-solution by default, are usually some mix of entirely illusory and entirely unneeded, especially when you get to how much they cost.
I have gone on too long already. Stay tuned for the next episode, when we talk about that cost.
Foreshadowing: the standard practice is grim beyond belief, valuing these highly sketchy benefits in the made over real success in the making.