JavaScript


04
May

How to match any character (including newlines) in a JavaScript regular expression

There is a little gotcha with JavaScript regular expressions. The . (dot) character, which supposedly matches any character, does not match newlines.

Now this is actually standard (if somewhat counter-intuitive) behaviour in regular expressions in most languages, but it can be changed, for example, by setting the RegexOptions.Singleline option in .NET, the /s modifier in Perl, or the PCRE_DOTALL option in PHP.

Unfortunately, there doesn’t seem to be a corresponding option in JavaScript.

However, there is a workaround. The \s character class matches any white space character (including carriage returns and line feeds), whereas the \S character class matches any non-whitespace character, i.e., anything not included in \s. So… if you want to match any character in JavaScript, including newlines, using [\s\S] instead of the dot should do the trick.

For example, to extract the contents of the <body> section of an HTML document:

/<body[^>]*?>([\s\S]*)<\\/body>/.exec(html)
Comment on this »
Posted at 12:19 in JavaScript
16
Feb

Pro JavaScript Techniques

Since I started taking JavaScript seriously just over a year ago, I’ve found myself a bit disappointed with most of the online resources for it that are knocking around. The main ones seem to concentrate solely on the basics, and tend to be aimed at beginners — people who are happy to write code in a purely procedural manner and just want the basic information needed to get the job done, even if it does mean writing gratuitous amounts of copy and paste code.

Personally, I’ve felt a bit disappointed by this. I’ve said before that I think of JavaScript as the new Scheme — so with that in mind, anything that treats it as if it were merely client-side PHP will naturally be something of a disappointment. Perhaps this is a case of quidquid latine dictum sit, altum viditur on my part, but I like to use closures, lambdas, iterators, generics, Linq and so on in my code to maximum effect. I am also firmly of the opinion that every professional developer needs to be familiar with these concepts too — after all, they show that you have the kind of mind that can handle the complexities of software development, and won’t stumble over the FizzBuzz problem.

pro-jsSo when I came across Pro JavaScript Techniques by John Resig on Thursday, I thought it sounded like a breath of fresh air. Resig is something of a JavaScript guru: he is the lead developer of jQuery, and really knows his stuff, so I expected it to hit the mark in this respect. I promptly ordered it through Amazon.co.uk, and it arrived pleasingly promptly yesterday lunchtime.

The book certainly does not disappoint. Following a short introductory chapter, it gets right down to business with a chapter on the more advanced features of the language such as closures, currying, scoping rules, and how to make full use of JavaScript’s somewhat unorthodox, prototype-based approach to object oriented programming. This is followed by advice on how to write reusable code, unit tests for your scripts, and how to enforce good code conventions with tools such as JSLint. The rest of the book focuses on the practicalities of real world JavaScript as it works in the browser, with chapters on the DOM, events, CSS and forms, and Ajax, and ties it altogether with several practical examples including an image gallery, an Ajax search box, an Ajax wiki, and a Google Reader style "never ending" WordPress theme. He treats the subject in a fair amount of depth, about as thoroughly as you can in 350 pages, covering gotchas and issues with common browsers along the way, and points to resources on the web where you can find out further information.

This isn’t a book for complete JavaScript novices — it assumes a certain amount of familiarity with the language, and is written more from a perspective of adopting professional best practices and producing high quality code rather than from simply getting you up and running quickly, so at least some experience of JavaScript is necessary. However, it is not a difficult read, and a competent developer with at least some basic JavaScript experience should find it fairly accessible.

The only downside to it is that as it is now two years old, there are already one or two omissions that date it somewhat: it does not cover Internet Explorer 7 or Safari for Windows, for instance, and it still recommends testing your code against Internet Explorer 5.5, which has since pretty much fallen off the radar. However, all the content is still applicable today, and no doubt will remain so for quite some time to come. Personally, I would recommend it to any professional web developer who wants to improve their JavaScript skills. (And if you are a professional web developer, you jolly well should be improving your JavaScript skills.)

Comments (1) »
Posted at 22:06 in JavaScript
11
Dec

Volta, GWT and leaky abstractions

There’s been quite a bit of hype recently about Volta, the latest and greatest offering from Microsoft. It’s a bit like the Google Web Toolkit or RJS in Ruby on Rails, in that it allows you to write everything in C# and have it translated into JavaScript. You don’t even have to use C#—you could just as easily use VB, since it works on the compiled MSIL, converting that into JavaScript. It allows you to split your application at the lower tiers as well, automatically generating web services so that you can put, say, the user authentication part of your application on a different server to the main site.

It sounds like a good idea in theory, and no doubt it will attract quite a bit of attention from developers who do not want to have to learn yet another programming language. The main attraction of this kind of framework is for developers who are frightened off JavaScript by all the cross-browser insanities and the useless, bizarre and often totally misleading messages that Internet Explorer throws up when it encounters a JavaScript error. The old “Syntax error in line 0″ syndrome. There is also the issue of testing on multiple browsers on multiple operating systems. But hey, now we can write JavaScript without writing JavaScript!

But is it really necessary?

About a year ago, I would have given an emphatic “yes” in answer to that question. However, a lot has happened in the JavaScript world in the past year and a half. We now have free virtualisation software and Intel Macs, so you can run several different operating systems—Windows XP, Windows Vista, Windows Server 2003, Linux and Mac OS X—on the same machine if you are that way inclined, making cross browser testing a whole lot easier. Firebug turns Firefox from a humble browser into a powerful debugging tool. JavaScript frameworks such as Prototype, Scriptaculous, jQuery and Dojo abstract away all the nasty cross-browser stuff, allowing you to discover just how nice a language JavaScript really is. And on top of that, they give you transitions, drag and drop, thickboxes, fade anything techniques, and a whole lot of other eye candy and cool stuff as a bonus.

I’m also rather sceptical of the whole write-language-A-in-language-B business.

Admittedly, I’ve never actually tried the Google Web Toolkit or RJS, but my guess is that while there’s undoubtedly a lot that you can do with them, I doubt if they’re the most efficient. Writing JavaScript in C# or Java or Ruby will inevitably involve a layer of abstraction, and all abstractions are, to a greater or lesser extent, leaky.

Now before you shout me down on this one, yes, I know that Prototype and jQuery are abstraction layers, and therefore may well have plenty leaks of their own. However, the point that I am making is that the process of converting between languages adds a whole further abstraction layer in addition. Making the whole thing even leakier.

At present, Volta has a lot of leaks. Late binding is not supported, for instance, which means that languages such as IronPython, IronRuby or PHP (via Phalanger) are effectively ruled out, and Visual Basic requires you to use Option Strict. This seems a bit surreal given that JavaScript itself is also a dynamically typed language, but it is a consequence of the fact that it all goes through the statically typed MSIL intermediary, and support for reflection (which is needed to simulate dynamic typing on a statically typed platform) is severely limited.

I am also sceptical of the benefit of being able to move parts of your application between the client and the server. Far from making things simpler, this could introduce a whole new can of worms if it is not carefully thought out, partly in terms of performance, particularly if you end up with a very chatty interface between them, but much more seriously, in terms of security. Maintaining state across multiple tiers is also very difficult if not impossible to abstract completely transparently, and it will be interesting to see how they tackle this problem.

However, it is probably a little unfair to knock it too much at this stage. Volta is only a technology preview and pretty experimental, so obviously some of these leaks will be patched as it matures. On the other hand, undoubtedly other leaks will remain and may even prove impossible to patch—in particular, performance will never be the same as with pure vanilla JavaScript, and download sizes will still be greater. So by all means check it out if you like, but as far as I’m concerned, if a task calls for JavaScript, JavaScript is what I intend to use.

Comments (4) »
Posted at 23:00 in JavaScript
22
May

The functional beauty of JavaScript

I’m the kind of developer who tends to sit on the “coding” side rather than the “design” side of the fence. I’m at my happiest when I’m designing web services, database access and application architecture, and although I do enjoy the odd creative spurt with Photoshop and the like, I don’t find it as interesting as the former. Consequently, until a couple of years or so ago, I only gave JavaScript and client-side development the bare minimum of attention that I needed to do my job. What with all the lunatic inconsistencies that you needed to handle in order to cope with Netscape 4 and Internet Explorer 4, I always perceived it as a monstrosity that needed a lot of ugly hacks to get it to do anything more compelling than bring up a dialog box saying “Hello world”, and was content to merely download whatever scripts I could find off the Internet to make it do whatever I needed it to do.

These days, of course, the story is quite different: you have some nifty tools such as Firebug, and despite the myriad rendering bugs in Internet Explorer, standards such as CSS and XHTML make browsers are a lot more compatible with each other than they used to be, plus of course there is all the cool stuff that you can do with Ajax. All this makes learning JavaScript a much more attractive prospect, and not surprisingly I’ve had to do a lot more of it in the past couple of years than ever before.

It’s been a real eye-opener. Far from being the ugly, kludge-ridden monstrosity that I’d always thought of it as being, JavaScript is actually a beautiful, well designed language with some very nice constructs. I always thought of it as one of those linear, procedural languages much like VBScript or Fortran with some vaguely object-oriented bits and pieces thrown in as an afterthought like PHP 4, but in actual fact it has much more in common with functional languages such as Scheme, OCaml or Haskell. It has closures and first-class functions, for example, which means that you can express some things in very clever, succinct and beautiful ways.

One particular JavaScript framework that has gotten my attention in the past few months is jQuery, and it’s become my library of choice for DHTML and Ajax gee-whiz. It’s an increasingly popular and fully featured toolkit that enables you to do some pretty clever stuff with only a handful of lines of code. For a simple example of what you can do with it, here is a code snippet that will highlight rows in a table when you mouse over it:

var highlightColour = "#ffff00";
var normalColour = "#ffffff";

$(document).ready(function() {
  $("#my-table tr").hover(
    function() {
      $(this).css("background-color", highlightColour);
    },
    function() {
      $(this).css("background-color", normalColour);
    }
  );
});

I love the simplicity of this. As the WordPress guys say, code is poetry.

(Update: Jeff Attwood has an interesting take on the subject where he describes JavaScript as “the lingua franca of the web” with the likes of Flash and Silverlight as merely pretenders to the throne.)

Comment on this »
Posted at 23:43 in JavaScript
20
Dec

Firebug - the best Firefox extension ever?

I came across Firebug this morning via Matt Mullenweg’s blog. It is without a doubt one Firefox extension that no web developer should do without.

It’s an awesome plugin. You can debug and profile your Javascript code, step through it line by line, set breakpoints, inspect objects and variables, and quickly find errors when they happen, with detailed and useful information. It has a command line that lets you execute Javascript on the fly. You can edit your HTML and CSS on the fly and have the changes show up immediately, explore the DOM, and monitor the network activity involved in each page request, showing you the HTTP request and response headers for each file that it fetches.

All in all, it has just about everything you need to develop client-side JavaScript effectively and easily. And best of all: like Firefox itself, it’s free and open source.

Just one thing I don’t understand though. Once it is installed, it is disabled by default and you have to enable it, either globally or on a site-by-site basis, before you can use it. I presume that there’s some rationale to this — possibly something to do with either security, performance or stability — but I’m not sure what it is. Can anyone enlighten me?

Comments (2) »
Posted at 21:40 in JavaScript
20
Apr

Eolas v Microsoft and FlashObject (continued)

Microsoft caused a furore earlier this month when they rolled out the update to Internet Explorer on the eleventh of April to implement some changes to the browser behaviour in the light of their legal defeat by Eolas. Not only was this earlier than anticipated (their court imposed deadline is the middle of June) but they also bundled it in with the latest round of security updates. Anyone who has updated Windows, either automatically or manually through Windows Update, will be affected.

The update does not result in any loss of functionality. ActiveX controls such as Flash animations, embedded Windows Media players and Java applets will still play as normal, but they will ignore all user interaction until you click on them to “activate” them.

If your Flash animation or embedded media player is merely cosmetic, you may not need to take any further action. However, if it has some interactive functionality such as navigation, less knowledgeable users may get confused and think that your site is broken. Rollovers will not work until the animation is activated, for instance.

As I mentioned in my previous blog entry, I have been using FlashObject to work round this issue. It is fairly easy to implement this with only a few lines of code. You can wrap your <object> tags in an HTML container tag such as <div>, <span> or <p>, and add just a couple of lines of extra code to load in the object:

<script language="javascript" src="/path/to/flashobject.js"></script>
<div id="myFlashContainer">
  <object width="400" height="200" clsid=blah blah blah blah blah...>
    <!-- and so on... -->
  </object>
</div>
<script language="javascript" type="text/javascript">
  var fo = new FlashObject("/path/to/flash/animation.swf",
        "myFlashObject", "400", "200", "7", "#ffffff");
  fo.write("myFlashContainer");
</script>

The script works by swapping out the Flash animation within the container, which does not automatically get activated, for a new, dynamically loaded, <object>, which, does, due to a loophole in the Eolas patent. The parameters are: the path to the Flash object; a unique ID which is assigned to the created <object> tag; the width; the height; the version of Flash which is required to view the animation; and the background colour.

Geoff Stearns gives fuller instructions and details about FlashObject on his website.

Open source browsers such as Firefox are not affected at this stage. Eolas founder Mike Doyle has stated that he intends to license the technology free of charge to open source projects, but what exactly comes out in the wash in that department remains to be seen.

Comments (1) »
Posted at 11:48 in JavaScript
04
Apr

Using Flash? Check out FlashObject…

If you are using Flash animations in your website, you should check out Geoff Stearns’s FlashObject. It neatly works around the problems that will arise in the Internet Explorer updates that have been introduced in the light of the Eolas/Microsoft patent dispute.

It also has several other advantages over the standard way of embedding Flash using <object> and <embed> tags in your web pages:

  1. It is standards compliant, so your HTML/XHTML pages will validate. (<embed> isn’t.)
  2. It downgrades gracefully, as the Javascript swaps out some existing content in your web page.
  3. It is syntactically clearer and easier to read than the conventional way of putting an <embed> tag within an <object> tag in your pages, and hunting around for those long, arcane and easy to mis-type GUIDs.

I must say I take my hat off to Dr Michael Doyle of Eolas. Taking on Microsoft and winning is no mean feat, especially when you consider that in legal disputes such as this it’s usually a case of simply spending the other side to death. However, it still illustrates the whole lunacy of the American software patent system. As one Slashdot commenter said, “Are we for Microsoft because we hate software patents, or are we for Eolas because we hate Microsoft?”

Comment on this »
Posted at 14:30 in JavaScript