’ve been developing in JavaScript for a long time and have seen client side techniques evolve drastically over that time. However, I have to say right now is about the most frustrating (and promising) time to be working with JavaScript in a professional capacity that I’ve seen in many years (and possibly ever). Let’s do a little retrospective of what I recall from back when I started really getting into computers.

For me, in the beginning of dealing with the web, there was Mosaic (yeah, I’ve been around a while). Mosaic was nice (or was at the time) and was an excellent start. I didn’t do any JavaScript back in those days, although I did write the occasional bit of HTML (I think I remember when LiveScript was released with Netscape, but it’s been some years since then). It was the blissful, simple paradise of the new user and it was a glorious time to be euphorically recalled once long past. The tag had yet to appear on the scene (or at least I didn’t know about it, maybe it did exist at some point by then) and web browsing was limited.

Later, there was Netscape, which was the awesome sauce of the time, along with a few other browsers following later. I tried JavaScript back then (as well as more complex HTML) and found cross-browser support so bad that I didn’t bother and decided to stick with desktop applications because the web was still in that awkward stage, where it might eat glue or stick a fork in a light socket. It was…unpleasant, but the potential could be seen.

Eventually, I made the switch to Internet Explorer, as Netscape ground itself into the dust of history, first by progressive bloat and then by a disastrous attempt at a rewrite. JavaScript still sucked, and it was running in a browser that was acceptable for the time. Eventually, Microsoft would let IE languish on the vine, secure in the notion that there would never be competition (maybe the occasional bit of monopolistic practice helped with this….). They even included it with the operating system and allowed you to update the OS through the browser (which is pretty much the gas station sushi of security practice, in my opinion). ActiveX came into the browser (and more importantly, touched things outside the browser) and a billion security holes erupted onto the scene. Later, VB6 web classes would be briefly become “a thing”, before tottering over and dying like so many mayflies. I did mess with those, but ultimately found the value they provided to me to be limited (I was still in college by this point). Later, the problems with ActiveX and all the hooks Microsoft put into the browser to make their stuff work would result in increasingly terrible security issues. They would also give birth to a new era of web development, although we didn’t know it at the time. Asynchronous JavaScript and XML (or AJAX) would be introduced to allow pages in the web browser to get data from the server without a full postback. The impact would take a while to be felt. Like JavaScript (a scripting language that ISN’T actually Java), it would be horribly misnamed, as it wasn’t inherently asynchronous, JavaScript, or XML, but I digress.

Eventually, IE would start introducing enough security holes that I switched to Firefox. By this point, I was doing professional ASP.NET development full time, but avoiding JavaScript like the plague (it was) anywhere I could. It still sucked, and what was worse was the browser ecosystem of the time, a retched pile of bad interactions and utterly incompatible code that caused you to waste more time trying to get something to work in a second browser than it took to get it working in the first. Consequently, most employers demanded Internet Explorer, and usually wanted an old version of it, in order to avoid surprises. Lots of crappy in-house ActiveX code was in use then (as well as a few things that might well have been called brilliant, but this was the tail end of the dark age of the web), and more was still being written. Everybody was still locked into a browser that shipped with the operating system, had horrible security vulnerabilities, and was not keeping with the times. JavaScript was a little better by then, as you’d see the occasional tutorial showing some decent technique and actually putting code inside script blocks instead of directly in event handlers and the like. It was still ugly and best avoided.

Suddenly, seemingly out of nowhere, JavaScript frameworks started arriving. This actually overlaps the previous paragraph by a bit, but I missed some of the early development of JavaScript frameworks because I remember thinking “when the whole language is a raft of slimy hacks, why would I want a “framework” made out of the same. So I missed some awesome sauce like Mootools and the like. I did, however, eventually encounter jQuery. I think a lot of us were a bit shocked by jQuery when it came out. Not only did it fix a lot of the quirky issues between browsers transparently, but it also suddenly made JavaScript “not suck” for the most part and it even made it easy for us to use AJAX, even in boring corporate applications. Eventually, more developers came to realize that JavaScript was a beautiful language, bolted onto the ugliness which was the browser ecosystem of the time.

A few years passed. Loads of people evacuated from Firefox to Chrome when the former got buggy and slow, leaking memory all over the place and even occasionally having security issues. Internet Explorer started getting decoupled from things. ActiveX started slowly dying off. We got better development tools in the browser and major platforms started treating JavaScript as more of a first-class citizen, especially as smarter patterns started getting used in server-side code, like the MVC pattern. Silverlight hit the scene and looked like it was going somewhere, but after a while started looking a lot more like it was going to be very limited in utility (even though it’s still used a lot, it really seemed to miss out on its potential).

Later, taking the idea from Silverlight (I suppose, maybe they came up with it themselves), more JavaScript frameworks started having viewmodels and databinding, which drastically improved the experience of working on those platforms. Now, instead of a fever swamp of nested jQuery code, we had clean class-like objects (I used KnockoutJS) and bound them to controls on the page. There were still difficulties though. For one, lots of people were now pushing JavaScript to its limits and learning just how it was very much not like their favorite server-side languages, particularly in regards to scoping issues around the “this” keyword, lack of true object-oriented features, and loads of nastiness around variable hoisting, equality operators, and various other oddities of the language. But life was improving.

Still later, other, more extensive frameworks popped up. We started seeing frameworks like Durandal, Ember, and Angular, which brought far better models of development to the client side, effectively bringing the client-server model that was once the domain of desktop applications into the browser. They brought with them templating systems, like mustache and handlebars, that made templating much simpler on the client (although, they had their own fun issues as well). In addition, they brought modularization that allowed developers to compose fairly complex systems on the client side of the application that could talk to services on the back-end. Web sockets got used more frequently (and more impressively as well), and better patterns for dealing with asynchronous calls were developed, such as promises, which are a fair bit cleaner than the callback-based mechanisms we used to use back in the old days with jQuery. It seemed like a golden age had dawned, with web technology not only being clean and integrated well, but in actually expanding to other environments, such as the server (NodeJS), living within native apps on various platforms, and even making inroads into database technology.

Which brings us to the present. All this opportunity has made developers do what is in our nature. Build things. In this particular case, we now have an explosion of both client-side and server-side frameworks, plugins, libraries, and various approaches for each of them, many of which are not even in the same paradigm. Angular is being drastically changed in the next version, which is going to be supported by Google. Durandal is going through massive changes as well (and is supported by Rob Eisenberg). ReactJS has shown up on the scene with several compelling new changes to the way JavaScript-focused applications are being built. At the same time, JavaScript itself is changing, bringing in a lot of the features whose lack we ran into way back in the day in the next version. In addition, new languages, such as TypeScript and CoffeeScript have been around a while and get rid of numerous pain points in JavaScript.

So, here is my frustration. I’m working on a major re-imagining of the flagship application at the day job. I also have a side project that is getting close to being ready to release, along with several ideas that are on the back burner. I expect a clear winner for my use cases to emerge in the next twelve to eighteen months. However, that winner isn’t present right now. It’s an enormously risky time, as picking a path means being married to it for the foreseeable future, as none of these projects can be trivially rewritten. It looks like the options are those below:

1. Pick a framework that is great right now and meets my use cases. The clear winner at the moment for me is AngularJS, bar none. With TypeScript on the back end, this is an enormously powerful tool for me. However, I don’t know how long the existing version of Angular will be supported once the new version comes out. A year? Eighteen months? Or will it be forked and maintained for several years, ala. jQuery 1.x? Right now, that’s up in the air.
2. Pick several frameworks that together can provide what I need. If I go this way, I’d likely shoot for ReactJS and Flux. I like what I see with those and React is not likely to die anytime soon, with Facebook supporting it. The trick here isn’t the long term support, but rather the short term support. I’ve been burned by depending on code that dealt with Facebook and I’m concerned that breaking changes may be made more quickly than I can handle them (remember, I’m building products which are also going to need bug fixes, additional features, etc. – that’s hard to do with the framework being moved under you). I’m also not entirely sure of how well the tooling will work for me on Visual Studio, even though that’s increasingly less of a problem as Microsoft wades into the open source world.
3. Pick one of the upcoming frameworks that I think has excellent potential, but isn’t ready to go out the door yet. For this, I would probably go with Aurelia, which is somewhat the next version of Durandal. Quite frankly, Rob Eisenberg impresses me a lot. His work has been flat out solid, and his departure from the Angular 2.0 team initially made me a little nervous about the future of that project (but to be fair, they have a most excellent team as well, so I would consider them a near second nipping at his heels and I’d be interested to see how they look six months hence). I’d probably try to use it right now, but the site FAQ tells me not to use it in production yet.
   So what’s a fellow to do? I can’t put everything on hold while everything is in flux like it is now, and making a good judgement call is going to be tricky. There is so much promise in the landscape right now that it is incredibly frustrating to try and pick a single direction to go. It’s not a bad frustration to have (it beats having two choices, both of which stink), but there are enough choices to induce paralysis by analysis. I think much of the rest of the industry is in the same boat. I’m leaning strongly towards continuing to use AngularJS in its current form, while carefully refactoring based on the 2.0 migration guidance as it comes out. I think this offers me the best chance of getting something built in the near term, while helping to insulate from problems further out. I’ll also need to build a full set of regression tests, as even with good guidance, the migration to the next version will not be easy. I’ll need to be able to quickly identify areas where changes have caused code to break (Typescript will help as well).

What are the thoughts from the peanut gallery on this? Am I going to look back on this a year or two hence and regret this decision?