Using JavaScript in WebForms apps? Have I the webinar for you…

Yes, I know, I know: you could probably get away without doing any client-side programming in your ASP.NET WebForms app. Back when I started writing web apps some dozen years ago, that’s exactly what I did. I even remember finding this little snippet of JavaScript that would force the caret into the first text field on the page when it was displayed, and using it all the time and virtually nothing else. Ah, those were the days.

These days, it’s different. JavaScript is all grown up now. Yes, you can still find those blog posts about what you get from adding two empty arrays together (“What’s [] + [] equal?”) and other peculiarities of the language, but real JavaScript devs have moved on, have established a set of best practices, and are creating real client-side experiences with the language everyone loves to poke fun at.

So, next Tuesday at 10:00am Pacific time, I’m presenting a webinar on using JavaScript inside your ASP.NET applications. We’ll be doing some refactoring, writing some new code, creating closures, and other things that will show you that JavaScript is a language force to be reckoned with, even in that ASP.NET app. Register here now.

One of the best practices I’ll be describing almost in passing is the use of strict mode – or should that be, the strict use of strict mode. I’m talking about putting this construct at the top of your functions (or even better, at the top of your JavaScript file):

"use strict";

Since I won’t be talking about it too much in the webinar, here’s what strict mode is all about. Put at its most succinct, it helps you avoid certain mistakes and errors in your JavaScript (see above where I quickly mentioned the peculiarities of the language).

Strict mode changes common mistakes into errors

The biggest example here is creating global variables by mistake. You’re deep in some function and you need to store some value in a new variable. In the heat of the moment, you forget the var keyword.

    var closeWidget = function(index) {
        panel = controlList["dpw" + index];
        panel.Hide();
        if(noWidgetsAreVisible())
            $(".widgets").addClass("hide-panel");
    };

The code seems to work, but in reality you have created a bug. The panel object here is created as a global variable. It is visible elsewhere in the application. If someone else created a global variable called panel – after all web apps are created in teams of more than one person – you’ve just clobbered their version. And so on. Globals are bad, creating one is easy by mistake, but strict mode throws an error at run-time if that code gets executed. (Mind you, a good lint program would find it too.)

Similar to that is properly declaring a local variable (Hurrah!) but misspelling it as you assign to it (Boo!). Result: another global variable is created with the misspelled name.

Other examples of mistakes that are invisible in normal code but that will throw in strict mode are assignments to non-writable variables. Yes, in non-strict mode these types of assignments will seem to work, but won’t actually do anything. Wouldn’t you rather get an exception than total silence on this kind of mistake? Examples are assigning to a non-writable property, a property that only has a getter, a new property on a non-extensible object.

Ditto delete-ing something that cannot be deleted.

Property names on an object must be unique (I didn’t even now that non-strict mode allowed this). Saves you against inadvertent typos.

Parameter names in a function declaration must be unique. Again saves you from your typos.

No octal syntax for number constants. That is number constants can’t start with a ‘0’. Seems too many new devs have never used octal (blimey, I haven’t in twenty years or so) and so were completely bamboozled when something like 0123 was actually interpreted as 83.

Strict mode simplifies uses of variables for optimizations

Using with is disallowed. As it should be. Hated it in Pascal/Delphi, it’s worse in JavaScript. Brrr. Thanks, strict mode!

There are some changes to how eval works. In particular, new variables introduced by the code being evaluated will not appear in the surrounding scope. In normal mode, they are and can overwrite outer scoped variables. Which, you must admit, is a bit of a security problem.

Strict mode makes arguments simpler to use

In essence, strict mode stops you doing stupid stuff with the arguments pseudo-array. I hardly use it anyway, so haven’t run into any of the things strict mode forbids. (Reminds me though of a daft blog post I read recently that so enjoyed doing stupid stuff with arguments.)

Strict mode helps secure JavaScript

The this variable is no longer guaranteed to be an object. Strict mode will, in certain cases, make this be undefined. This has bitten me mildly before: I used to assume that IIFEs when called had this as the global object. This “strict” behavior also avoids unnecessary boxing of primitive types.

It is no longer possible to “walk the stack” since strict mode makes accessing the caller property illegal. Goes along with the changes to arguments to make JavaScript more secure.

Strict mode looks to the future

The list of reserved keywords is larger in strict mode. This means that your identifiers now won’t clash with keywords from later JavaScript versions. Things like implements, interface, let, package, private, protected, public, static, and yield.

Function statements must appear at the top of a script or function. Not something that’s bitten me personally, since I don’t use function statements, but buyer beware.

Summary

All in all then, strict mode introduces a set of logical restrictions to the language designed to help you avoid common mistakes and errors and to prepare you for newer versions of JavaScript. I recommend wholeheartedly using strict mode (as well as a lint static analyzer) in all your JavaScript code. Most of all, you should register for my webinar.

Free DevExpress Products - Get Your Copy Today