The jQuery Divide:Understand where jQuery ends and JavaScript begins
slideshare.net
slideshare.net
There is also anecdotal evidence that jQuery qua jQuery has some fundamental limits. I worked on a largish jQuery application, written by ninja badasses, and it creaked a lot more than it should have for its size.
Comparable systems built on YUI seemed to have more structure. I actually went through the exercise of converting a prototype from jQuery to YUI3, and spent a lot of time working out their respective "philosophies". (see http://jsrosettastone.com)
There are newer frameworks (eg JavelinJS) that aim to be to jQuery what jQuery was to other frameworks.
People using jQuery improperly is not something wrong with jQuery. jQuery is perfectly fine for large web applications, you just need to organize your code properly, with something like a MVC and ORM layer.
I'm also very skeptical of the dozen-odd undocumented "extensions" to the selector language. They are useful, but tend to tie you to jQueryisms. I didn't realize for a long time that :first was not valid CSS3.
Now that we've gone all the way down the pedantry slide, have you anything of value to contribute, or was that it?
If you want to pick on something that claims compatibility, try Sizzle itself - http://sizzlejs.com/. In that case, you'll find a summary of alterations right at the top of its documentation https://github.com/jquery/sizzle/wiki .
I worked on a largish jQuery application,
written by ninja badasses
If they were, they would realize that jQuery is not a framework that structures your application, but just a neat and light library that provides syntactic sugar for DOM-manipulation + dealing with cross-browser issues.
jQuery as commonly used leads, in my personal
experience, to hard-to-maintain programs. Just
like Ruby on Rails, or Perl.
Newsflash: bad developers write bad code.
And yes, I've worked with Perl -- Catalyst and DBIx::Class are pretty good, you should check them out ;-)
I've also noticed a new trend in complex applications, eg JavelinJS and Yahoo's "Minty" mail app, that moves away from jQuery's or YUI's model. They feature a centralized controller/arbiter and a separation of CSS classes and event markup. Instead of jQuery + MVC it's a little of both.
And whether working on an android app, a QT application in C++ or a jquery based rich client interface, rich client functionality is always somewhat messy in my experience by nature of having many complex interactions in a stateful environment. I certainly don't see using YUI as a silver bullet to alleviate the complexity. As long as it is always clear where the boundaries between the communication between the client code and the server / and its model, you will maintain a clean and maintainable core.
If you want to ditch the idea of progressive enhancement and work directly with a web api to your server, then similar rules apply; as long as it is clear that "this page / widget presents a snazzy interface to update this model" you can remain sane in the organization of your app.
Finally, if you have a super rich interface like Asana, pivotal tracker or google wave where the entire page is presenting many models at once in many forms, then a functional reactive approach may help, using something like backbone or what luna script promises to be. But using a framework like that has its own cost and complexity and IMO is overkill for many of the web apps out there.
I've been using the library for 2 or 3 years now, and I am always surprised to see it has such a small community.
Here is Michael's blog: http://blog.bolinfest.com/
And the HN discussion from when it was first open sourced: http://news.ycombinator.com/item?id=924426
Compiler : http://code.google.com/closure/compiler/
Library : http://code.google.com/closure/library/ (UI / widgets)
Templates: http://code.google.com/closure/templates/
I don't really like js so far, but there are just no alternatives in some cases. And my code ends up like those counter examples. Where can learn how to organize it properly?
[2] http://blog.jcoglan.com/2010/02/21/events-theyre-not-just-fo...
There are other alternatives as well[1], such as:
- LLVM languages: http://syntensity.blogspot.com/2011/04/emscripten-10.html
- HotRuby: http://hotruby.yukoba.jp/
- Smalltalk: http://clamato.net/
- Haxe: http://haxe.org/
- Mascara: http://www.mascaraengine.com/
And so on. Coffeescript is just closer to javascript than most alternatives. But it is a different language, and a nicer one in my humble opinion.
[1] https://github.com/jashkenas/coffee-script/wiki/List-of-lang...
Like everything else: throw a lot of time at it, and have a desire to make awesome things. Other than explicit feedback on written code, there is no one thing I could tell you to help you write better JavaScript for web browsers.
Just like anything else, it will take time and active effort. Till then, I suggest work with frameworks which help you structure your code. I use backbone.js and I have heard good things about YUI.
I'm not going to ask how to write good code, but I think this is a fair question: can someone point to a coding standard / style guideline for Javascript + jQuery?
E.g., when to choose a single-use named function over an anonymous function? When to bind jQuery results to variables vs. go crazy with chaining? Any advice on good selector practices? Good html naming conventions?
I'd love to see all that stuff documented in one place. It must be out there somewhere.
backbone.js is good. That gives you a fair idea about structuring your application. If you webapp is designed in a RESTful manner, backbone.js maps quite nicely to your backend.
I absolutely hate the plugin system simply because you cannot easily get the instance of the plugin an refer to it later. To answer this I use function constructors with the module pattern (its easy and doesnt require an extra lib to get going) to create my plugins. Another thing that I do is when I query for a collection of objects, create an array that represents every item in that collection already wrapped with the jQuery object. This may not seem like a big deal, but there is a difference between
var collection = jQuery('a');
collection.each(function(i, l){
var link = jQuery(l);
link.bind('click', function(){//do suff});
});
var collection = jQuery('a'),
collected = (function(){
var c = [];
$.each(collection, function(i, item){
c.push(jQuery(item));
});
return c;
})();
Anyway, that is just a few ways that I use jQuery to make javascript a bit easier. These little tricks have the people that I work with thinking that I'm some sort of genius.
Why wouldn't you write the first one as:
$("a").click(function() { // do stuff });In my first example I actually took that problem out of the equation by looping through the collection and storing the jQuery'd a as a var accessible via the event closure. However, if you want to reference an element in that collection later in your code, you have to jump though the jQuery selection hoops.
But you are right, sometimes you may not need to have every element in your selection wrapped in the jQuery object and it is up to you to determine which solution to use in a given case. But I do feel that most cases I see devs constantly wrapping $(this) inside of event handlers when they could have made an external reference/collection before hand and used that.
$('a').hover(
function(e){
$(this).doSomething();
},
function(e){
$(this).doSomething();
}
);
var as = $('a'),
collected //using the same method as above;
as.each(function(i, e){
collected[i].hover(
function(e){
collected[i].doSomething();
},
function(e){
collected[i].doSomething();
}
);
);
var memd = {},
getMem = function(obj){
var o;
if(memd[obj]){
o = memd[obj];
}else{
o = memd[obj] = $(obj);
}
return o;
};
$('.class').doSomehting();
$('.class').doSomethingElse();
$('.class').thirdThing();
var ele = $('.class');
ele.doSomething();
ele.doSomethingElse();
ele.thirdThing();
Lets say you have a very simple tabbed thing
//this is code that i've seen around
var tabs = $('a.tab'),
containers = $('div.container');
tabs.click(function(e){
var index = tabs.indexOf($(this));
tabs.removeClass('active');
$(this).addClass('active');
containers.css('display', 'none');
$(containers[index]).css('display', 'block');
});
$.each(all_tabs, function(i, tab){
var t = $(tab);
t.bind('click', function(e){
tabs.removeClass('active');
t.addClass('active');
containers.css('display', 'none');
all_containers[i].css('display', 'block');
});
});
If running the jQuery object isnt too expensive, why is the practice of rerunning the same selector frowned upon?
That's also why it's recommended that all selections start with an id. The size of the tree to iterate over can be quickly reduced using the native getElementByID method.
In the case of $(this), the DOM node is already passed to the event handler, so wrapping it in a jQuery object doesn't touch the DOM tree at all. Furthermore, I always cache it (var $this = $(this);) if I'm going to use it more than once.
Also, in your first example, you don't have to rewrap containers[index] in a jQuery object. All the elements in the selection are already wrapped.
Really? I think that is the whole point of this long comment thread -- that the elements in a collection arent already wrapped.
This doesnt work unless i wrap a[i] in $()
But like you're saying, it may be fruitless since the dom is the bottleneck and we're bypassing it by already having the element.
1) You've got a "global" named a and then a local variable (via the argument) inside the each function called "a"...so that really confuses things.
2) a[i] where a is a jQuery object returns an unwrapped DOM element...what you want is .index().
3) What you're doing is sort of roundabout...
Why not:
var d = $('div'),
a = $('a');
a.each(function(i, el){
d.text(d.text() +' '+ $(this).text() );
});
var d = $('div'),
a = $('a');
a.each(function(i, el){
d.text(d.text() +' '+ a.index(i).text() );
}); var d = $('div'),
a = $('a');
a.each(function(i, el){
d.text(d.text() +' '+ a.eq(i).text() );
});
So if you do have some complex selector then I can see that avoiding re-running it makes a lot of sense - for DRY as much as efficiency. However, in an event handler you've been handed the element you want to work with and all you are doing is wrapping it in jQuery to make it easier to work with.
Or something like that :-)
Rerunning the same selector is frowned upon for (at least) 2 reasons:
1) It can make for more readable code.
Sometimes it makes more sense semantically to have a local variable that describes the role of an element in the particular block of code you are working on, rather than just what selector you are using to get at the element.
Also, it makes the code shorter and less complex, in your example "tabs" is shorter and easier to read than "$('a.tabs')" etc.
2) ...because it's a stupid simple optimization to make.
This goes in general for ANY JS variable that is not in local scope, is the property of an object, or is returned as the result of a function.
It's so easy to just cache it as a local variable, you should probably just do that once you are accessing it a few times.
Even that has the whiff of premature optimization, but it's so easy and has such a low impact (or even improvement) on readability, that it's no big deal.
What you're talking about is much harder to justify imho.
Re-running the same selector is an instance where you are re-running a function that will definitely return the same result that you just got.
Effectively it's the same as
function get5(){ return 5; };
var x = 4 + get5();
var y = 35 + get5();
It's hard to say because your examples aren't entirely clear to me, but I don't think your version as is is any better, perhaps even worse in some respects.
$('a.tab') returns A jQuery object that has a context that is a collection of DOM elements.
Your map function (which has the arguments reversed fyi) return's an array of jQuery objects (plural); each with a context of a single DOM element.
So you're creating a bunch of new instances of jQuery objects to possibly save an insignificant amount of context lookup time (getting the context of a jQuery object is not as heavy as selector lookup).
Again in the each you're creating a new jQuery object for each tab element, even though it was already in one. A jQuery object which will stick around via the closure.
So this is all to save looking up the index each click event for the tab (btw, something like $(this).index() would probably be cleaner) which may or may not be worth it.
I can see where you're going, and think you've got the right idea, but I also think what you use really depends on the situation.
I would say just write clean and idiomatic code first...that should be the default.... and then if you hit problems you can start optimizing based on the situation.
If looking up the index and context each click really is a problem (could be in some situations) you could find a solution based on the situation using strategies like event delegation, strategic naming, caching the index, associating them in a data structure of some kind, of any combination thereof.
> Your map function (which has the arguments reversed fyi)
Oh god, jquery is php.
https://github.com/jquery/jquery/blob/master/src/core.js#L67
Wrapping elements in event handlers is completely fine.
I think the following does the same thing:
var collected = $('a').map(function(element) {return $(element)}) var collected = $('a').map($)
So, what you actually want is:
var collected = $('a').map(function(index, element) {return $(element)})
http://api.jquery.com/jQuery.map/
I would consider this to be the more intuitive way round, although I'd prefer it if both maps were consistent. So, you could write:
var collected = $.map($('a'), $)
There is a method called .eq() that allows you to select from the collection and it returns the element wrapped for you.
Friend: "Can I see some of the JSON?" In-over-his-head Developer: "Sure, here." Friend: "That's not JSON, that's jQuery." Dev: "Whatever, it's the same thing." Friend: "No it's not and you thinking it is, is the real problem here."
The goal of this presentation wasn't to teach people how to write good JavaScript -- many of the people in the room that day can and do write circles around me. Rather, the goal was to urge them, the experienced JS devs who are inventing the answers to these questions, to take seriously the need for creating exactly the information you point out to be lacking, and to be intellectually rigorous and honest in discussions of various solutions.
I'd suggest that you pay extra attention to the presentation starting at slide 40, and especially to what I said on slide 60: "Sharing what we know is as important as making new things." That, in a nutshell, was the message I sought to convey to the audience in October.
I also like jQuery as well. If you're doing simple DOM manipulation, AJAX and light javascript work it's hard to do any better. But I think there are superior choices for some more heavy lifting JS projects.
At that time IMO the other libraries apart from YUI, did not seem to have everything in place to learn how to use them quickly. I was put off YUI at the time because it seemed incredibly verbose, this has since been improved.
Also I think a distinction can be made between using jQuery and using the widget factory which does allow for more modular maintainable code.
Surely there is a design pattern that does not try to shoehorn AJAX via jQuery into what was once an MVC pattern?
MVC for webapps was around long before AJAX, yet the design pattern remained the same, after the widespread introduction of AJAX in webapps. Until very recently, there has been little traction in an 'evolved' design pattern, incorporating what the js is doing.
HN: What are the best technologies for writing large JS apps?
I have experience writing Closure (http://code.google.com/closure/) and its structure is pretty scalable, but it feels like so much effort to do simple things. Styling the widgets is a pain. Making a custom widget (extending goog.ui.Component) is surprisingly difficult to get right for even simple extensions.
After all that, I still think it's probably better to develop in that over jQuery -- at least you end up with a straightforward, modular, testable structure at the end of the day.
Is there something better? backbone?
He implied there was a problem, showed some code, but never showed where the problem lies or what it was, and certainly never mentioned any solution.
All I got was some vague "this isn't pretty" vibes.
http://twitter.com/#!/rmurphey
http://www.rebeccamurphey.com/Most of the stuff on javascript programming is bullshit. "Javascript, The Good Parts" from Douglas Crockford is good. But it is only a start, we need more of that. The majority of books is trying to apply OOP design patterns or plainly translate GoF. I'm sure we can do better now.