Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The jQuery Divide:Understand where jQuery ends and JavaScript begins

slideshare.net

Post reply on HN
Print view View original

21–30 of 78 posts

Re: The jQuery Divide:Understand where jQuery ends and JavaScript begins

#21

Post by emehrkay »

nezumi wrote: post #9

Hey! That's exactly how my jQuery code looks! I think I just got seduced by all the closurey goodness that comes with Javascript (my day-job languages don't let me do that.) 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…

I know that it is extremely simply to write spaghetti code in just about any language, using any supporting library, but I'd say check out some of the stuff that the MooTools guys are doing. I come back simply amazed at some of the things that they're doing. Check Company http://code.keetology.com/company/ its a different approach to solving the same problem(s) as backbone

Re: The jQuery Divide:Understand where jQuery ends and JavaScript begins

#22

Post by joetyson »

I don't see it mentioned very often, but google's closure-library has some really phenomenal patterns for building maintainable javascript. Its worth checking out Michael Bolin's book, Closure: The Definitive Guide, which goes in depth of the Component and Control frameworks.

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.

Re: The jQuery Divide:Understand where jQuery ends and JavaScript begins

#23

Post by arethuza »

emehrkay wrote: post #20
emehrkay wrote: post #17

People at my job call all JavaScript jQuery, it is so annoying. Even more annoying is that their code (jQuery or not) plain sucks

When I use jQuery (MooTools is my lib of choice) I find myself using it in ways that is very unlike the majority of jQuery that is seen around the web. 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. A…

Isn't that second code snippet actually creating a jQuery object for each "a" - even if it is never clicked on? Isn't that rather more of a "waste of processing" than the first, where a jQuery object is created in the event handler?

Why wouldn't you write the first one as:

   $("a").click(function() { // do stuff });

Re: The jQuery Divide:Understand where jQuery ends and JavaScript begins

#24

Post by rmurphey3 »

jokull wrote: post #10

I was hoping for a Backbone.js mention. A tool like that will get you a long way in structuring your frontend code.

Backbone.js came out just a couple of weeks before I gave this talk in October 2010, and I just hadn't had time to look at it enough to feel comfortable mentioning it. It is definitely a powerful tool for bringing structure to an application, and I'd certainly mention it if I were to give the talk today.

Re: The jQuery Divide:Understand where jQuery ends and JavaScript begins

#25

Post by emehrkay »

arethuza wrote: post #23
emehrkay wrote: post #20

Earlier quoted context omitted.

When I use jQuery (MooTools is my lib of choice) I find myself using it in ways that is very unlike the majority of jQuery that is seen around the web. 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. A…

Isn't that second code snippet actually creating a jQuery object for each "a" - even if it is never clicked on? Isn't that rather more of a "waste of processing" than the first, where a jQuery object is created in the event handler? Why wouldn't you write the first one as: $("a").click(function() { // do stuff });

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 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();
        }
    );
vs

    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();
            }
      );
    );
This is a very rudimentary example and I know that there is a simpler way to accomplish this, but imagine code with multiple collected items who all match up on a 1 to 1 basis collecting the pre-wrapped objects has its advantages.

Re: The jQuery Divide:Understand where jQuery ends and JavaScript begins

#26

Post by albemuth »

emehrkay wrote: post #20
emehrkay wrote: post #17

People at my job call all JavaScript jQuery, it is so annoying. Even more annoying is that their code (jQuery or not) plain sucks

When I use jQuery (MooTools is my lib of choice) I find myself using it in ways that is very unlike the majority of jQuery that is seen around the web. 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. A…

>>allows you to select an item from collected without having to rewrap it with the jquery object

I think the following does the same thing:

    var collected = $('a').map(function(element) {return $(element)})

Re: The jQuery Divide:Understand where jQuery ends and JavaScript begins

#27

Post by emehrkay »

albemuth wrote: post #26
emehrkay wrote: post #20

Earlier quoted context omitted.

When I use jQuery (MooTools is my lib of choice) I find myself using it in ways that is very unlike the majority of jQuery that is seen around the web. 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. A…

>>allows you to select an item from collected without having to rewrap it with the jquery object I think the following does the same thing: var collected = $('a').map(function(element) {return $(element)})

Nice, I didnt know that jQuery had map. Thanks.

Re: The jQuery Divide:Understand where jQuery ends and JavaScript begins

#28

Post by albemuth »

arethuza wrote: post #23
emehrkay wrote: post #20

Earlier quoted context omitted.

When I use jQuery (MooTools is my lib of choice) I find myself using it in ways that is very unlike the majority of jQuery that is seen around the web. 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. A…

Isn't that second code snippet actually creating a jQuery object for each "a" - even if it is never clicked on? Isn't that rather more of a "waste of processing" than the first, where a jQuery object is created in the event handler? Why wouldn't you write the first one as: $("a").click(function() { // do stuff });

I guess it's just bit of cpu for memory trade-off

Re: The jQuery Divide:Understand where jQuery ends and JavaScript begins

#29

Post by xtian »

emehrkay wrote: post #25
arethuza wrote: post #23

Earlier quoted context omitted.

Isn't that second code snippet actually creating a jQuery object for each "a" - even if it is never clicked on? Isn't that rather more of a "waste of processing" than the first, where a jQuery object is created in the event handler? Why wouldn't you write the first one as: $("a").click(function() { // do stuff });

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?

Re: The jQuery Divide:Understand where jQuery ends and JavaScript begins

#30

Post by krosaen »

IMHO the most important "clean code" boundary for web apps is a non-enhanced interface (plain old forms). From there, pages can progressively enhance until the cows come home with jquery plugins and complicated interface code, but as long as you know it boils down to a form submission, it's easy to understand what is going on in the application. The form is the model into your web app, and everything else is just sugar.

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.

Post reply on HN