The productivity argument behind JavaScript

Greg Low has followed up on my post about HTML and JavaScript by presenting an argument about productivity which you can read here:

Developer Productivity – MIA? – The Bit Bucket

In his post, he argues that the developer productivity for writing JavaScript is much lower than for writing .NET code.  There’s a few points that Greg raised that I’d like to comment on here:

1) Use of JavaScript pushed the timeline of an application ‘out’.

I think that this one is low hanging fruit.  While Greg is quick to call JavaScript the villain here I’d be surprised if there weren’t a number of factors that rate much higher in the demise of projects such as this:

  • Lack of clear vision
  • Lack of requirements
  • Constantly changing scope
  • Changing technology (use of technology that changes during the project)
  • Customer relations
  • Bleeding-edge technology
  • Changing resources on your team
  • Other quality indicators (unit testing, co-location of agile workers, etc)

If you were to use that list and rate each of those factors as a possible cause of any blowout, my bet is that you’d see JavaScript pale into insignificance – probably to the same level as whatever .NET language was used on the project!

 

2) Tooling support

As Glav mentions in his follow-up comments to Greg’s post, the tooling support in 2008 is already much better.  In fact, I’d go as far as to say that, aside from ‘type inferencing’ we already are there.  Actually, even with ‘type inferencing’ I’d argue that many more bugs in an application come from incorrect logic than come from incorrect data-type usage.  To catch these errors you can really only use unit tests.  So, if you are on a project which has bugs, ask yourself, did you have good unit test coverage?

By creating unit tests for your JavaScript will actually force you to write client-side code that is a well factored and of a similar standard to your server-side code.  You cannot write nice OO-style .NET code and compare it with a plate-of-spaghetti style JavaScript code that you’ve cranked out.

Having said that, while it isn’t too difficult for an advanced programmer to write a suite of unit tests for their JavaScript code, I’ll concede that not much tooling support exists here yet for the ‘day programmer’.

 

3) Cross-browser issues and the DOM

ASP.NET Ajax gives us the Sys.UI.DomElement and Sys.UI.DomEvent which act as an abstraction layer to many of the browser issues that exist today.  As opposed to what many people say about the HTML DOM, I really do not find it to be terribly difficult – just remember that everything is a DOMElement and you’ll do fine 🙂

 

Conclusion

In my original post I finished by stating that "it’s not a binary argument".  What I meant by this is that we won’t end up with Silverlight *or* HTML+JavaScript as some of the people who make statements such as "JavaScript is broken" would probably have you believe.  In the past 3 years, Microsoft has made 2 massive investments in the webdev space: Silverlight and ASP.NET Ajax.  My advice is that, if you really want to be a relevant ASP.NET web application developer in 2008 and beyond, then you must learn both of these.  Hiding behind an argument of "JavaScript and HTML are broken" will only serve to reduce the pool of work that is available to you.

The one final thing that Greg mentioned that I’d like to touch on was this comment:

if I had needed to quote the development of that same project as a winform app, I would have quoted several weeks in total, not several months and just for me, not for four or five people. What on earth have we done to developer productivity in recent years?

There are many times when I feel the same way but it’s generally when I either have some weak links on the team or, more often than that even, is when I have a team which has not yet formed properly yet.  A great team cannot simply happen by bringing several talented people together and throwing them into separate dark rooms.  Great teams grow with each iteration.  Once I have grown a team, then it’s very rare (if ever) that I would back myself against it to deliver something of a similar quality level.

Advertisements

~ by D on December 31, 2007.

3 Responses to “The productivity argument behind JavaScript”

  1. Hi Darren,
     
    My comparison was not really JavaScript vs .NET languages, it was on web-based development compared to alternate technologies. That\’s where I think the real loss of productivity has occurred. The industry has made a big push into this territory but I suspect that most of the reason for it has been based on issues related to deployment. There seem to be only two real arguments: one is ease of deployment, the other has been cross-platform support. The deployment issues could have been solved in a variety of ways. I\’d suggest the cross-platform support still hasn\’t really been solved, not to any acceptable quality bar.
     
    In the project I mentioned, a good suite of unit tests, etc. were present. Silly amounts of time however, were spent making sure that things that looked great in IE7 and Firefox2, were acceptable (and in some cases even usable) in IE6. And only IE7, IE6 and Firefox2 were targeted. I can\’t imagine how much time might have been added if Safari and Opera support had been required.
     
    I think Silverlight offers a glimmer of hope here. But even with it, we\’ve gone from an era where the amount of effort an average developer would expend producing ordinary-looking UI fairly quickly to an era where the same effort produces worse-looking UI slowly. That\’s not where the tools should be taking us.
     
    Regards,
     
    Greg
     

  2. >> Silly amounts of time however, were spent making sure that things that looked great in IE7 and Firefox2
     
    OK, fair point.  Mind you, on most of the WinForms projects that I\’ve been on, you lose ridiculous amounts of time nudging pixels around the place too.  Not really weakening your argument here, more to the point, I\’m just suggesting that the UI seems to be where incredible amounts of time are lost regardless.  Of course, as you say, on a public facing website, the browser capabilities do add extra pain.
     
    I still think that much of this can be solved with a richer control-set.  Admittedly that is harder if you have to roll all of your own.  But there\’s plenty of good looking options out there for ASP.NET now.

  3. Beautiful Posting!Thanks For dedicating  this Article to The Community !Or to the social Network in Genaral,where live,s happen ever moment!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: