While looking for how to tweak my JavaScript code I came acrossa coupleof sites, that might be interesting to look at. To get really into depth I guess I need to try Mozilla’s javascript runtime profiler.
And if you are doing DOJO, be sure to read Performance Tuning very well and don’t stumble blindly into the world of a million widgets without learning how to speed them up!
[Update] If I would read properly I would have seen the big red letters: “While the profiler described here may still work, Venkman is now the preferred way to profile JavaScript.”
Thanks to Josh for finding David Baron’s blog where he provides a way to find memory leaks and their causes in Firefox. There is even an extension for it.
Compared to other browsers the WebKit crew has released a JavaScript debugger quite soon after releasing their browser. And here it is Drosera named after the largest bug eating plant. Nice idea for a debugger name :-). And the screenshot is very promising.
After the element inspector this is the next really useful tool, Safari is becoming more and more useful for development. Even though JavaScript development using browsers is still a pain … but I am looking forward. The technology is just too promising to give up too soon.
Besides Firebug this will be another one of my tools that I stuff into my toolkit box.
I have no experience with Ruby on Rails I just know the screencast and am reading about all the hype. But I think I know PHP quite well, so I wanted to know how much people had learned from RoR and how it has effected the PHP community, especially concerning frameworks and stuff to make your life easier. Here is an article Rails-inspired PHP frameworks from H3rald, which is not going very much into depth. But from what I read symfony seems very promising, especially because it has I18N support integrated and extensive docs, which I think are musts nowadays. I haven’t worked with neither one of them, but I probably will.
Let me just state that I think the integration of AJAX is pretty neat and comfortable, but when it comes to really dedicated JavaScript stuff I would probably not use it. And the Web2.0 stuff nowadays does really dedicated JavaScript. But we will see how this is evolving …
I am writing a heavy JavaScript application and now I can understand the advantages it had doing embedded programming :-).
The simple task I ordered my browser to process via JavaScript, was that it shows this image and then starts doing the real work, which will take long, so indicate that first by showing the image. Nothing easier than that, set style.display = “inline” and go for it. But to my surprise the image was never shown, may be sometimes for a very very short time at the end, when everything was already over. That lead me to investigate what really happens there. And I wrote a little script which basically does those two things in this order:
show the image, that indicates that something will be done and the user shall wait
The result I saw was that the rendering obviously does not happen in real time, as the script would let you assume. It is “put off” to a later point in time and while the heavy-load-task is executed the rendering does not take place. In my case the heavy-load-task was just looping over thousands of calls to document.getElementById, since there was no setTimeout or anything alike used in this loop I expected the browser to be busy for a while, of course. But that the showing of the image was not done until the loop had ended was a surprise to me. Imho it makes clear that the browser either updates his DOM tree very quickly but the rendering engine doesn’t get time to update the screen or that the DOM changes are put in some queue and processed later, which would be very difficult and cause race conditions easily. So I think the first thing happens. For programming reliable JavaScript, especially DHTML this knowledge is extremely valueable but the fact is very obstructive.
That strengthens that a poorly implemented JavaScript can block the browser easily (we all knew that). But now in the times of AJAX JavaScript becomes more and more a thing that is used heavily and the browsers don’t seem to be prepared for this load yet.
No browser is prepared as my tests have shown. This makes me doubt that I am just doing it right and may be I am testing something irrelevant or may be in the wrong way, but I doubt it.
I tried all the relevant browsers I have available on Mac OS X those are the times it takes them to finish the heavy-load-task and to finally show the image (or hide as in the example above).
Firefox 1.5 - about 2 seconds
Safari 2.0.3 (comes with Mac OS X 10.4.6) - at least 10 seconds
Safari nightly build (from http://nightly.webkit.org/builds) - about 0.4 seconds
Opera 8.54 - about 0.7 seconds
The heavy-load-task in the script is looking through the DOM tree and searching for 30.000 elements (you can change this number), which don’t exist. But the DOM tree is actually very small (just have a look at the source) that it is even more surprising that it takes even about 10 seconds in Safari, but fortunately the new version of Safari will be significantly faster!
And by the way, it doesn’t matter if I am looking for the same node every time in the loop or for a different node every time, I tried it (there is no caching of the nodes obviously).
Or did I just do something wrong or misunderstand something?
Sharper minds: please let me learn!
Another one of those standard AJAX components is the edit in place method.
Don’t you agree, that editing data used to be really painful? It was always this looong story: clicking the edit button behind the actual data, showing a form that allows us to edit all the fields, submitting the form, getting back the validation message(s), finding the wrong field, edit again, submitting again … and so on.
The solution
Now that we have suffered enough we have also found an easier and much more intuitive way to do those kind of things. Let the user edit the data in place, just there where they are shown. This does of course have other traps, like: how does the user know what is editable, roll the mouse over every item to check? I think that the data that are editable should be obvious by the context. If the user is on one page of his address book, then it should be obvious (by design and context) that the address book data are editable. Additionally the web designer can also mark the elements that are editable. For example showing a border around them, using another color for those elements (we are used to different colors from hovered links) or by slightly animating the editable text.
To make a long story short, here is the example. Just feel free download and use it.
PS: I couldn’t yet figure out how to embed it here in wordpress, someone might help me so I can make wordpress allow me to copy+paste the code in here and leave it untouched. Not even en iframe with a src attribute would work (src becomes xsrc). I guess I gotta invest a bit more in finding that out :-).
This is the first entry in this category: AJAX (style) guide. Here I will try to sum up some of the main concepts that AJAX provides nowadays, as I see them. Most of the things might be really tiny problems and their solution - very easy for copy and paste. So enjoy.
You remember the pain as a programmer that the form submit always took longer than it actually should and mostly longer than the user expected. Some users even clicked on the submit button again, because it seemed that nothing had happened since the last click, even though the form had been submitted, it just needed some time. But the user didn’t know, because we didn’t use JavaScript efficiently enough.
Nowadays it is already a standard to change the submit button’s text right away to something like “Sending…” and disable it. You can even add a little hour-clock icon or something alike beside it. This way the user sees that the form had been submitted, no matter how long it takes, the user won’t press submit again. Because the button is disabled, he can’t. But most important he gets a visaul response that the form is on it’s way, so now he implicitly knows that he only has to wait.
Here is the example, just try it and click the button:
Compared to other browsers the 
and then starts doing the real work, which will take long, so indicate that first by showing the image. Nothing easier than that, set style.display = “inline” and go for it. But to my surprise the image was never shown, may be sometimes for a very very short time at the end, when everything was already over. That lead me to investigate what really happens there. And I wrote a little script which basically does those two things in this order: