I was looking through the code in facebox.js(a jQuery plugin) and I saw this:
'\
    <div id="facebox" style="display:none;"> \
      <div class="popup"> \
        <table> \
          <tbody> \
            <tr> \
              <td class="tl"/><td class="b"/><td class="tr"/> \
            </tr> \
            <tr> \
              <td class="b"/> \
              <td class="body"> \
                <div class="content"> \
                </div> \
                <div class="footer"> \
                  <a href="#" class="close"> \
                    <img src="/facebox/closelabel.gif" title="close" class="close_image" /> \
                  </a> \
                </div> \
              </td> \
              <td class="b"/> \
            </tr> \
            <tr> \
              <td class="bl"/><td class="b"/><td class="br"/> \
            </tr> \
          </tbody> \
        </table> \
      </div> \
    </div>'

Wow, I am ashamed I didn't know you could do multi-line strings like this earlier!! Although not as nice as multi-line strings in Ruby/Python/Perl, this definitely beats quotes and plus signs.

I wanted to try putting a javascript console inside an AIR app to aid development. I tried firebug lite, which I've been using a lot to debug IE. When I started up the app and hit F12, the console came up and everything, '1+2' gave 3, so time to rejoice? Not so fast, if you try to type 'window', or 'document', you get this error:
Error: Adobe AIR runtime security violation for JavaScript code in the application security sandbox (eval)

So they sandboxed eval and restricted access the dom and any other api that's available. And it's for... security reasons. What does Adobe have against eval? This sucks!

Man! Have I been at war with IE lately. I have been holding back a lot of blog posts related to debug IE problems, and I going to start spewing them out now one by one. For the first installment I'll talk about one I encountered these couple of days...

Ever get this IE error?
When you click "Ok", this is what you see:

Ouch! Can this be any more catastrophic?(Yeah, that's my Chandler impression.)

According to this forum post, this happens if you have script tags in your document that's modifying other parts of the dom before the document finishes loading. Umm, okay, but I still had a hard time finding out the exact point this caused the problem. I used the comment-out-code-and-see-if-it-still-breaks-binary-search methodology, and came up with some work arounds which involved delaying the execution of some setup code. But, this catastrophic error came back to haunt be time and time again. Clearly I didn't find the root cause of this error or I wouldn't be committing it repeatedly.

But finally, I found it(I think, well at least one of the root causes). I am using firebug lite in development, which creates iframes and panels in the pages that pops out and in just like firebug. When you call console.log with firebug lite, guess what happens? Yeah, it modifies the console output window - a part of the dom that is outside of where the script tag is. Got rid of those console.log statements and fixed it.

In conclusion, do not do what I did!

IE, are you kidding me?

I realized when I was trying to explain the prototype chain to my wife the other day that I didn't get it completely. So I went back to the drawing board and this is the example that I came up with:

function inherit(parent){
    var obj = function(){};
    obj.prototype = parent;
    return new obj();
}

toby = {};
toby.name = 'Toby';
toby.age = 27;
toby.eyeColor = 'brown';
toby.hairColor = 'dark';

console.log(toby);
// Object name=Toby age=27 eyeColor=brown hairColor=dark
emma = inherit(toby);
emma.name = 'Emma';
emma.age = 1

console.log(emma);
// Object name=Emma age=1 eyeColor=brown hairColor=dark

console.log("Toby is Emma's parent: " + (emma.__proto__ == toby));
// true

This is a great article on the Y-Combinator. It talks in laymans terms. I understand now what it does and why it is useful. However, I still have no clue how the code for the Y-Combinator works.

At work I am required to write a web UI that has a rich-desktop kind of interface. Without getting into too much details, it's layout will look a bit like an older email application(e.g. outlook, the older versions). It also need to have drag-n-drop capabilities. I whipped up a prototype of the UI using prototype and scriptaculous, since that's what I've been getting fluent with. A couple of things about my prototype made me decide to give Flex a try.

1. No draggable divider. The draggable divider - although not essential - is something that seasoned computer users have learned to expect when you give them interfaces that have multiple panels jammed onto one screen. Scriptaculous didn't have an draggable divider widget. YUI and ExtJS did, and I am not against learing a new library. But I get the vibe that their implementations might not be rock solid.
   
2. Buggy drag-n-drop libary. Scriptaculous comes with a drag-n-drop library. I've used it in multiple occations. It's also been buggy for me on multiple occations. A lot of the bugs are attributed to differences in browsers.

I decided that I was tired of chasing down cross browser bugs, which will only grow exponentially the more complex my UI gets. Therefore, Flex could really be the answer to these problems.

I am probably 60% done with my port of the UI prototype from Javascript/prototype/scriptaculous to Flex. I am happy with it for the most part. Here are my first impressions of Flex. First the pros:

1. Programming in Flex is suprisingly similar to programming in HTML/javascript/CSS. (Well, not as suprising as it could have been since I've heard Charles Lowe say the same on DrunkAndRetired.com podcast). You write a mxml file, which is like your markup - in place of your HTML; you write ActionScript inplace of Javascript; and there's a css 3 compliant stylesheet you can use to style the UI.
2. Flex has a rich UI component model that similar to many of the desktop UI toolkits(Swing, GTK, MFC, etc), which is a departure from the HTML/Javascript model. This is a plus because you get a lot of widgets you can use out of the box with very little code. Using third party Javascript widgets is usually more involved.
3. ActionScript is not much different from Javascript, so people literate in Javascript should pick it up easily. The only significant difference I've noticed so far is the type declaration syntax - ActionScript is statically typed. I believe ActionScript is compatible with a newer version of Ecmascript which has optional type declaration for variables and parameters. Type declaration in ActionScript(as far I can tell) is required on function parameters and global variables(errors out if you leave it), and optional on local variables(warns you if you leave it).
   
4. Yes, you have to write XML, but it's not that bad. I have expressed my hatred for making programmers read and write XML by hand in the past. It's inhumane! Flex makes you do that. Yes. But! It's used in a way that's not as bad as some other ways in which XML have been used(build scripts, web configuration, for example). In Flex, XML is used for Markup (wow! a markup language used for markup? what a concept?). The XML declaratively defines the UI(such as in HTML), which, I my opinion, is the way UI's ought to be written, and not in a procedure way(such as in Swing).
   
5. Flex components look good by default. For HTML/CSS you always have to design your own theme - even if you just want it to look half way decent. No such BS in Flex. Flex components look good out of the box(no CSS tweaks or includes required), because of this I believe you can prototype Flex UIs faster.
6. A Flex app runs exactly the same on any browser it supports. This was the main sell for me. Nothing more needs to be said.

Now the cons:

1. Develop feedback - not as instant. Developer feedback loop is slower because of the compile step. ActionScript is a compiled language, and you need to compile your Flex programing to get a SWF file. Also, in Flex 3, they took away the eval() function(why oh why???). This means you cannot create an interactive shell in Flex like Firebug or the python shell.
2. Mandatory Static typing. Although I have nothing against static typing in general. I don't like mandatory static typing(such as exists in Java, C#, C++). Haskell is a staticly typed language, it verifies all your types for you, and yet it doesn't require you to specify the types of all you variables and parameters because it can infer them all for you. I like that. This is not a big issue for me, it's just not as kosher as Javascript in this respect.
3. It's annoying that you have to write mx: to begin all Flex component tags in the mxml spec. No such BS in HTML. I tried a hack to do without it, it didn't work so well.
   Update: Looks like I have gotten rid of the mx: problem. I guess I showed them ;)
   

Overall, the pros are worth more than the cons. Linguistically, I prefer Javascript to ActionScript and HTML to MXML, so it's not going to Change My Life(TM). But the UI component model and cross browser compatibility greatly outweigh those nags.

If you register the change event for a radio button, they fire at different times between IE and FF. FF fires the event immediately when you click on the radio button to change its value. IE does not, it fires changed only when you blur the element.

If you write an input element like this:
<input type="text" id="name" name="name" value="></input>
In IE, if you try to traverse the dom, you will get the end-tag as a separate element /input. Ex. with prototype: $('name').next() should get you /input.

If you use a button element as a submit button in a form, like:
<button id="mybutton">My Button</button>
$('mybutton').value in FF will get you an empty string whereas in IE you would get "My Button"

Since Chrome is so great, I wanted to use it for all my browser needs. But the apps I've been working on myself have not been targeted for WebKit - the rendering engine used by chrome, and also used my Safari. This is mostly due to laziness on my part - having to handle two browsers at a time is chaos enough. But Safari compatibility is on my todo list for more than one of my projects, and chrome is a good push for this cause. And so I went in today and made just todo list. compatible with Chrome and Safari. The differences I encountered were:

1. This is really prototype specific - prototype adds an empty underscore parameter for all Ajax request for WebKit browsers. Because apparently, Safari errors out when you try to post with an empty body on XHR calls. And, who knows, this might already be fixed in WebKit. I happened to have code that was not handling this fact on the server side. This was no biggy.
2. This is an error on my part really, but I had a form with a text input inside. But also registered for the key events on the text input so that when enter is pressed I called form.submit(). The key event code is really unnecessary because an enter on the text input triggers the form submit on both FF and IE. So, although on the other 2 browsers this was no problem, in WebKit this triggers 2 posts. So... just DON'T do this.
   

Google just released this awesome browser. They have a great comic strip walking you through what the big deal is about, which is a must read for web developers. I've been using the browser for half a day and it's been pretty rock solid for all the sites I normally use. Javascript is clearly MUCH faster thanks to the v8 engine, which I think Steve Yegge alluded to a while ago. I like many of it's different features, and think it's a great boost to the browser world as well as javascript, i.e. the NBL(Next Big Language).