Posts by jwmcpeak

I first noticed this a few years ago when visiting some forums. A person asked why their code using jQuery didn’t work. It was a simple scope issue, but it was indicative of what was to come: people picking up and using a library without any knowledge of JavaScript.

While jQuery certainly opened the doors for web designers to add behavior to their web designs, it also ushered in an era of programmers who have little to no clue of how to really use JavaScript. I understand why people want to jump into a library without learning about the browsers or JavaScript – client-development isn’t developer friendly. On one hand you have a language that is so simple, yet so complex, that is completely different than any conventional programming language, and you can spend hours figuring out why a few lines of code doesn’t work. On the other hand, you have IE and standards-based browsers that seem to have discrepancies everywhere you turn. Having middle-ware to iron out some of the wrinkles (primarily the browser discrepancies) is alluring.

It wouldn’t bother me except that the primary attitude I see is “Don’t attempt to learn anything because it’s not worth it and jQuery does it for you.” Thankfully I’m beginning to see a reversal of that ideology, and more and more people are wanting to get their hands dirty without a library.

Like you, I think that someone would become a better programmer by learning the language and browsers and writing their own work first.

As for my favorite library, my own. It has everything I need without changing the way I program or providing functionality that I don’t need (ie: it’s smaller and quicker to load). I haven’t spent alot of time looking at mainstream libraries. I’ve looked at jQuery, MooTools, and Prototype. If I had to use one of the three, I’d pick MooTools. It’s impact on how I code is minimal, and some of its methods are similar to jQuery’s.

I don’t know about applications (Jeffrey could answer that better than me), but anything .NET related. So components or controls for any .NET app (WinForms, WebForms/MVC, WPF , WCF, etc).

Getting values from css properties won’t work when they are defined internal or external though works for inline elements.

var op = document.getElementById(“test”).style.opacity;

works fine but when opacity is defined in style tags or external css file it does not work.

I wouldn’t call that wrong. All properties of the HTMLElement interface map directly to attributes belonging to that element (http://www.w3.org/TR/2003/REC-DOM-Level-2-HTML-20030109/html.html#ID-58190037). So it would be wrong for style to do anything other than getting the CSS specified within the style attribute.

The DOM allows you to get the style of any element within the document. In standards-based browsers, you use the getComputedStyle() method. In IE, you use the runtimeStyle or currentStyle objects.

Microsoft won’t do anything drastic. Their philosophy is backward-compatibility above all else. So dropping IE is out of the question. Besides that, the Trident engine used to be a core component of Windows since IE4 . If Microsoft continued down that path and if it’s heavily used in Windows Vista and 7, Microsoft isn’t going to drop IE or change rendering engines. They need to separate Windows and Web, but I’d be surprised if they did that.

We can expect IE9 to have a standard’s mode. Whether or not it’ll be separate from IE8 ’s standards mode or if it’ll use the same switch remains to be seen.

My dream list for IE:

1. Scrap Trident. It’s old, slow, and bloated. 2. The new rendering engine would be standards compliant. HTML could be compiled for faster DOM interaction. They do it for ASPX . I don’t see a reason they couldn’t for valid HTML documents. 3. JIT compiler for JScript. It’s unclear what exactly Microsoft is doing to offload JScript execution to the GPU . What they should’ve done is develop a JScript compiler for .NET 4 and the DLR and start using that in IE for the JS engine. We’re going to see alot more apps coming out of Microsoft built on, or heavily using the .NET framework after 4.0’s release. I think Visual Studio 2010 using WPF is a beta test for that concept. What better group of people to beta test than developers? A JScript compiler would’ve made perfect sense to JIT JScript code in IE. Why Microsoft didn’t develop one is beyond me. 4. Minimal UI like Chrome.

I’m sure I have more, but thinking about it is a waste of time =/ My dream list will probably never happen.

Scope.

function foo(fn) {
    if (typeof fn === "function") {
        fn();
    }
}

var bar = {
    barbar : "Hello, World!",
    method  : function() {
        alert(this.barbar);
    }
};

bar.method(); // alerts Hello, World!
foo(bar.method); // alerts undefined
foo(function() { bar.method(); }); // alerts Hello, World!

The line with foo(bar.method); should have the same results as the other lines, but method() gets called as a method of window instead of bar. Getting that result requires a workaround like the third calling line. The alternative is to modify foo() to accept an object to use as a context:

function foo(fn, context) {
    if (typeof fn === "function") {
        fn.apply(context);
    }
}

Yeah. I have no idea what I’m talking about

I couldn’t disagree more. JavaScript is not like other languages. The syntax is very familiar, but beyond that it’s a different beast. I’ve always called it a simple-complex language for a reason. It’s easy to get started and use, and it’s easy to get yourself in a pickle if you don’t understand how it works.

The sooner anyone drops their preconceptions of the language, the easier it is to learn and use it.

<span onclick="toggleModal('test title', 'test message', { text : 'test me', onclick : function() {alert('hello');}});">Click Me.</span>

That works for me. I personally wouldn’t do that, though. I’d define a function in a script block and pass the function name:

function testMe() {
    alert("Testing this thing here");
}

...

<span onclick="toggleModal('test title', 'test message', { text : 'test me', onclick : testMe});">Click Me.</span>

Or I would define a “button object” in a script block and pass it to toggleModal(). It makes the onclick attribute a little less unwieldy that way.

var btnOk = {
    text : "OK",
    onclick : function () {
        alert("Hello, World!");
    }
};

...

<span onclick="toggleModal('test title', 'test message', btnOk);">Click Me.</span>

Is there a reason to have more than two buttons in a dialog box? I can’t think of any reason to have more than OK and Cancel.

There’s an arguments collection that contains the values of all parameters passed to the function.

function toggleModal(title, message) {
    // arguments[0] is title
    // arguments[1] is message
    // arguments[2] is anything passed as a third parameter
    // arguments[3] is anything passed as a fourth parameter
    // etc...

    if (arguments.length > 2) {
        var length = arguments.length - 2;

        for (var ii = 3; ii < length; ii++) {
            var arg = arguments[ii];
            var text = arg.text;
            var callBack = arg.onclick;
        }
    }
}

Putting function names in a string means you’re going to have to either use eval() or have strict rules on what scope callback functions are in. The former option is evil, and the second option is too confusing for the majority of people.

I would take a different approach. I’d keep the title and message parameters, but I’d accept objects for buttons.

toggleModal("A Title", "Are you sure?", { 
        text : "Yes", 
        onclick : function() { 
            alert("You clicked yes!");
        }
    }, { 
        text : "No", 
        onclick : function() { 
            alert("You clicked No!");
        }
    });

That way whoever uses your API can have as many “button object” parameters that they need, and you don’t have to do a ton of parsing and eval()ing. You could also accept an array of “button objects”, but that gets into the “too confusing” category. Keep it simple for your users.