John Resig (jQuery guy) talks about advances in the next rev of Javascript (properly known as ECMAScript 5). It now has a “strict” mode, which makes Javascript look a lot more like a compiled language.

When I first moved from classic ASP — interpreted VBScript — to C# in .Net, I must admit I was a bit annoyed. Why do I need to declare every variable? What’s this “build” stuff? I was used to just throwing text files on the server and if they were broken, I would hear about it.

Then I came to understand why we have compilers and strict languages: prevention of silent-but-deadly errors. Like mistyping a variable name. Or not paying attention to scope, where the “i = 0” in your subroutine overwrites the “i” that was defined one level up.

The difference comes in when you learn about the defect. In a strict language, you’ll hear about it immediately, before it gets out the door. In a less-strict language, you might hear about it after your user has lost a week of work. A priori, or a posteriori?

The fact that JS is not strict (it rarely throws errors) and also dynamic (you can mutate objects at runtime) means that the burden for accuracy is entirely on the developer. S/he needs to be as smart and exacting as a compiler. And user testing is the only way to catch logical errors.

Now, with strict mode, you can tell JS not to be so forgiving. Undeclared variables are caught — which helps to catch typos and forces you to manage scope. And asking-for-trouble functions like Eval() are no longer allowed.

What John doesn’t mention is that strict mode will probably lead to greater performance. If the browser is told “I declare this code to be good and right”, it can spend less time handling ambiguities, and get on to the business at hand.

2 thoughts on “Javastrict

  1. "What John doesn’t mention is that strict mode will probably lead to greater performance."

    The biggest obstacle to delivering desktop like applications over the wire right now is the nature of plain text delivery that is compiled by the browser at runtime. Yeah, caching helps the situation a little since you’re not requesting "War and Peace" (unabridged JavaScript version) each and every time, but it is still parsed and compiled.

    V8 is the best engine at parsing JavaScript right now, but I mean, its task is a heavy one. Offering more structured code would be the better alternative and a "strict" scenario might help a lot in that regard.

    …I hope.

  2. Virtually all of whatever you say is astonishingly appropriate and that makes me wonder the reason why I had not looked at this in this light previously. This article really did turn the light on for me as far as this specific topic goes. But there is one particular issue I am not really too comfy with and whilst I try to reconcile that with the actual central idea of your issue, permit me see just what all the rest of the subscribers have to say.Well done.

Leave a Reply

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

You are commenting using your 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