22 May 2009 9:45a Pacific

Javastrict

by Matt Sherman

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.

Comments

22 May 2009 4:03p Pacific #

Ian Patrick Hughes
"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.

Ian Patrick Hughes United States |

Comments are closed

Tell others

TwitterTweet this page
Digg!Digg this page
TwitterAdd to Google Reader

Experimental! Let me know how it works for you.

Shorten this page's URL

Learn more about the TinyASP URL shortener

ASP.Net jQuery Controls

Implement jQuery effects using familiar ASP.Net server controls. Learn more...

Recent posts

Alikewise learnings #1: DIY PR

Sherman’s law of prior knowledge, or, predicting the past

The busiest people at Apple right now…

When “infographics” jump the shark

HTTPS is the least of your problems

Stacking up

Beware the truth-tellers

Please don’t write “efficient” CSS

more...  

About us

ClipperHouse.com is brought to you by Matt Sherman and Fernando Chilvarguer, among others. Contact us here.