What’s good

On the positive side, there are some reports that Chrome’s market share has already surpassed that of Opera, coming in at close to 2.5% when I last checked. These results should be taken with a grain of salt, as Clicky’s web analytics might only be used by websites that tend to be visited by those more technically-inclined and thus more likely to try out something like Chrome. (Though Chrome’s visibility on Google’s main page no doubt has some small part in its fast growth)

For what it’s worth, Google Analytics on my lowly-trafficked site amounted to over 4% of hits in the past five days. (Google Analytics has since started identifying Chrome as a specific browser type, no surprise)

Chrome browser share on my site

What’s iffy

While the V8 JavaScript engine of Chrome was reported to be fast (myself included) Mozilla has fired back with their own results when compared to the upcoming Firefox 3.1, which also features a newer, faster JavaScript engine dubbed TraceMonkey.

Even if this only manages to bring Firefox 3.1 to within striking distance of Chrome for JavaScript performance, it’ll still easily hand the win over to Firefox 3.1 considering its much larger established base and support for extensions/addons.

Microsoft, meanwhile, still seems to have their heads in the sand when it comes to IE. True, IE7 still have a substantial margin on any other browser but that lead has been steadily sinking. Though IE8 will likely be a vast improvement over IE7 and seeks to erase all memories of the abomination that was IE6, it looks like Microsoft will have its work cut out with the stiff competition from Firefox and Chrome.

Problems

The release was not without controversy, as since this product was from Google, many privacy concerns were voiced. There were concerns about the “GoogleUpdate.exe” process that is installed with Chrome, which apparently allows for higher privileges to install software, which understandably freaked out some users. Generally, unwanted processes running in the background are just the thing the tinfoil-hat wearers are looking for.

Additionally, some keen-eyed users who perused the EULA discovered that Google had apparently tried to claim ownership of all content posted through Chrome. (Who actually reads a EULA?) Evidently, it was all a mishap, as Google quickly moved to correct the errors in the TOS. Apparently, in the rush to release Chrome, a “standard” TOS was used as the basis for the EULA, most likely similar to the ones covering services like Blogger, etc.

My own experiences

Personally, I’m very pleased with the browser. The “application shortcut” feature is very nice as it makes web apps like Gmail integrate very nicely with the desktop. I can’t wait to setup my Mom’s computer with shortcuts to things like Gmail that will undoubtedly make her life easier.

The JavaScript performance is very fast compared to other browsers, but some things like Flash are still buggy at times. This has caused problems with sites like Google Finance (which uses Flash for the charts) and YouTube, which are ironically Google’s own services.

I guess the “Beta” tag and the lack of a full version number excuse these problems, though it looks as if the list of bugs is already quite extensive. Google’s bug tracker for Chrome lists over a thousand bugs/feature requests currently, though likely many of them are duplicates. (Google is, however, following the trend of using the “Beta” moniker in an increasingly loose manner)

After much speculation yesterday, marked by a leaked web comic and finally an acknowledgment by Google, Google Chrome, the much anticipated web browser, is here.

I encourage you to download it and give it a try, as I did as soon as it came out. Here are some of my initial impressions.

Overview

Google released a fairly long web comic that delves into quite a bit of detail about Chrome - it’s not your typical comic! Touted as being built “from scratch”, Chrome uses the WebKit rendering engine, the same one that powers Safari and Konqueror.

The first thing you notice is how minimal the “Chrome” or UI of Chrome is. If you’re used to a half-dozen toolbars, buttons and widgets all over the place, Chrome will seem like a greenfield to you. By default, there is only a tab bar and then an address bar containing back, forward, a combined reload-stop button and the address bar. There are also buttons for bookmarking a site and for page and browser settings. The bookmarks bar is not displayed unless you specifically change that setting.

Keyboard shortcuts are also present so that you don’t have to click through context menus. If you’re used to the keyboard shortcuts of Firefox and IE7 you’ll be pleased to know that most of them transfer over without change: Ctrl-T opens a new Tab, Ctrl-W/Ctrl-F4 closes a tab, Alt-D focuses the address bar and Ctrl-J opens Downloaded Files.

The address bar also functions as a search bar, and this combination just makes sense. It’s something I’ve always been doing using Firefox Quick Searches

By default the home/start page is set to set to show an Opera-style “Speed Dial” page containing most recently-accessed pages/bookmarks. You can also configure Chrome to restore the previous tabs/websites on startup, which is my personal preference ever since I started using Firefox.

Features

Chrome integrates Google Gears to speed up supporting web applications and is an obvious effort by Google to self-promote. This is substantial since the download link for Chrome is on the main Google search page - no small feat considering only the most popular/important services get that sort of attention and furthermore the link is positioned dead center beneath the search field.

The address/search bar

Chrome allows for quasi-Site-Specific Browsers by use of “Application Shortcuts”, which can be set for any website but are meant to be used mainly with web applications. These allow you to open the target URL in a browser window that does not have the menu or address bars and essentially serves as a blank canvas upon which the web application’s own UI can be displayed.

This is similar to other SSBs such as Mozilla Prism or Fluid for the Mac, as they aim to bridge the gap between desktop and web applications to make their integration more seamless.

However, like Google Blogoscoped points out, using such non-browser interfaces may condition the user to be more lax when entering their credentials and makes phishing attempts more viable since no URL is displayed. This is curious since security, “sandboxing” and general safe browsing were so high on Chrome’s feature list - this feature seems to help undo some good user practices of always confirming the URL before entering credentials.

There are also some nice little enhancements as well - the combined address bar/search bar is very much like Firefox 3’s “awesome bar”. Chrome also allows you to dynamically resize any textarea element, without the site designer having to code this specifically in JavaScript or some other client-side technology.

Performance

Each tab/window is a separate process and thus will show up separately in Task Manager; Chrome also offers its own Task Manager but the memory usage reported here differs from that in the Windows Task Manager. To get the full picture, you have to click on the “Stats for nerds” link, which takes you to about:memory

This page displays the full memory usage details, and also, surprisingly, displays memory usage for any other web browsers also currently running! (I have confirmed that it will display Firefox 2/3, IE7 and Opera 9)

Much talk has been made of this feature; indeed while it does use more resources, it also prevents a single site from bringing down the entire browser as only that tab/window will be affected. To test this out, just terminate one of the instances of chrome.exe and you will see that tab’s screen into a “sad tab of death” with an amusing message.

JavaScript

Though JavaScript falls under the category of `Performance` I felt it deserves its own section because of the importance of JavaScript in web applications. Chrome uses the Google-developed V8 JavaScript engine, which has also been released as open source.

The main points of V8 are outlined at the Google Code page for the project, and are quite interesting. One of the main improvements in performance is the use of a Virtual Machine (VM) for processing JavaScript.

The V8 Virtual Machine is different from say, the JVM (Java Virtual Machine) in that it compiles JavaScript source directly to machine code; there is no intermediate byte-code representation used and hence no interpreter is needed for this. This seems to indicate that JavaScript performance might be faster on Chrome since there’s no intermediary. Google provides some benchmarks to confirm this.

From some informal/unscientific preliminary testing, the V8 JavaScript engine in Chrome does appear to be quite fast; loading the same Digg topic in Firefox took longer than it did in Chrome. (Roughly 14 secs vs. 8 seconds over a few trials - and Chrome did not have the benefit of AdBlock Plus) I’d be very interested to see how Chrome stacks up against Firefox 3.1, considering the rumoured performance boosts coming with it.

If Chrome has anything going for it, it’s definitely the lightning fast JavaScript performance. Coupled with the crash-proofing this makes it ideal for use in web applications.

Development

Chrome comes with a nice DOM inspector reminiscent of Firebug. Using it is dead simple; you just right click and select “Inspect Element” and the inspection window will pop up with the element highlighted. Here you can see the full DOM tree as well as the computed CSS styles for the element.

There’s an included JavaScript console for executing code/commands/expressions on-the-fly and while there is a JavaScript debugger included, it seems at this time to be a command-line only tool, far less user-friendly than Firebug.

Not ready for prime time yet?

Of course, Chrome is marked as Beta by Google, something we’ve come to expect since Gmail has been in beta for longer than the company has been publicly traded. Nonetheless, there are still some features that are sorely missed.

The one thing I absolutely love about Firefox is the vibrant developer community and subsequent widespread availability of quality, useful extensions. This has produced such gems as the aforementioned Firebug and Adblock Plus.

For now, extensions/addons are not part of Chrome but may be added in a later version. In the meantime I don’t think I’ll be even close to ready to switch, as I’m very stubborn. I don’t use that many extensions but the few that I do are “must-haves” and I just can’t browse without them.

Lastly, there are always privacy concerns, especially from a company as big an involved as Google. Though you can turn off the sending of usage statistics, there will always be some with their tinfoil hats on.

Conclusions

All things considered, Chrome is a very good entry into the browser market. While I don’t think it’s ready to take on Firefox or IE yet, it does provide competition. So as long as Chrome continues to support standards (which I think it will, since it uses the WebKit renderer and Google has also been forthcoming with their support for web developers), I won’t have a problem with it. I won’t be switching over to it anytime soon, but at the very least it’ll be a useful development tool to verify/test my websites on to make sure they look proper in Safari/Konqueror/Chrome.

The issue was with an Ajax request I was sending. The return value was an array in JSON form. More specifically, the server was returning something like:

{tag:[{id1:'A',id2:'B'}, {id1:'A',id2:'B'}, {id1:'A',id2:'B'}]}

This was perfectly valid and worked fine in both Firefox and Internet Explorer. However, in Opera 9.26, I got a JavaScript error indicating that the JSON was not valid. It was then that I realized I was using an older version of jQuery, v1.2.2. Upgrading to the latest, 1.2.6 fixed the problem. Strangely, I could not find anything on their bug tracker indicating that such a problem (JSON and Opera) had been fixed.

What was even more interesting was that upgrading to Opera 9.50 also solved the problem independently; that is, things worked fine even with the older version of jQuery. This goes to show the importance of keeping your software up to date and highlights the complicated interactions between different browsers and client-side code in a web application.

I’ve been playing around with the Google Maps API for a bit and it’s turned out to be a great way to get started with “mashups” and the like. One of the best uses of the API is the ability to create paths or routes on the map.

This is done by creating GPolyline object and then adding it as an overlay to the map. Basically, a polyline is just an ordered list of geographical points/coordinates on the map, each of which is a GLatLng object. For serialization/storage of polylines, there is an algorithm you can use to Base64-encode a series of points; the resultant string can later be passed directly into a factory method to regenerate the GPolyline. By using encoded polylines, you also get access to a few more interesting and useful options related to rendering and performance issues.

Encoded Polylines

Despite the algorithm for encoding polylines being readily available on the Google Maps API documentation site, there is no built-in functionality within the API for generating the encoded polyline string from an existing GPolyline object. This might be a bit strange, but it’s probably because the encoding process requires some extra values that aren’t available in the typical polyline.

As specified on the algorithm page, you also need to specify a list of encoded “levels” in addition to the points themselves. These levels tell the the Google Maps renderer when certain points can be omitted from the polyline depending on the zoom level. For example, with a polyline with n points, you’ll always want to show the first and last point, no matter what the zoom level. However, intermediate points can potentially be omitted at low zoom levels and only shown when the map has been sufficiently zoomed in to warrant the detail. This sort of optimization cannot be done with the typical GPolyline constructor that just takes an array of points. (GLatLng objects)

Making things easy

If you’ve looked at the polyline encoding algorithm, you’ll probably notice that it’s a bit tricky unless you’ve taken course in CS or done a lot of this stuff before. (At least it was tricky for me) Google has an interactive utility for generating the encoded polyline format for you. The results can then be stored and later fed into a call to the factory method GPolyline.fromEncoded() to regenerate the polyline.

However if you want to generate the encoded polyline format on-the-fly as part of your application, the interactive utility is not really an option. Instead of coding the algorithm from the ground-up, there’s a much better way of doing things, thanks to the PolylineEncoder class and other utilities provided by Mark McClure.

The PolylineEncoder class is written in JavaScript and is very straightforward in its usage. (It has been ported to several other languages as listed on his site, in case you need to use it in different contexts)

Using this class allows you to quickly and easily convert a GPolyline into a compact encoded format useful for serialization or storage. You can also use the class to convert arrays of points into encoded polylines, thus gaining the benefit of optimized rendering at different zoom levels. McClure goes into an in-depth, but easy to understand explanation of the encoding algorithm used complete with animations that show exactly how the polyline approximations work.

I highly recommend the usage of his polyline encoder as it saves you the headache of implementing it yourself. It’s well-written, thoroughly documented and is free for usage. (It isn’t licensed under open-source terms but has instead been placed in the public domain - which is perhaps even more “free”) McClure also has a few other interesing Google Maps projects that you may want to check out.

Some documentation warnings

The Google Maps API documentation is fairly thorough, but it’s out of date in some places, as some people have found. Indeed, in this case, it appears that the GPolyline.fromEncoded() is documented somewhat wrongly in the API reference, though curiously, is used properly in their examples page.

Specifically, you should not use:

GPolyline.fromEncoded(color?,  weight?,  opacity?,  latlngs,  zoomFactor,  levels,  numLevels)

if you want to generate a polyline from the encoded format. Instead, you should use something like:

GPolyline.fromEncoded({
    color: "#FF0000",
    weight: 10,
    points: "yzocFzynhVq}@n}@o}@nzD",
    levels: "BBB",
    zoomFactor: 32,
    numLevels: 4
});

This is because the API has been updated to accept an object of options instead of separate parameters. This, in my opinion, is better for readability and takes advantage of JavaScript’s ability to define inline anonymous object literals.

As a side note, the example actually calls something like new GPolyline.fromEncoded, but I’ve found that you don’t need the new keyword, and in fact, it’s a bit confusing that the example has it and that it would work - after all, you are calling a factory method that returns a type of GPolyline, and not directly instantiating an object. (At least as far as JavaScript uses the new keyword)

Here, I’ll try to address some of these concerns and answer some questions.

Salt of the earth

To understand why salting is used, we must first understand exactly what it is. Just like regular salt, in cryptography, salting is used to alter the “taste” or output of some process.

In the case of password storage, most people would realize that you should never store lists of users’ passwords in plaintext, because if that data is ever compromised, attackers will gain access not only the compromised accounts but could potentially use the passwords to gain access to user accounts on other services/sites. This is because people often reuse the same passwords across multiple account/services.

The easiest way to avoid this is to store the hash of the password. A hash is a one-way function, that is, once you compute the hash of a value, you cannot obtain the original from just the hashed value. Some typical hash functions are MD5 or the more secure family of SHA hash functions.

However, this still doesn’t fully conceal passwords. If an attacker were to obtain the list of hashed passwords, they could try a dictionary-based attack to discover the original inputs. This involves hashing common words to see if they hash to the correct value. Since people often use common words or combinations of such, a dictionary-based attack has the advantage of having far fewer combinations that the attacker needs to try compared to a true brute-force attack.

Adding variability

This problem can be mitigated by salting, which basically amounts to combining the password with additional input before passing it into the hash function. This alters the end output from the hash function so that a dictionary-based attack cannot be used, provided the salt is kept a secret. A comparison example:

Without salting:
hash(A) -> B;

With salting:
hash (A + S) -> C;

In the first example, salting was not used before hashing. Assuming the value ‘A’ is a common word or phrase, an attacker can use a dictionary-attack to determine what the value of ‘A’ was. (I.E. what value hashes to the value of ‘C’)

With salting, things become more difficult. If the attacker does not know the value of the salt (S), they cannot use a dictionary-based attack because the actual input will not be a common word or phrase. Instead, they must try all values in the dictionary with all possible values of the salt. In fact, every bit of the added salt value doubles the number of computations in a dictionary-based attack. The important point to retain here is the salt value must be kept a secret in order to obtain this benefit.

One other benefit of salting is to ensure that two accounts with the same password don’t produce the same hash. This can be accomplished by making different accounts have different salts. The obvious benefit of this is to decrease the information leakage from the hashes, as otherwise, equivalent hashes would infer equivalent passwords.

Salting and the modified Challenge-Response System

With the modified challenge-response system, it isn’t clear to me how salting could be used to improve it. Here’s a quick re-cap of how it works:

Signup:

1. Server sends random1
2. Client sends hex_sha1(hex_hmac_sha1(password, random1))

Login:

1. Server sends random1 and random2
2. Client sends hex_hmac_sha1(password, random1) and hex_sha1(hex_hmac_sha1(password, random2))

To login, the user must present two values: One to verify that they know the password, and the second value, which is used to set the response that must be computed for the next login.

Because the client must compute the next response value, it’s a bit tricky to implement salting in a way that’s beneficial.

One possible method would be to further hash the second value (hex_sha1(hex_hmac_sha1(password, random1))) with a server secret before storing it in the database. This would complicate things should the database be compromised but not the server secret, since a dictionary attack would become much harder with the extra variability of a server secret. In this case, the work flow would look something like this:

Signup

1. Server sends random1
2. Client sends hex_sha1(hex_hmac_sha1(password, random1)) [Let's call this value `hashed_challenge_response` for brevity]
3. Server stores hex_hmac_sha1(server_secret, hashed_challenge_response)

Login:

1. Server sends random1 and random2
2. Client sends hex_hmac_sha1(password, random1) and hex_sha1(hex_hmac_sha1(password, random2))
3. Server computes hex_sha1(hex_hmac_sha1(password, random1)) [Call this `hashed_challenge_response_received`]
4. Server checks if hex_hmac_sha1(server_secret, hashed_challenge_response_received) equals the value previously stored. If so, authentication was successful and a new challenge-response is stored based on the second value received.

Note that this method would not improve the login security anymore, since an attacker who captured the intermediate traffic of a successful login could still conduct an offline dictionary attack, which this challenge-response system is unfortunately susceptible to.

However, the modified system does benefit from the use of the `random1` and `random2` challenge strings, which are stored alongside the response values. Since these are random and different for each user (and for each subsequent login), accounts with the same password will not have the same hash-response. This effectively gives the second lesser benefit of salting.

The modified challenge-response system also suffers from the inability of the server to enforce strong passwords. Because the initial value sent during registration is a hashed value of the password and a random value, the server cannot be aware of any properties of the password such as its length or composition. The only aspect that could be enforced server-side would be to make sure the password was not blank! My suggestion is to (attempt to) enforce password complexity using JavaScript on the client side. Such rules can obviously be circumvented but are better than nothing.

Conclusion

Hopefully I’ve shed some light on the topic of salting in relation to the modified challenge-response Ajax PHP login system. I’m no security expert, so you should not take my advise as scripture. Please don’t hesitate to give me your comments or feedback!

Download the source

Please feel free to download and try out the first public release of the CHAP-PHP login system. The zip file has the full source and provides an example how to implement the system both on the client and server side.

The same demo available in the zip file is also available here.

Improving authentication security with Challenge-Response

Challenge-Response is the basis for many authentication systems. In such a situation, a server may have to authenticate a user by verifying their credentials, usually in the form of a password. However, transmitting plaintext passwords over connections that are not secure can lead to compromises. In such a situation, challenge-response may be used. This usually involves the server sending a random challenge string to the client, which must then produce an appropriate response that can only be computed using the challenge and the password. This response is then sent to the server, which can then verify if the right password was used to generate it. The response is usually computed by hashing a value that depends on the challenge and the password, thus it is not possible to obtain the password from the response, which might have been sniffed on an insecure connection.

However, such a traditional challenge-response has the downside that the plaintext password (or a password-equivalent) must be known to the server at some point. Paul Johnston came up with an idea for an alternative system a while ago that overcomes these shortcomings. (Though it is not free from weaknesses itself) It is this “Alternative System” that the above release is based upon. Here is a quick explanation of the system, adapted from Johnston’s site:

Signup:

1. Server sends random1
2. Client sends hex_sha1(hex_hmac_sha1(password, random1))

Login:

1. Server sends random1 and random2
2. Client sends hex_hmac_sha1(password, random1) and hex_sha1(hex_hmac_sha1(password, random2))

During registration, the value sent by the client is stored. During login, the user must present a value that when hashed produces the value provided at registration. Because of the non-reversibility property of hashes, knowing the value passed during registration does not allow an attacker to login. The only way to produce the valid response is to know the actual plaintext password, which is never transmitted or known by the server. In this system, challenges are linked to a user and must be stored, since it must be known what challenge was used to produce the response.

The second random challenge (random2) and the second value sent by the client during login are used to prevent replay attacks. Upon successful login, the second value provided by the client becomes the next response, equivalent to the value first provided during registration. Thus, for the next login, the value that is sent must hash to equal this value. This also means that the challenges are updated/changed each time a login is successful. This has the unfortunate downside of revealing when a user has logged in, since the challenge presented at login will be different. (Challenges must be publicly available)

For a more thorough explanation, I suggest that you read Johnston’s article on the subject.

Getting it to work

Understanding the process above leads to the conclusion that user-login is now a two-stage process. Since the challenges are tied to a user, the username must first be known to the server in order to retrieve the challenge for that user. The client can then use the challenge to produce the response to send to the server for authentication.

Having a two-stage login form would be very unfriendly to users. Thus, the main challenge is to make it appear as if nothing out of the ordinary is happening. This is where Ajax comes into play. When the form is submitted, the event is prevented from occurring normally. Instead, the username is first retrieved from the form and sent to the server via an Ajax call in order to retrieve the associated challenge. Once the challenge is received, the appropriate responses are computed, inserted into the form and then the form is submitted.

The current system also works in the case that JavaScript is not enabled/available on the client side. In this case, challenge-response will not be available, since JavaScript is used to compute the responses. The server-side PHP scripts infer that JavaScript was not enabled on the client-side if proper challenge-responses are not received, and thus treat the password as plaintext. In this case, passwords are transmitted in plaintext. With this code, you have the choice of allowing this “insecure” login to proceed or not.

Note that the CHAP-PHP is more of a module than a full-fledged system, since it’s not intended to be used on its own but instead as part of some application. It might be a bit confusing if you’re a non-developer, but I’ve tried to make it as straightforward and simple as possible so that it will be easy to integrate with existing code bases/frameworks/sites.

Please don’t hesitate to contact me with your questions, comments or suggestions.

Disclaimer and warning

You should not use this as the basis for authentication for sensitive data/websites. I am not a security expert. At this point, this is more of a proof-of-concept then something concrete. It is intended to be the starting point for perhaps something more secure and to show that there are alternatives for more secure authentication when SSL is not available.

Revision History

• 0.5 - First Public Release - 2008-03-29
• 0.5.1 - Fixed file-based storage to be more robust - 2008-03-30

* Sensationalist headline inspired by previous posts

Eclipse is my IDE of choice, as you’l probably have noticed from some of my previous articles. I had been wanting to write an article about why I use it (and why I switched to it), but kept putting it off. Recently, Matt Mullenweg wrote about his problems with Dreamweaver, and this perhaps prompted me to organize my notes on why I’ve chosen to use Eclipse. Don’t get me wrong - I’m not advocating that you immediately switch and throw out your current editing tool (the headline above, as noted, is purely for sensationalism) - but rather I’m just urging you to consider Eclipse for your next project.

Changing Gears

Like many, before switching to Eclipse I had been using a pure text editor, Ultraedit, for most of my web-development activities. Ultraedit seemed fine for most things, offering basic features like code highlight and autocompletion. However, it lacked a certain finesse when it came to dealing with larger projects. For example, if you’d defined a class, its members wouldn’t be available for autocompletion. Something else was needed. I finally decided to take the plunge, and switch over to Eclipse for all my development towards the end of the summer last year.

Some might wonder why I was even using a text-editor in the first place for development. For those coming from a traditional programming/development background, the idea of not using an IDE (Integrated Development Environment) is silly. This is because a lot of programming languages are compiled, and in this case, it just makes sense to use an IDE since it’s easier to write code, compile and debug using one tool instead of multiple ones.

However, for scripting languages, especially those meant to run on a web server, one can “get away” with not using an IDE quite easily. This is because the scripts are not run standalone but are almost always executed in the context of a web server; thus you’re usually editing code that you then run on a development web server, without the need for a special tool like a compiler. Additionally, it’s easy to view the output using any web browser. These reasons are what allowed me to persist in using a text-editor for so long.

No turning back

However, once I started using Eclipse, I was hooked. I downloaded Eclipse PDT (PHP Development Tools), which is basically a version of Eclipse bundled with the tools/plugins necessary for setting up a PHP development environment. Besides offering everything Ultraedit did, it also offered nice features like easy ‘Todo’ lists, (just type ‘todo’ anywhere in a comment and it’s automatically indexed by Eclipse into a list), code completion for built-in PHP functions and your own as well as a multitude of other advanced features that IDEs have. Oh, and it’s also FOSS. (Free and Open Source Software)

However, perhaps the best part about Eclipse is its robust and well-supported plugin system. This allows Eclipse to pretty much assume any feature that someone is willing to write a plugin for. This is what really sold me on Eclipse, because this almost makes its abilities endless. Some of the plugins I use are Subclipse for SVN integration, Mylyn for Trac integration and JSEclipse for JavaScript editing. This is part of the reason why Eclipse is the basis for many other IDEs out there.

Some other nice features are the ability to link the IDE in with the Zend Debugger, thus allowing for proper debugging sessions with PHP.

Spoiled

However, I’ve been pampered somewhat and have found a few things to complain about, at least when it comes to Eclipse PDT. I use Eclipse JDT (Java) a work and its advanced refactoring abilities are a feature I find myself wanting in the PDT version. Have you ever found yourself wanting to rename a variable to something more descriptive but putting it off because you’re afraid you’ll mess something up by forgetting to change the name somewhere?

With some IDEs, you’re left having to just do a search-and-replace in order to accomplish what should be a trivial name refactor. Even if your editor supports regex searches, things can still be tricky - what if you’ve used the same name, but in a different context, and thus shouldn’t change the variable there? The point is, the process still has to be human-supervised and is tedious. With Eclipse JDT’s advanced refactoring, you can rename the variable once - and the IDE is smart enough to know where else to change it to keep the code consistent - very neat, and I was amazed when I first used it. Other refactoring abilities include extracting methods out of blocks of code in order to clean up lengthy methods. All of this makes your life 10 times easier and allows you focus on real programming rather than annoying tasks.

However, Eclipse PDT doesn’t support this for PHP code, yet. I hear that it may be supported in a later release, so I have my fingers crossed. Perhaps accomplishing these refactoring tasks is easier in Java because of its compiled nature or because the JDT project has received more attention. It’s definitely possible in PHP, as some IDEs, such as the Zend Studio (which is based on Eclipse) support this ability. Zend Studio, however, is a commercial solution and I haven’t tried it out yet.

Nothing’s perfect

Eclipse does have its downsides as compared to a traditional text editor. First of all, it’s a memory hog - though most IDEs are. I have regularly seen Eclipse eat up 300-400 MB of RAM if I’ve been using it for a long time. However, it should be noted that I have not had it crash once, so it’s been rock-solid as far as stability goes. Nonetheless, I recommend you to have at least 2 GB of memory if you really want to use it properly, since you’re likely to have other programs open. This is especially important if you’re running Windows Vista. RAM is quiet cheap nowadays, and you can easily pick up 2 GB for $50 or less and upgrading is a painless process, so there’s no reason not to.

Finishing up

Eclipse has changed my life. Okay, so perhaps I’m exaggerating a bit. But, I can say that development, at least for me, would be much harder without Eclipse. If you’re still using a text editor for development, I urge you to give Eclipse a try - just for 30 days, and see how you like it. I don’t guarantee results as good as mine, but you may be pleasantly surprised.

This is why inheritance in JavaScript is probably one of the least understood concepts. While languages like Java have well-defined constructs for inheritance, the topic is of less importance with JavaScript. In many situations, you’ll never have to deal with these aspects when programming in JavaScript, simply because it isn’t required for a lot of client side scripts. However, for larger-scale web applications, applying object-oriented principles to your code may make it easier to design, improve and maintain.

There have been many articles written about inheritance in JavaScript and how it can and should be done. You really don’t need to read mine to gain an understanding. Rather, I’m just going to write about what I’ve learned, the process I went through and the experience I’ve gained along the way.

It’s all new(s) to me

If you come from a Java background, you’ll be no stranger to the new keyword. Using it allows you to instantiate a new instance of an object from its class by calling its constructor. The keyword also makes a lot of sense, since you’re creating a ‘new’ object.

JavaScript also has a new keyword, but it doesn’t do quite the same thing as its Java counterpart, though at first the effects might seem similar. This is one of the main reasons why JavaScript inheritance tends to be poorly understood.

Consider the following example.

function Foo(name)
{
  this.name = name;
}

var fooObject = new Foo('I am foo');

If you’re familiar with Java or JavaScript, this example is fairly straightforward. In the prototype-based JavaScript, functions can serve as object constructors in somewhat the same manner as a constructor in Java. However, Foo in the above example is not a class, since classes do not exist in JavaScript. So, if Foo is not a class, what exactly happens when the statement var fooObject = new Foo('I am foo') is executed?

Taking a step back

Before we dive into the details, I’ll explain the concepts of a prototype-based language as it applies to JavaScript. I mentioned above that JavaScript does not use classes like Java does. This basically means that new objects are not created from instantiation of classes, but rather inherit from existing objects. Thus, there is no “class hierarchy” but rather just an object hierarchy.

In JavaScript, all objects are descended from the built-in Object type. This is similar to how all Java classes implicitly have the Object class as a superclass. In JavaScript, instead of extending classes, you can inherit by manipulating the prototype property on a type; that is, the prototype property on the function you are using to create an object. Let’s see some code to straighten things out.

function Foo(name)
{
  this.name = name;
}
Foo.prototype.getName = function()
{
  alert(this.name);
}

var fooObject = new Foo('I am foo');
fooObject.getName(); // Will alert with 'I am foo'

This example is identical to the first one, except for the lines that are emphasized. Here, I’ve set the getName property on the prototype property of Foo equal to a reference to a Function object. This is effectively the same as defining a method for a class, since any object created from that type can call the method getName() on itself to return the proper value. But what exactly is happening, and what’s the deal with the prototype property?

More new(s)

In JavaScript, the new keyword actually accomplishes a few things. When you execute an expression such as var fooObject = new Foo('I am foo'), here’s exactly what happens.

1. First, a new generic object is created. This object is the same as if you created the object using the statement new Object(), using JavaScript’s built in Object type.
2. The constructor function, that is, the function Foo(), is then called with the this keyword set to reference the newly-created object. The parameters supplied are also passed to the constructor function, in this case, the string “I am foo”. If you’re familiar with context, this is equivalent to:

   var fooObject = new Object();
   Foo.call(fooObject, 'I am foo');

   Thus, the code in Foo() sets a property called name equal to the supplied string. Up to this point, things are the same as if you had created a new object and then manually set the name property yourself. The next step is where things change.

3. The last step is where inheritance takes effect. The constructor function, in addition to executing the specified code above, also sets an internal property called __proto__ equal to the value of Foo.prototype. This is how the new object inherits from the old one.

   When you call a property on fooObject now, JavaScript will first check to see if the object has a local value for it. In this case, the only local property is name. (Besides the internal and implicitly set __proto__ property. However, if it does not exist locally, it will check to see if the property exists under the object referenced by the __proto__ property. In this case, the getName() method exists under here.

Where things get confusing is because of how the new keyword is used. Perhaps the designers of JavaScript wanted to use a keyword familiar to Java programmers so as to ease the transition to a new language that sounded so similar. While it accomplishes a similar goal and for the most part you can consider the action to be almost the same, the use of the new keyword conceals the true meaning of prototype-based inheritance in JavaScript. This ends up causing more confusion when you start digging into code.

We’re all the same

Suppose you created multiple objects from the Foo() constructor, called fooObject1, fooObject2 and fooObject3, In one fell swoop, you could add a new method to all of these objects without having to recreate them. This is because of the prototype property. Because each object contains a reference to Foo.prototype, adding a new method here will allow all objects access to it. For example:

Foo.prototype.yellName = function()
{
  alert(this.name.toUpperCase());
}
var fooObject3 = new Foo('I am Foo 3!');
fooObject3.yellName(); // alerts 'I AM FOO 3!'

This adds another method to all Foo-constructed objects allowing them to “yell” their names.

Extending Types

I mentioned inheritance above but with just one type definition, the principles weren’t too clear. Suppose we decided to extend our Foo “class” - how exactly would this work? First, you need to define the child type and then set its prototype value to a new object of the parent type. An example:

function FooChild(childName)
{
  Foo.call(this, 'I am a child of Foo and my name is ' + childName);
}
FooChild.prototype = new Foo('');

var fooChildObject = new FooChild('Barbar');
fooChildObject.getName(); // Will alert with 'I am a child of Foo and my name is Barbar'

Let’s break down what’s going on here.

1. First, we define a new constructor called FooChild. In it, we call the parent constructor function with the context set to the current object. This allows the name property to be set on the object during creation since that’s what the parent does.
2. Then, we set the prototype property equal to a new object that’s an instance of Foo. This is what allows all of the child objects to have access to the parent’s properties, such as the getName() method.

A few more details

JavaScript provides two special operators for dealing with types and objects. One is called instanceof and the other is typeof. The latter, typeof, is less useful since it only deals with built-in JavaScript types.

The typeof operator returns the current variable’s type, but is limited to predefined types. For example, typeof fooChildObject or typeof fooObject both return a string with the contents of “object”. Thus, differentiating between the two is impossible. More information can be found at the Mozilla Developer Center.

The instanceof operator is more interesting. It takes two arguments and tests whether the first is an instance of the second. (I guess I didn’t need to explain that) For example:

function Foo(name)
{
  this.name = name;
}
Foo.prototype.getName = function()
{
  alert(this.name);
}

function FooChild(childName)
{
  Foo.call(this, 'I am a child of Foo and my name is ' + childName);
}
FooChild.prototype = new Foo('');

var fooObject = new Foo('I am foo');
var fooChildObject = new FooChild('Barbar');

alert(fooChildObject instanceof Foo); // true
alert(fooObject instanceof Foo); // true
alert(fooChildObject instanceof FooChild); // true
alert(fooObject instanceof FooChild); // false;

In the above code, it is clear that fooChildObject is an instance of FooChild, and fooObjectis an instance of Foo. However, fooChildObject is also an instance of Foo, since its type was inherited from it through the prototype property. However, fooObject is not an instance of FooChild since that type is a child of Foo.

I hope I haven’t said “foo” one too many times for you.

More information about instanceof is again available from the excellent Mozilla Developer Center.

Concluding remarks

I hope this has helped you to understand the nature of JavaScript’s built-in inheritance features. I know I found it very convoluted at first, coming from a class-inheritance background. I read everything I could find on the subject, and I believe it’s made me a better JavaScript programmer by understanding some of the “inner workings” of the language. I encourage you to check out some of the references I’ve provided below.

References

1. Prototypal Inheritance in JavaScript - Douglas Crockford
2. The Philosophy of JavaScript - Jesse of 20bits
3. Prototype Inheritance Revisited - Mozilla Developer Center
4. The Employee Example - Mozilla Developer Center

You may have run into this particular aspect of JavaScript when working with event handlers. For example:

function alertId()
{
  alert (this.id);
}

document.getElementById('someId').onclick = alertId;

This will return the “id” attribute of the element that the function has been attached to. You could attach the same function to multiple objects and each time you called it on a different object, it would return a different value, since the context is different. (Minor note: using element.attachEvent(), as part of the Microsoft event handler model, does not change the context of the function so “this” will still refer to the window object)

However, there may be times when you want to change the meaning of this without actually having to attach that a function to an object. Using the call() and apply() methods of the Function object can allow you to do this.

Context is everything

Let’s backtrack for a moment. In JavaScript, many (but not all) variables are objects. This includes the references to all functions as well - they are also objects. In the example above, using “alertId” (without the parentheses) would refer to the Function object that represents alertId. As the Function object is a predefined object in JavaScript, it has methods and properties associated with it.

Two of these methods are call() and apply(). Using these methods on a Function object allows you to set the context of that function - that is, what the “this” keyword refers to. The two only in how arguments are passed to the function whose context is being redefined. For example apply() takes an array of arguments like this:

function someFunction(arg1, arg2)
{
  this.id = arg1 + arg2;
}

var arrayOfArguments = ['valueOfArg1', 'valueOfArg2'];

someFunction.apply(objectToBeUsedAsThis, arrayOfArguments);

The values in the second-argument array are then used as the arguments to the someFunction() function.

The call() method is almost the same except it does not take an array of arguments, but rather just an indeterminate number of arguments that are all passed to the function. For example, the above could also be accomplished with this code:

function someFunction(arg1, arg2)
{
  this.id = arg1 + arg2;
}

someFunction.call(objectToBeUsedAsThis, 'valueOfArg1', 'valueOfArg2');

I prefer to use apply() sometimes since you can directly use the arguments variable that is local within all functions. (The variable arguments stores all the arguments that were passed to the function when it was called, and so this can be used in a situation with where it is desired to have a function with a variable number of arguments.)

A useful example

So far, the examples posed have been fairly trivial. Let’s look at a real-world use of call() to illustrate its usefulness. Remember the arguments variable? Basically, you have access to this object variable whenever you’re inside a function since it stores all the arguments passed to this function. However, it’s not exactly an array (although it works like one sometimes) and thus it does not have access to Array methods such as join().

We could easily convert it into an array by accessing each property by its index using a loop, but there’s an easier to way to do this. Consider the following code:

function someFunction()
{
  var argsArray = Array.prototype.slice.call(arguments, 0);
}

Using this one line, we have successfully converted the arguments into a true Array object and stored the result in the argsArray variable. How? First, we access the slice() method on the Array object through the prototype property and then call() the method telling it to use the arguments object as this.

The slice() method allows us to extract a section of an existing array. However, by using call() we are able to apply its effects on the arguments object that is similar to, but not exactly an Array object. The second argument of ‘0′ merely indicates that we want to extract not just a part of arguments but all of it. Since slice() always returns an Array object, we thus get back a true array containing the same data as the arguments object. And that’s it!

Note that the above example could be compacted even further. However, it looks very cryptic and can be confusing. (As if the previous example wasn’t confusing enough!)

function someFunction()
{
  var argsArray = [].slice.call(arguments);
}

This example works the same as the previous one. Instead of using Array.prototype, we create a ‘dummy’ empty array to get access to the slice() method. The second argument of ‘0′ isn’t needed, as if it is left out when using slice() the entire contents will be returned.

Contextual Conclusion

In short, using these methods to change the scope of a function can allow you to do some neat things with JavaScript that aren’t possible in some other languages. However, one should always be mindful to keep code readable and maintainable and to lessen the learning curve for those new to a language.

Some of this may have transferred over to JavaScript, a language that is already poorly understood and often implemented even worse. It is often hard to find well-written, maintainable JavaScript code, as it is often left as an afterthought in a project or otherwise not given much consideration, having been delegated to the realm of popup scripts and mouse-overs. While exception handling may be overkill for a lot of JavaScript applications, many do not even know of JavaScript’s exception-handling capabilities. In this article, I’ll give a brief overview of exception handling and some recommendations on how to use it in JavaScript to improve the readability of code.

Exceptional conditions

I won’t go too in-depth about the merits of using exception handling but will instead just give a brief overview. (While there are some drawbacks, these apply more to the Java language rather than JavaScript)

The main reason for using exceptions is to have a separate channel for communicating errors. Without this, you must communicate error conditions using the function itself. Consider a function that performs mathematical division:

function divide(dividend, divisor)
{
  var quotient = dividend/divisor;
  return quotient;
}

Division is a fairly simple arithmetic operation, but of the four basic operations it is the only one that has limits on its arguments: the divisor (the term you divide by) cannot be zero, since division by zero is undefined. So, how should you handle cases where the supplied arguments result in division by zero? (The situation is very likely in an application accepting user input)

Without using exceptions, you have a few options, each of which has its own weaknesses. Firstly, you could choose not to return anything and just alert() the user of the error. This isn’t good since when you call the divide() function, you expect a result, not a warning message.

Secondly, you could choose to return a special “error code” indicating that there was a division by zero. But this creates another problem - what exactly do you return when something goes wrong? In this case, the only error case is division by zero - since JavaScript is a weakly-typed language, you could just return false on this error, but then in the calling code you’d have to check if divide() equaled false before using it, probably using the strict equality operator. As you can see, things get messy fast.

Alternatively, you could just check the inputs/arguments every time before you called the function. However this is clumsy, and adds another layer of complexity where something could go wrong.

Another way of doing things

As mentioned before, exception handling adds a side channel of sorts strictly for communicating errors. By doing this, it allows for the interruption of program flow for the purpose of dealing with the exception or error situation. Using exceptions, you would re-write the function above like this:

function divide(dividend, divisor)
{
  if (0 == divisor) {
    throw new Error("Bzlorg! Cannot divide by zero.");
  }

  var quotient = dividend/divisor;
  return quotient;
}

Here we are checking if the divisor equals zero - signifying an invalid input value - and then throwing an exception if this is the case. How is this different than returning an error code?

The main difference is in the control flow of the program; using exceptions causes a change in the program flow. In the above example, if the divisor equals zero, the execution of the function stops there and returns to the calling code with the throw exception. The subsequent statements calculating the quotient and returning will not be executed. Here’s an example of how you’d call the divide function.

try {
  var dividend = 3;
  var divisor = 0;

  var quotient = divide(dividend, divisor);

  alert("The answer is " + quotient);
}
catch (e) {
  alert(e.message);
}

With exceptions, you enclose code that could throw an exception with a try block. This signifies to the interpreter (in the case of JavaScript) that you will be executing code (in this case, calling a function) that could throw an exception as a result of some error condition. Thus you are trying to do something - but as in real life, things may go wrong.

In this example, everything works until the line calling divide. Since divide throws an exception with the input values supplied, flow will be directed to the catch block. All try blocks must be followed with a catch block, with the variable in the parentheses specifying the variable to hold the thrown exception object. In the code above, we merely alert the user to the problem - the message “Bzlorg! Cannot divide by zero” is displayed - in a real program you most likely would want to do handle the error differently depending on the context - but that’s a whole different topic.

If, however, you executed the code with valid values and no exceptions were thrown, once the program had got to the end of the try block it would jump over the following catch block and the user would be alerted with the correct answer. Code within a catch block is only executed in the event that an exception is thrown.

Differences with Java

Since Java is an extremely popular language and one that also uses a similar exception handling model, it would be prudent to discuss some of the differences and similarities with it and JavaScript.

1. No multiple catch blocks with JavaScript

   This is perhaps the biggest difference. If you’re familiar with Java you’ll know that different exception objects can be thrown during execution (all subclasses of the root/parent Exception class defined by Java), each signifying different error conditions. You catch each of them separately by using separate catch blocks, each specifying a particular class or parent class. However, with JavaScript, as you might have noticed from the code above, there can only be one catch block and thus there’s no need to specify the exception class.

   If, however, you want the granularity of working with different exception classes, you’ll have to use the instanceof operator within a catch block, like this:

   try {
     ...
   }
   catch (e) {
     if (e instanceof RangeError) {
       ...
     }
     else if (e instanceof TypeError) {
       ...
      }
   }

   It’s not as elegant as having multiple catch blocks, but it’s one way to deal with multiple exception types.

   Correction:

   It appears I was mistaken. In JavaScript, you can indeed have multiple catch blocks, as seen in the Core JavaScript 1.5 Guide from the Mozilla Developer Center. My initial example above is still valid syntactically, but this way may be more appealing. An example is as follows:

   try {
     ...
   }
   catch (e if e instanceof RangeError) {
     ...
   }
   catch (e if e instanceof TypeError) {
     ...
   }
   catch (e) {
     // General catch-all block.
     ...
   }

   It just goes to show that when you think you know something, you probably don’t! This is part of why I like JavaScript (and by extension, programming); there’s always more to learn and experience to be gained.

2. Exception types

   The discussion of exception types brings us to another point - the different exception types in JavaScript. JavaScript defines some built-in exception types, all based off the parent Error object. These should suffice for most situations where you’re checking user input (the most common use), but if you’re developing a complex application you may want to define your own.

   In that situation, things get a little tricky, especially if you’re coming from Java. Despite the outward similarity, JavaScript does not uses classes like Java, but instead uses a prototype-based approach where inheritance comes from existing objects. In this respect, things can get complicated as there are debates on what the best way to inherit from objects is and to that degree, a few JavaScript libraries have been written to facilitate the extending of objects in JavaScript. These points are beyond the scope of this article, but I thought I’d just point you in the right direction.

   Interestingly, you can also throw many different types of expressions, and are not limited to the built-in exception types. For example, throw false; and throw "Hello World"; are valid statements, but in my opinion, it doesn’t make much sense to throw any type of expression just because you can. Using the built-in exception types (or defining your own) is a better practice, though throwing just String expressions might be alright in some situations.

3. Runtime errors

   During execution, you code may trigger runtime errors within JavaScript - for example, when trying to reference a property on a non-existent object. These will also result in a new Error object being thrown, even though you did not define this throw in your code. If this happens within a try block, the exception will subsequently be caught in the following catch block, and if you’re not expecting this error you may miss it. (If, for example, you’re only looking for specific exception object types)

   This can create problems with some of the JavaScript debuggers out there like Firebug. Since the runtime exception is being caught, Firebug will not be able to catch it (it is prevented from “filtering” up), so you may not be able to locate the source of your error if you’re relying on the debugger.

   My recommendation is thus to ensure your code runs properly under normal conditions. Only then should you start using exceptions and try-catch statements. This will ensure that no unexpected runtime exceptions get caught. (The runtime errors are analogous to the unchecked runtime exceptions of Java in that they are not normally caught)

Summing it up

The whole point of using exceptions is not to make your code “work” better - anything that can be accomplished with exceptions can most likely be done without it, with just the same end result. The point is to make your code more readable, manageable and flexible. By using exceptions you get rid of having to use cumbersome “error codes”, the values of which you may forget later. You also get more flexibility with how you handle errors. You need not handle the error right in the function where it occurs - you can throw an exception to the calling code and handle the error there - or, alternatively, you could let the exception bubble up to a higher-level and handle all errors there. It really depends on your needs, but using exceptions allows for this to be implemented more readily.

Though exceptions may seem like overkill for JavaScript and despite the limitations of its exception handling model as compared to that of Java’s, there are still some benefits to using exceptions, especially for complex JavaScript applications that you may implement to improve the interactivity of your site.

Changes/Fixes

• 2007-12-06: Changed throw new Exception(...) to correct statement of throw new Error(...).
• 2008-01-08: Fixed incorrect assertion of “No Multiple Catch Blocks” in JavaScript; added remarks about being able to throw any type of expression.