JavaScript

Lately I’ve found myself doing a lot more web application development in JavaScript.  Typically, I always seem to fall back on plain old Notepad++ or Visual Studio.  As a developer, the user experience in either is, IMHO, somewhat lacking.

However, for the past week, I’ve been using RubyMine.  RubyMine is a Ruby on Rails IDE from Jetbrains, but it seems to work rather well for editing JavaScript and HTML files.  Plus, as an added bonus, it automatically comes with built in support for jQuery.

Well, I don’t know why it’s taken me so long to get to get around to this: but I must say that there are now a couple of “must haves” in my web developer’s tool box.  One of them is jQuery, and now the other is QUnit.

Chad Myers has a good, quick, post introducing QUnit, I’d strongly suggest checking it out if you do web development (which, IMHO, implies some use of JavaScript, right?).  Chad’s post covers the basics pretty good, and I think I would just be duplicating/plagiarizing Chad’s work if I were to blog the hour or two I spent getting to know QUnit here.

One thing I noticed since I started doing ASP.NET programming back in 2002: I started using Javascript a lot less, and my copy of JavaScript: The Definitive Guide sits on the shelf gathering dust.  I’ve noticed a lot of developers I’ve worked with are the same way. In fact, I’d say that most of the ASP.NET programmers I’ve worked with these days really don’t know much about Javascript.

I don’t blame Javascript itself for this - I blame ASP.NET. Developers just get used to dropping the server side controls on their WebForms, and then doing everything server side. I’ve also worked at clients which had a “no client-side javascript” rule. All of this combines to cause our (my) Javascript skills to atrophy and wither. Kind of shame, really. (note: to a degree, I think the same can be said about CSS).