Your Ad Here
20th
 March

JavaScript error reporting: DamnIT

Creating compatible and portable Javascript scripts can be extremely hard. We, as developers, can test our scripts in as many browsers as we want, but, there always seems to be problems.

Now, when an error occurs, what usually happens? The browser shows a little yellow symbol in the bottom-left corner of the screen (in IE at least - I might as well use it as a good example: it is the most popular browser). The visitor will usually just ignore the error for two reasons:

  1. They don't know what the error means most of the time, unless they are Javascripters themselves; and
  2. They don't really care about your site and the errors - why should they?

Because they ignore them, and you have no idea they exist, bugs in your applications may go unnoticed for weeks, or even months. And, all the time your application is not functioning as expected, visitors are seeing your service as unprofessional and will simply go to your competitors.

But, thankfully, there is a way to catch and fix these errors. A new service called DamnIT will send you emails whenever there is a problem on the client-side. Here's an example message:

DamnIt

One thing that the service could be used for is client-side error detection and reporting during BETA tests.

Here are some great benefits of the service:

  • It allows the user to enter some details about the error, and what they did before the error;
  • It can be incorporated in to JavaScriptMVC easily; and
  • Error messages are very informative - they contain browser details, user's description and the error's line number

There is also another great benefit of DamnIT. That is its error management section. This section lists the most recent errors, and the most common - so you can prioritize. It will even categorize by browser:

DamnIT - My Errors

To use DamnIT is simple - you don't have to touch any of your existing script. All you have to do is put this code on to your page:

<script type='text/javascript'
src='https://damnit.jupiterit.com/damnit.js?_KEY_'></script>

And it is as simple as that - after obtaining your key, you will automatically receive error details by email within a few seconds.

DamnIT Demo

16th
 February

Tips for Faster JavaScript Scripts

So, after a reasonably successful "Tips for Faster PHP Scripts" series, I've thought about what else I could write about. As I've been using JavaScript quite a lot recently, I decided to write about ways to improve scripts so they run faster.

It is important than JavaScript scripts are fast, because you can not determine the execution speed on the wide range of clients' browsers.

You can not also determine how fast peoples' internet connections are, so it is important that the scripts get to the clients' browsers as fast as possible.

Some of these tips may not be entirely practical and may make the scripts harder to maintain, but I believe there should be compromise between making maintainable code and speed- and resource- efficient code.

1. Combining Scripts to One File

When Javascript files are requested, the server sends a few headers. Sometimes these headers can take more bytes than actual JavaScript itself.

For example, if 5 single JavaScript files are requested, they each will be received like this (with headers shown):

HTTP/1.1 200 OK
Date: Sat, 16 Feb 2008 18:55:10 GMT
Server: Apache/2.2.4 (Win32) mod_ssl/2.2.3 OpenSSL/0.9.8d PHP/5.2.1
Last-Modified: Sat, 16 Feb 2008 18:55:08 GMT
ETag: "6d37-86-fd04022"
Accept-Ranges: bytes
Content-Length: 134
Connection: close
Content-Type: application/x-javascript

function aFunctionName(arg1, arg2) {
if(arg1 == arg2)
return 0;
if(arg1 < arg2)
return -1;
if(arg1 > arg2)
return 2;
}

The total size of this transmission, including headers, is 424 bytes. The code itself is just 125 bytes. If similar code was loaded 5 times, the total size of the transmissions will be 2120 bytes. If, though, all the code was put into one file, the size of transmission would be 933 bytes, a saving of about 56%.
Read more »