JavaScript : Always the bride's maid, and never the bride

I've been working with JavaScript since 1998, when I first started 'developing' for the web (if you can call hand coding HTML pages developing...).

Back when the DOM was non-standard, and most of what we now call Ajax and Web 2.0 was known by a far less sexy moniker, namely DHTML (huh?)

CIO Magazine looked at JavaScript recently, and it got me to thinking about the little language that clearly WASN'T.

JS is great, JS breaks, JS is hard to debug. And yet when addressing the browser its the best thing we've got. I once had a boss of VERY german origin, getting VERY upset with me because I had the audacity to use VBScript to write some client side code back in 2003.

This despite the fact that all the people using the application had IE, but that is a more philosophical question; the fact is that JS is your best bet to have your code run on the MAX of browsers; however judging by the number of browser-checking code branches in the average JS application, its certainly not a good thing.

I like the basis of JS, namely EcmaScript, and have achieved great things in Flash and other applications which implement this syntax to drive their scripting. It plays nice, makes a lot of sense (once you understand prototyping) and is easy for developers to have a common ground, whether they are C++, C# or Java programmers.

The only people all at see in JS are Visual Basic programmers, and quite frankly... they should know better than to try and get their hands dirty in the land of curly brackets. (HA!) : seriously though, I think VB is an unfairly killed language, and I'll be going into that soon enough. (Try teach someone programming with a Basic language, such as VBScript, and you realise where the appeal once lay with this family of languages : its a BREEZE)

JavaScript's greatest weakness isn't a weakness of the language itself, but rather the complete lack of tools and debuggers for the scripting language. For such an established languaged, how can it possibly be so hard to debug?

There are several offerings online, from Eclipse plug-ins to stand alone IDEs, but more often than not, most developers will admit that their JS development tends to involve a text-editor (maybe DW), a bag of alert()'s and a prayer.

This isn't an acceptable situation, and strides made in VS 2008 go a long way to fix such things; but I can't help but feeling that JS will only really take flight when it is completely divorced from the user. ASP.NET Ajax goes a long way in this direction, allowing me to code my app (client side and all...) in C# and see nice efficient JS be pumped out of my server, and I never have to interact with it. That for me is what an programming language should be.

Maybe JS's day will come. But not yet.

To recode or not to recode

When an application is in daily use, especially a web application, for many years (7+), its in all likelihood:

• Written in a scripting language (ASP, PHP, CF, et al)
• Been worked on by MANY different developers
• Has fallen pray of many server and client side "fixes"

The question then eventually becomes when and/or if you should recode the application or parts of it. Some might jump straight to "recode the whole thing in .net/flex/j2ee/ruby" decision, while others might be a little more circumspect, and decide instead to focus on simply recoding with better practices the pages in the language they were written in the first place.

It's a very difficult decision, and I don't know if I have a strong opinion either way, I have a tendency to look at the code base and decide on a case by case basis, especially if the code appears to be stable and operating normally.

The problem is maintainability in the long term, but I don't know if the potential new bugs included in a recode (or worse: a rewrite) make it worthwhile.

It depends on the system. If you have a bad email post form, recode it for sure. If you have a vast client management platform hit by 100 000 users a day... maybe reconsider bringing out your Dreamweaver and going 'bos' on the code base.

Over the coming months I'm going to be doing a partial piece meal code review and instance recode of a large ASP application, so expect some stories of pitfalls around this.

I'll be kicking this off tomorrow by looking at ASP/VBScript's Date() and Now() functions, and why they are ABSOLUTELY not what they seem, and should NEVER be used for anyone expecting any certainty around the date or the time.