Choosing JavaScript frameworks, the bigger picture

It looks like I haven’t written in a long time. On the contrary, I’ve been writing a Lot, just not all here. And what I have written here I haven’t posted simply because I’ve been holding onto it all for editing. One of these days I need to put it into my ToDoList to just edit and publish everything over a short period of time. Not that anyone will read it… Anyway, today I received a note from a colleague about AngularJS training. That spawned a lot of thoughts which I’ll share.

I haven’t immersed in any of these library/frameworks. Personally I need a solid business case to move forward with any of them. As soon as I immerse in AngularJS someone will say they have a project that requires Backbone, or Ember, or KnockoutJS. It’s already happened. It’s easy to make a technology choice and get it wrong in the eyes of the client. For example I had a case where the client said “I want .NET”, so I wrote code in C# and they came back with “no, we wanted VB”. That’s tough, it wasn’t in the contract, they need to pay for conversion. But aside from such pragmatism there’s a client who is displeased with code that does exactly what they wanted. In this case an educated consumer isn’t a better one – or at least a partially educated consumer – or shall we say, a consumer who thinks they’re educated. Their interpretation of what they read (or what their nephew tells them) is likely to narrow down the choice of tools that they believe are right for their project. The project becomes more about the nuances of the tools than their higher-level business goals, about the moss on the trees rather than the forest. The same can happen a soon as an end-user discovers some JS framework is great for small numbers of events but poor in performance as the event count increases – while we might have chosen it because it’s fast with larger data volumes. It’s tough to “win” in these situations.

Diversity is good. Choice is good. Innovation is good. But the proliferation of too many incompatible choices has slowed down the entire industry for way too long. We see this in Java vs .NET, Apple vs “everyone else”, browser wars, and MVC vs MVVM. That’s not the same as product-specific choices, where there are just a few options, like Flash vs Silverlight, or Android vs iPhone. Over the last several years with masses of people coming back to JS as a powerful platform, there has been this proliferation of frameworks to address many focused needs. I’m hoping the web development industry shakes itself out – like the Linux industry shook out the explosion of distros into just a few top-tier platforms. Or compare this to the auto industry where they’ve all agreed to provide us with vehicles that have four wheels, steering wheel on the same side, and the stereo and heating/cooling buttons pretty much in the same place. Standardization can be good at that macro level – it’s tough for anything radical to emanate from that industry. But you can’t go wrong in the eyes of the consumer with another four wheeled vehicle that has a steering wheel and buttons in the same place as every other vehicle they see. I’m not alone in my sense that I’ve had enough with tool disparity. These thoughts I’ve had for a long time have been echoed independently elsewhere.

But this situation is what it is. We do need to make educated choices. So as professionals we need to understand the pros and cons of the various offerings. Unfortunately most end-users don’t understand that the difference between us and some $25/hour programmer (or the “computer genius” nephew) is that we do this kind of research. The difference is that many of us have spent weeks at our desk with no compensation, reading poor documentation, slogging through forums for answers to fringe cases, and writing little code samples for ourselves so that we can understand syntax, code flows, and issues we’re likely to encounter later. And each time something new becomes vaguely popular we need to do the same thing, in the hope that someone will ask us for that technology … and often it never happens. (Sounds a lot like the pharmaceutical companies who spend billions of dollars on research that never translates into drugs on the shelf.) Meanwhile the $25/hour programmer/nephew just tells a client what they think is best (the only tool they know is often the “best” – seriously, I’ve had that discussion with people). The rest of us must struggle to make a connection with the next tier of client who has a better handle on such dynamics – that they should be paying for a developer with broad practical experience, not just someone who can write code.

So where do we go with this? Frankly I’m struggling with how to incorporate any of these JS frameworks into my projects that use ASP.NET. I just don’t have a solid handle yet on how to get a complex JS framework to do its thing without conflicting with the communications and back-end processes with which I’m familiar. Separating tiers is good but the reason we use these tools is so that we can make use of a single technology end-to-end. As soon as we start bringing in new best-of-breed technologies it’s time to reconsider exactly why we’re using end-to-end solutions. Sure, we can drink some Kool-Aid and buy into the notion that now ASP.NET is being positioned more of a team-player in a polyglot N-tier topology, but the reality is that we need to make all of this stuff work, and our clients don’t want to hear about time delays due to some incompatible data on the wire, they just want their data to flow from here to there. So my approach now is to try to familiarize with as much as I can at a high level, but to keep most of my code as free as possible from other bolt-on frameworks. Admittedly, that’s tough because I’m not taking advantage of new code which does offer many advantages over a lot of hand coding. But that’s where I come back to, OK, so which JS framework(s) do I adopt? Someone can easily argue that full adoption of a new framework just shifts the baseline – that the toolkit can/should include AngularJS today as the firm client-side tool of choice to simply get the job done, and that can change later if required. Sure, that’ll work, but like I said, I don’t want to have to argue with someone later about why I didn’t choose Knockout or Backbone.

You see, these are the choices we have to make. Do we focus and become expert with one tool? Do we take more time and broaden our scope so that we can pick the right tool for whatever job that comes along? That implies that we actually need to be competent with a wider variety of tools. (Jack of all trades, master of none?) Do we lock-in now but keep our eyes open for the next better solution?

I dunno about you, but after learning some 20 programming languages and dialects (going back to Dartmouth BASIC, Fortran, COBOL, BAL, APL, RPG, then on to various OOP languages) I’m tired of it. I’m not going to jump on ObjectiveC because that’s what Apple says … or jump to Swift because that’s what they say Now. I’m frustrated with paradigm shifts, like from Android Dalvic to Art. I’m tired of dealing with massive protocol shifts like XML-RPC/SOAP/REST and ODBC/ADO/OLEDB. I never jumped on to C/C++ heavily because of the major changes in MFC/STL/ATL, etc – a lot of this wasn’t evolutionary, it was just Microsoft changing the landscape based on what they had on their minds at the time. I’m tired of working with software that’s great but “has its share of bugs” – I can’t afford to jump on a bandwagon and then realize (once again) that the tools just aren’t stable enough to get through any project without some funky hooks.

I just want a stable platform for developing solutions to business problems.
I’m choosing technologies a lot more carefully these days.
Or maybe I’m just getting old.