Yesterday I went to this year’s Atlanta Code Camp, which I had learned about through the Atlanta JavaScript Meetup mailing list. Code Camp is a very Microsoft-centric developer symposium, whereas my bread and butter lie firmly in the Java world. However, the event offered several interesting sessions on “single-page application” (SPA) JavaScript frameworks, and cost only $5 for the full day including lunch. Sold!
The speakers in the SPA sessions gave an interesting amount of attention to a framework called Durandal, an AngularJS competitor built on top of Knockout and RequireJS. I was surprised to see Durandal and Angular getting equal billing from all the speakers, since I had never even heard of Durandal before.
Later it occurred to me, I’ve also never hung out with several hundred Microsoft developers before! I checked out the “Testimonials” section of the Durandal website, and noticed a pattern:
Durandal is the missing piece in my Knockout SPA toolkit. It handles the infrastructure and lets me focus on delivering functionality. Powerful, yet lightweight, pluggable and built on proven patterns from WPF/Silverlight development.
Hans Fjällemark, Freelancing HTML5 consultant – Tellurian InteractiveDurandal brings capabilities from Caliburn.Micro to JavaScript clients that we sorely missed. Love the screen management and convention-based composition of Views and ViewModels.
Ward Bell, V.P. of Technology – IdeaBladeRob set high standards with Caliburn.Micro… When we develop WPF/Silverlight applications using it, we get better code organization, flexibility and, ultimately, higher code quality and team productivity. He’s done it again with Durandal – which brings all of the same qualities to the world of HTML5 applications. Amazing work!
Srdjan Strbanovic, CTO – Cignium Technologies
It turns out that the founder of the Durandal project, Rob Eisenberg, is also director of a popular Windows GUI framework called Calliburn.Micro. Both projects feature mythical sword motifs, as well as a few paradigms apparently borrowed from Silverlight development.
I should stress that although I’m not a Microsoft guy myself, I DON’T mean to imply anything negative about Durandal by association. From what little I saw at yesterday’s symposium, it looks like a capable competitor to Angular with some really good ideas.
What I DO mean to say is that this weekend made me think about JavaScript development in general. Where its ideas are coming from, and where they may be going.
Who exactly are JavaScript developers, anyway? Of course there are some full-time rockstar JavaScript samurai, err, ninjas
- HTML or graphic designers, who by necessity have picked up some JavaScript as a secondary skillset, or
- Back-end server-side developers, who by necessity have picked up some JavaScript as a secondary skillset.
One of the selling points of Node.js is the idea that you can take Group #1 guys, and re-purpose them as advanced server-side developers. I believe that this is wishful thinking. It’s not that I don’t respect HTML or graphic designers (I do). It’s just that the skillsets involved in design and development are quite different (as seen in my own primitive designs!). In whatever setting you write JavaScript, my experience has been that Group #2 guys wind up handling the more advanced stuff, simply because it’s more analogous to the regular work we do with our “real” programming languages. This may change in the future, as younger developers come of age knowing only richer clients and thinner servers, but I think that’s the workforce we have today.
So if advanced JavaScript is indeed being written by moonlighting server-side developers, should it be surprising that JavaScript frameworks borrow from server-side frameworks? Should it not be expected that communities will gravitate around JavaScript technologies based on server-side affiliations?
Durandal seems popular among Microsoft developers, because it originated from that community. In addition to Rob Eisenberg himself, Durandal’s underlying Knockout library was created by Steve Sanderson, a .NET author and Microsoft employee. These frameworks no doubt feel more familiar to developers coming from a similar background.
CoffeeScript is huge in the Ruby community, because it’s about making JavaScript development feel more like Ruby development. Batman.js, another SPA competitor to Angular and Durandal, describes its motives straight-up with the tagline, “A client-side framework for Rails developers“. The popular Jasmine testing framework seems largely inspired by Ruby’s RSpec.
TypeScript has generated a lot of buzz recently in the C# community, as it adds the strong type-checking that enterprise developers miss when dealing with JavaScript.
The Java crowd has shown some interest in TypeScript as well. However, Java developers working with JavaScript tend to gravitate toward Google technologies and/or other cross-compiler solutions. Things like GWT, Dart, or ClojureScript. The recent AngularJS wave can be seen as backlash to the longstanding Java community view of JavaScript as a “bug” to design around. The QUnit JavaScript testing framework looks and feels just like JUnit. So on and so on…
Node.js supposedly minimizes the “context switching” involved when using one language on the server-side and another on the client-side. However, most of the new developments in JavaScript today actually arise from the switched contexts of other languages, and their established libraries and frameworks.
Perhaps all of this should be recognized and discussed more openly. I mean, if you’re starting a JavaScript-intensive project, and are lucky enough to have a team of developers who have worked deeply with JavaScript as their primary language for years, then that’s great! However, it’s far more likely that your group’s “real” language is Ruby or Python. Or you’re in a Java shop. Or a .NET shop, or something else. So when you are selecting a JavaScript library or framework for a project, an important factor to consider is your team’s existing server-side affinity, and which JavaScript options line up with that community.
Of course this presents a danger, that you might be too biased. Say you take AngularJS and Durandal for test drives. You happen to find Durandal more intuitive, or better fitting for your requirements. If you choose AngularJS anyway, “because we’re not a Microsoft shop”, then that’s a mistake. Same goes for a Microsoft shop that rejects AngularJS, simply because those Google guys use the term “MVC” rather than “MVVM”. The affinity of a JavaScript component to your “real” language should be only one factor in your decision-making. But it should be a factor.
