A colleague of mine came up with this interesting finding he found on click events in JavaScript. Initially, I was in denial thinking what I saw is not what its supposed to be and I was trying to blame it on jQuery, browsers etc. But turns out, it is nobody’s fault and the way it worked is “by design” & the expected behavior of click events in JavaScript.

So, Let’s say there is a text field and a button. We have an event handler for text field’s ‘blur’ event and there is a ‘click’ event handler to the button. On blur event of the textfield, we remove the textfield from the DOM tree, which internally adjusts the page layout moving the location of the button on the screen. So, what happens to the event handlers for the text field & button?

I have created a jsFiddle for this exercise and following are the steps to run this test case. Thanks to my colleague for short & simple code for this jsFiddle :).

1.) Place the cursor focus on the textfield
2.) Without tabbing out or clicking anywhere on the screen, just click on the button
3.) Observe the console output on the textarea.

If you are surprised as I was, you would see the console output from ‘blur’ event but, not from the ‘click’ event. The reason is, mouse ‘click’ event is triggered only after the successful completion of ‘mousedown’ & ‘mouseup’ events sequence on the exact same component.
So here in this example, when we click on the button, ‘mousedown’ is triggered which internally triggers ‘blur’ event on the textfield. And right after that, button’s location is changed from the screen(because of the textfield being removed) and ‘mouseup’ could not be triggered as the mouse pointer’s location is not within the bounds of the button.

My original argument was, as long as we have a click event handler attached to the button, it should be fired irrespective of where the button resides on the page. But, that is simply not true as we had just proved.

After digging into this little further, I was able to find out where this expected behavior is actually mentioned. To my surprise, I was able to find the fine print both in jQuery’s click event & W3C’s mouse event API doc.

jQuery’s click event API doc – http://api.jquery.com/click/

The click event is only triggered after this exact series of events:

The mouse button is depressed while the pointer is inside the element.
The mouse button is released while the pointer is inside the element.

W3C’s mouse event doc – http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-MouseEvent

The click event occurs when the pointing device button is clicked over an element. A click is defined as a mousedown and mouseup over the same screen location. The sequence of these events is:

As you may or may not aware that capturing screenshot from Java (stand alone, applet or webstart) was made easier with the help of java.awt.Robot. But due to the fact that multiple monitors have become a common place, its a challenge to figure out the bounds, width & height of the monitor you are currently on for capturing the screenshot. In this specific case, I would want to capture the screenshot of the current active monitor ie. where my mouse is pointing at that instance. After playing around with screen geometries, I finally came up with this code snippet and thought it might be useful for someone else. I have tested this code from standalone & applet in Java version 1.6.0_26 on Windows 7. Hopefully, it should work fine in other platforms as well.

To admit the truth, I’ve been holding not to write on Dart for a while. After consuming lots of stuff online on this topic I couldn’t resist but to throw out my thoughts. So, what in the world is this new programming language called “Dart”? Why do we need another programming language with new syntax & semantics? What does dart do, others don’t?
OK, I’ll try to address these questions with my view points & analysis. Keep in mind, as Google put it, Dart’s language specification is still on its “early release” so, don’t be surprised if there is any significant change to Dart from now. There are lots of reviews(good & bad) on Dart available online. But, I’ll try to focus on only the points relevant to questions stated earlier.

Dart as described by its technical overview page – “It is a class-based programming language for creating structured web applications.”. There are two keywords to note here, class-based and structured web applications. You may know this already, Javascript is prototype-based, which is fundamentally different from class based languages like Java, Python, Ruby etc. What that means is, its very different in the way object orientedness/object hierarchies handled by the language. Whether you love or hate Javascript, you always get puzzled with its prototypic language nature and that adds so much to its peculiarity. Sometimes its a good thing and often times its not. So, a developer coming from a strong objected oriented programming language (like Java, Ruby, Python) background would always have a hard time working their way out using Javascript the way you normally do in class-based languages. The point is, Dart is trying to address that problem. You may ask now, why Dart? Isn’t GWT supposed to do all that already for you by masquerading JavaScript in the cover of Java? Yes, thats a very valid question. But, there is a difference. Trust me, I will try to address that in a short while.

Why do we need another language?

This is gonna be the hardest thing to sell. It almost feels like Google is so confident on their “moving the web forward” initiative and they kind of ready to loose some of their good old friends. This might sound political, but here is the truth. If you think of a website with some life on it (dynamism), it is most likely provided by JavaScript. Obviously, there are other things like Flash, Applets, Silverlight etc. But, they are much lesser in the grand scheme of “web” in general.
JavaScript has been a close friend to browsers all through its life. And suddenly, some new guy called “Dart” walking in and trying to share its life with some body else. It is really gonna be very tricky. Think of all the companies, tools, libraries, frameworks, resources, browsers who have already invested so much on JavaScript. It would either take them long time to welcome Dart or may be “not anytime” at all. So, only time can tell the truth.

What does Dart do & others dont?

This is probably a good selling point for Google. If you look at programming language or code developed for web application, they are either client side or server side. Even the code written for client side execution in PHP, Ruby, Python, Java etc. need to be translated to HTML/JavaScript/CSS to run in browsers. So, there is really not a very seamless way to write some common code and run both in client(Browser) and server side(Web Server). Yes, JavaScript can be made to run both in web server & browser. But, that is not a seamless process. Same thing would applies to Java also (like server side Java & Applets). Thats where, the concept of Dart VM kicks in. If you think of Dart VM existing in web servers (Apache, Nginx etc.) and in browsers (Chrome, Firefox etc.). The code you write can be deployed both client & server side. One of the major reason, I personally feel Google is pushing Dart forward is, they indirectly own majority of Web not just through Chrome browsers in Desktop but, also because of Chrome being in Android (Phone, Tablet, TV etc.). Obviously, Dart can very well be expanded to build native apps in Android OS and stuff.

If you compare Dart with GWT. I would say GWT can be considered as kind of a short-term goal for structured web application approach. Whereas, Dart can be called more of having a brand new programming language & approach itself for long term goal.

Will it win? Not sure :). Its gonna be very hard to speculate. Only thing I would say is, it will be yet another “expensive experiment” by Google in the world of sophisticated technology and innovation.

Update 11/11/11: Here is a posting from GWT blog on where GWT & Dart stand.