JavaScript: A tool too sharp?


But, Roy Osherove believes so.  When I first started JavaScript, I thought so too.  My problem was that I approached JavaScript from the eyes of a C# developer.  But C#, JavaScript is not.  So what are the main gripes of JavaScript?

  • No tooling
  • No refactoring support
  • No navigation support
  • It’s not C#

One solution is to use something like Script# to generate JavaScript from C#.  This is similar to the approach of the Google Web Toolkit, with the exception that GWT has a whole ecosystem to basically be able to develop Swing-like applications on the web.

But something like Script#?  If you’re looking to program C# on the web, that’s the way to go.  But it’s a little unfortunate, as JavaScript is a very powerful language with features you simply can’t find in many other places.  The arguments against are very similar to what I’ve heard about other dynamic languages, yet the Rails developers seem to be productive.  Why is that?

My opinion is that it’s simply a very different mindset working in a dynamic language.  And before libraries like jQuery that really used JavaScript like it should, it was a lot more difficult to do interesting things.  I can’t imagine giving up features like prototype for generics.  In fact, I’d much prefer prototypes to generics, it’s just more powerful.  So how do we close the gap?

First, drop any assumption on how developing JavaScript should be.  It’s not a static language like C#.  It’s a dynamic, scripted language, not a static, compiled one.  Next, if you already know OOP, dive into some great JavaScript resources:

JavaScript is a beautiful little language, but it is not a forgiving language.  If you’re a procedural developer, or don’t know OO too well, JavaScript will eat you up.  Working with a language that has functions as first-class citizens actually changed how I use C#, and it would be rather unfortunate to skip the JavaScript experience in favor of a static language.

So what’s missing in my JavaScript experience?

For one, I still don’t see a great TDD story.  Most of the TDD examples I see go against a static, fake HTML page, which I don’t really see that proves anything.  I know how to TDD C# code, but it’s still not the same experience doing JavaScript.  Roy does have a great point, that your JavaScript files can get out of control.  It’s hard to find great canonical examples of how to develop and organize a solid scripted website.  I see a ton of small examples, but nothing on par of the DDD examples out there.  But given a little patience and some good reference material, JavaScript is one of those languages that can really open your eyes on what is possible beyond the barriers of C#.

About Jimmy Bogard

I'm a technical architect with Headspring in Austin, TX. I focus on DDD, distributed systems, and any other acronym-centric design/architecture/methodology. I created AutoMapper and am a co-author of the ASP.NET MVC in Action books.
This entry was posted in C#, JavaScript. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • “JavaScript is a beautiful little language”

    I couldn’t agree more, there’s a video out there by John Resig entitled “The DOM is a Mess”, in which he says: “When people say they hate JavaScript, they probably mean ‘I hate the DOM’”

    This is true, most JS problems are not with the language, but with the DOM.

    I feel that JS is getting a lot of momentum in terms of respectable tools out there, a good sign for web developers! :)

  • I’d recommend that you take a closer look at MooTools. MooTools embraces the native JavaScript language even further than jQuery and includes similar syntactic beauty of jQuery.

    The beauty of MooTools is that it embraces a Class-based and object-oriented model that we’re used to with a strong background in .NET. But in the paradigm of JavaScript. It makes it very modular and extensible which is a must in large scale applications.

    That’s why Google has GWT – to make things like Gmail which needs more competent tools than a simple DOM wrapper.

    That’s no reason to give up on JavaScript as a language. Quite the opposite.

  • I think calling it beautiful is going a little too far. ;) You just need to re-read the “Bad parts” appendix of “The Good Parts” book to remind yourself – and its not just because of the DOM.
    As for TDD, we’ve had success by creating “controller” objects in separate .js files that handle all of the logic in a page, and test them via qunit. All references to dom elements are handled via jquery selectors passed in as options to the controller, so the code is independent of the page it is used on.
    Yes, there is still a gap in running the code against the real page, but that is covered by integration/acceptance tests (via StoryTeller/Selenium).

  • Leyu Sisay

    There are some great videos by Douglas Crockford (The JavaScript Programming Language, Advanced JavaScript, JavaScript: The Good Parts and others…) on yui theater.

  • Dennis

    Dojo seems to have pretty good tools for developing a large javascript program. For a good sample, check out the sourcecode for Bespin, a programmers’ text editor written from the ground up with nothing but javascript, dojo, and the Canvas element.

  • mhanney

    Regarding tooling and refactoring, JetBrains is strong in this area. RubyMine has a great JavaScript editor w/ navigation and refactoring tools similar to ReSharper. Source control integration, including Subversion, is built in and very good.

    JetBrains also have a new IDE specifically for the languages of the browser – Web IDE – early access program now open And Firebug deserves a mention, it is an excellent debugger.

    I completely agree with the TDD commentary. Testing is particularly difficult when modern javascript uses closures and callbacks – how do you test values in the result of an asynchronous method call?

    For me, a C# web developer, taking JavaScript seriously happened when I moved away from Web Forms and resumed working with actual HTML, JS & CSS in ASP.NET MVC. I also have more time to concentrate on the language of the browser since the drudgery of writing CRUD data access code was solved by NHibernate. It is a very important language, particularly with HTML5 coming, and will continue to solve many of the rich UI requirements that people are using Silverlight for. I wonder if people would sooner target Silverlight, using the tools with which they are familiar, than learn to use JS effectively?