Jeremy Keith wrote a thoughtful blog post recently with a the clever title “Angular Momentum.” During reading it, I found myself nodding in agreement and then disagreeing and reproaching myself for being taken in and then oscillating between the two. I finally landed on thinking that he had written something thought-provoking and insightful and with a degree of subjectivity with room for differing thoughts. It’s a post I both like and dislike.
He started out with an epic description of enterprise software in saying that it is “big, bloated, and buggy.” Who can disagree with that? He also describes it as an instance of the cat food problem – the idea that cat food is advertised to and purchased by buyers who are not the actual end user of the product – in that decisions about technology stacks and platforms and tools are often made by the people with the money or management titles, not the people with the technical expertise and those doing the work – and certainly not by those using the system. He then says that AngularJS falls into this abhorrent category of enterprise software. This was at first and uncomfortable characterization at which I recoiled. I then slowed down and took in his larger point and I appreciate it, though I don’t embrace it completely and I think there needs to be some room to allow for compromise and nuance.
He goes on to describe how the ethos of the web is one of universality and that the idea of Internet is that everything should be accessible to everyone. He deftly describes minimal experiences in less-capable browsers with upgraded fireworks for those with the modern powerhouse browser – the idea that began with graceful degradation and then evolved into turning graceful degradation on its head and instead making it progressive enhancement. He says that this is the way of the web and that sophisticated frameworks relying on users having only the most recent and rocking browsers are contrary to what the Web is all about. To this I say both yes and no. Yes, the ideal is that a site work in any browser its user chooses, but it is time-and-money-consuming to support all the quirks of the many browsers out there. Testing to assure something works under multiple browsers running on differing operating systems is a career unto itself. The degree to which compatibility with multiple browsers is a requirement for a given application is a function of the requirements for that application. There are some problems for which the best solution is software for which you are simply going to need a keyboard and a lot of screen space to effectively use the thing. It would be silly to worry about mobile browsers for such a case. There are also the old desktop browsers – the likes of Internet Explorer 6 and 7. You know, the ones that thumbed their collective noses at web standards and acted as though having a large market share meant they dictated the standard and didn’t need to comply (which was, unfortunately, true). There’s also mobile Safari that uses market share as a club to beat user experience to death and make standards irrelevant. Supporting all these browsers is fine and good, but it doesn’t come without a cost and that cost doesn’t always make sense. If I write a browser and you start using it, does that make someone else’s website responsible for making sure it works in my browser? There’s a limit to all this.
That said, the idea that functionality that can be served with simple HTTP requests and server-generated/served markup, style, and script for devices and browsers with limited resources is an argument that has virtue. I still stand, though, by the assertion that it depends on the application and intended audience. Sometimes it makes sense not to serve someone in order to serve someone else better. At other times, giving everyone an experience is better than giving some a top-notch experience for a few. Ultimately, it depends. What is the intent of the application? Universal access is a reasonable goal for much of what is offered on the web, and it’s a virtue for those things for which it makes sense, but I see no reason universal access needs to be, well, universal. There is room in the world and on the Internet for Web as universal access and for Web as a delivery mechanism with conditions. The beauty of the Internet is the absence of gatekeepers saying how you must deliver your content and products, not a dictum on how it must be done.
Additionally, both Jeremy and the sources to which he links are trying to draw lines between back-end and front-end developers like it’s some kind of Jedi vs. Sith battle with virtuous JavaScript guys and well-meaning but naïve back-enders. I don’t get it. What value is there in having a spitting contest about who has the more challenging of problems? Delivering value to clients, customers, and end users should be the focus of the exercise of software creation and not a wrestling match for which concerns matter more. Additionally, a seasoned software professional should be comfortable dealing with all the challenges and facets of delivering a solution. Maybe in decades past it made sense to say that a person was a front-end or a back-end person, but today a developer needs to be comfortable in the browser and in a database. Trying to partition applications into horizontally sliced tiers where a “front-end” developer can do the web application and a “back-end” developer can do business logic and data access is antiquated and sub-optimal. Responsibility for a vertical slice of system functionality - delivering entire features that users can use with full responsibility - makes more sense than artificial borders around pseudo-technical divisions. Also, the assertion that choices of technology stack for functionality living on the server are unimportant is bordering on offensive. Yes, familiarity with certain tools and platforms and languages matter and can matter more than the actual features of those tools and platforms and languages. I’ll assume that’s what he meant – if something else, I will have to disagree and even acknowledging that doesn’t mean that some platforms and languages are better for certain problems than others. I don’t think this is particularly different with regard to code that runs in the browser. Choosing to use a framework and if so, which one(s) has consequences that matter, but can be overshadowed by the productivity and delivered product coming from a developer who know how to use what they have chosen to use. There are learning curves in any technology no matter where it runs.
That Jeremy calls Angular “Enterprise Software” in the pejorative because clients often come to technical architects/designers/implementers with design and technical direction already in mind is not a rational criticism. He’s pointing out a real problem, but pointing at a bystander and not the perpetrator. Yes, those requesting technical expertise for a problem should come with a problem description and not a solution design. Yes, this is seldom the approach of those with a problem because everyone thinks they have a solution. Everybody has ideas about what the solution looks like and that’s often how they communicate the problem. An exceptional technical person in the role of architect or whatever title is attached is one who can cut through the noise and extract the actual problem from pseudo-solutions and recommend a direction for a technical solution that may or may not follow the lines of what was in the head of the client and tactfully persuade. This has nothing to do with AngularJS. Yes, Angular may be one of those solutions given by a client, just like any other framework or library or pattern. It may happen more frequently than with others. Jeremy acknowledges that his experience of Angular being pushed on him more often than other technologies is anecdotal and deserves recognition of that, but still blames Angular for that experience. A knife can be used to commit a murder, but that does not mean using knives is a bad choice or that they are not “of the tool drawer.” It simply means that if someone approaches you wanting to use a knife to murder you, you are better off being elsewhere. If a potential client/customer/manager comes to you with a problem and they are giving you the solution you are to implement without any flexibility for listening to your expertise and getting to the root of the problem to solve, you are better off being elsewhere. It may be that a mandated solution includes AngularJS or gerbils on wheels powering rendering, but these technologies are not the culprit in the wrong choice being made for the wrong reason, they are just the tools that were chosen by the wrong people at the wrong time without the right effort put into identifying the problem before arriving at the solution. I agree it’s a mistake to make implementation decisions before deciding on what the thing does, but I don’t think that problem is isolated to any framework, library, or platform. It’s a near-universal human condition and a near-universal human fault.
I like Jeremy’s emphasis on subjectivity in how one views the web and that philosophy is important and that one should act in accordance with principle. Ultimately, though, I think Jeremy is making the same mistake for which he is criticizing AngularJS (though it’s not really a criticism of AngularJS, as I have pointed out, but the choosing of AngularJS (or anything else) without considering whether it is a good fit for the problem) – he is demanding universal access for all web application without thinking through what it is that the application is trying to deliver. Ok, he’s not demanding it, but strongly asserting that universal access is a matter of principle and not one of the right fit for the right problem and that violation of universal access is a question of virtue. On this I disagree. Accessibility choices, like technical choices, should be made with an eye – nay, with both eyes – on the problem for which the software is intended as a solution.