4 ms·
The inner platform arises out of how the JQuery ($) function/object and all the methods behave. Compare conventional DOM code: var d = document.getElement
by dstein 16y ago
The inner platform arises out of how the JQuery ($) function/object and all the methods behave.
Compare conventional DOM code:
var d = document.getElementById('elm');
d.style.color = 'red';
d.onclick = function() {}
To JQuery code:
$('#elm').color('red').click(function(){});
Now what if you want to add debug statements between the style and event statements? Using JQuery you have to "undo" the inner platform in order to get access to the actual element object:
var d = $('#elm').get(0);
// debug code
$(d).color('red')
// debug code
$(d).click(function(){});
All of a sudden what made JQuery concise starts getting in the way.
- konad 16y agoThat's where I'm coming from. But I guess it's just years of beind used to doing JS by hand.
- Encosia 16y agoThat seems like an unfairly contrived example. Even so, you should be using a real debugger anyway at this point, not printf debugging. Stepping through tight code like that and observing some watches is very easy in a client-side debugger.
- dstein 16y agoI wasn't talking about debugging techniques. It doesn't matter at all what you do between those statements. Any time you need to access DOM elements or do anything rudimentary JQuery just gets in the way because you can't even make use of local variables and for-loops without resulting in spaghetti code.
- Encosia 16y agoFundamentally, jQuery is just a JavaScript API to normalize the DOM. It doesn't force you to program or organize your code in a certain way (i.e. Spaghetti coding). I'm honestly curious to see a legitimate example of what you mean.
- dstein 16y ago"It doesn't force you to program or organize your code in a certain way" Yes it does. JQuery calls it "new wave JavaScript", but really it's just an anti-pattern. JQuery forces you to select all elements using $() before being able to use any of the methods. And you have to call $().get(0) to get the selected element out. It is this unnecessary process that gets very tiresome. Let's see if this makes it more clear: $('#elm').color('red'); /* do some stuff here */ $('#elm').text('new text'); To simplify that (and not require a redundante DOM call) you'd use a local variable to store a reference to the element: var d = $('#elm').get(0); $(d).color('red'); /* do some stuff here */ $(d).text('new text'); I argue that this is unnecessary when you could just write conventional code instead: var d = document.getElmentById('elm'); d.style.color = 'red'; /* do some stuff here */ d.innerHTML = 'new text'; The way the $() function operates just doesn't sit well with all coders, regardless of how solid JQuery is in other respects.
- Encosia 16y agoThat isn't necessary. This does the same thing: var d = $('#elm'); d.color('red'); // do some stuff here. d.text('new text');
- andrewf 16y agoSome use the convention that jQuery objects should be prefixed with $, so: var $d = $('#elm'); $d.color('red'); $d.text('new text'); I do this, and like it, despite my classic aversion to both Systems Hungarian and GW-BASIC.
- simonw 16y agoIf you want to access the underlying DOM element (which I very rarely find myself needing to do when working with jQuery - the $-enhanced version provides methods for everything I might want to do with it) a shorter idiom than .get(0) is this: var el = $('#el')[0];
- FooBarWidget 16y agoA few years ago I might have agreed with your statement. It was the reason why I used Prototype instead of jQuery: prototype extends the HTMLElement classes directly instead of requiring a wrapper object like jQuery does. But for various reasons I've switched to jQuery half a year ago, and I've never looked back. I can't say that the $() stuff is that much of an issue: it's clearly documented, easy to use, and I find the general DOM methods to be so useless that I'm only using the Prototype/jQuery methods 90% of the time anyway. Your claim that it's an anti-pattern is way exaggerated.
- code_duck 16y agoNo, it's not contrived - it's what people actually do. It seems perfectly reasonable to me.
- FooBarWidget 16y ago'console.log(a_jquery_object)' works just fine. Firebug displays it as an array, allowing me to peek inside its elements. I don't know why one would need to get the underlying element before passing it to the debug-printer. I do this all the time and it has never bothered me once.
- code_duck 16y agoOh dear, I seem to have mixed up the threads here. Kindly disregard...
- dagw 16y agoyou should be using a real debugger anyway I know that I should, and if you know a "real" debugger that works under IE7 (and preferably IE6) that is more powerful than print debugging I'd love to hear about it.
- shib71 16y agoYou could do this by adding your own .debug() function. In some ways this would add an advantage, because you would be making your debug code reusable. Example: jQuery.fn.debug = function(){ if (console && console.log) console.log(this); return this; }; ... $('#elm').debug().color('red').debug().click(function(){}).debug();