31–40 of 78 posts
So, how does one become a good, non-spaghetti-code javascript developer for the web? 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?
No alternatives? Coffeescript is always an alternative to js: http://jashkenas.github.com/coffee-script/
Earlier quoted context omitted.
if you need to do stuff with a inside of the function, then you have to do $(this), so every time an a in that collection is clicked $() is run. 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 t…
But wouldn't multiple potentially long loops on initial load have a greater possible impact on user experience than one extra call to $() per event?
var memd = {},
getMem = function(obj){
var o;
if(memd[obj]){
o = memd[obj];
}else{
o = memd[obj] = $(obj);
}
return o;
};
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.
Earlier quoted context omitted.
But wouldn't multiple potentially long loops on initial load have a greater possible impact on user experience than one extra call to $() per event?
Great point. I think that my simplistic example is just that, simplistic. A better solution for huge collections would be to memoize the retrieval of the $() obj with something like var memd = {}, getMem = function(obj){ var o; if(memd[obj]){ o = memd[obj]; }else{ o = memd[obj] = $(obj); } return o; }; and call that function instead of calling $() while inside of an event handler (I havent tested this code, but the c…
I'm not so sure I buy the premise that jquery is unsuitable for large scale applications. I think it is based on an assumption that jquery should provide a framework for these things, but really - what jquery is, is a framework for the controller layer of an application. If you want to use it, you have to provide the model level framework your self. I don't think this is the fault of jquery anymore than it would be t…
jQuery as commonly used leads, in my personal experience, to hard-to-maintain programs. Just like Ruby on Rails, or Perl. 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 throu…
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.
About time someone came out and said this, good job.
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.
Earlier quoted context omitted.
Great point. I think that my simplistic example is just that, simplistic. A better solution for huge collections would be to memoize the retrieval of the $() obj with something like var memd = {}, getMem = function(obj){ var o; if(memd[obj]){ o = memd[obj]; }else{ o = memd[obj] = $(obj); } return o; }; and call that function instead of calling $() while inside of an event handler (I havent tested this code, but the c…
I don't want to appear snarky, but as you admit yourself ("I dont have any data on it") you don't know if creating a jQuery object is expensive or not (to be fair, I don't know either) - so why all the extra complexity if you don't know whether the thing you are trying to avoid (creating instance of jQuery during event handlers) actually causes problems or not?
$('.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?
So, how does one become a good, non-spaghetti-code javascript developer for the web? 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?
GWT solves it for me while javascript has these problems.
Earlier quoted context omitted.
jQuery as commonly used leads, in my personal experience, to hard-to-maintain programs. Just like Ruby on Rails, or Perl. 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 throu…
> jQuery as commonly used leads, in my personal experience, to hard-to-maintain programs. 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.
I'm not so sure I buy the premise that jquery is unsuitable for large scale applications. I think it is based on an assumption that jquery should provide a framework for these things, but really - what jquery is, is a framework for the controller layer of an application. If you want to use it, you have to provide the model level framework your self. I don't think this is the fault of jquery anymore than it would be t…
jQuery as commonly used leads, in my personal experience, to hard-to-maintain programs. Just like Ruby on Rails, or Perl. 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 throu…
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 ;-)