7 ms·

The jQuery Divide:Understand where jQuery ends and JavaScript begins

157 points by binarray2000 15y ago

ichilton 15y ago
Here is a video of the talk you refer to: http://jsconfeu.blip.tv/file/4308069/ http://jsconfeu.blip.tv/file/4308069/
perlgeek 15y ago
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?
- ionfish 15y ago
  James Coglan has written a lot [1] about these issues. His series on evented programming [2] is a good place to start. [1] http://blog.jcoglan.com/ http://blog.jcoglan.com/ [2] http://blog.jcoglan.com/2010/02/21/events-theyre-not-just-for-the-dom-you-know/ http://blog.jcoglan.com/2010/02/21/events-theyre-not-just-fo...
- DanielRibeiro 15y ago
  No alternatives? Coffeescript is always an alternative to js: http://jashkenas.github.com/coffee-script/ http://jashkenas.github.com/coffee-script/
  - bcrescimanno 15y ago
    Coffeescript "compiles" to JS--so it's not an alternative to using Javascript; just an alternative syntax for writing javascript.
    - DanielRibeiro 15y ago
      Coffeescript is a different language though. It has different grammar, different keywords and so on. It shares the same object model, and it is usually used on compile form. There are other alternatives as well[1], such as: - LLVM languages: http://syntensity.blogspot.com/2011/04/emscripten-10.html http://syntensity.blogspot.com/2011/04/emscripten-10.html - HotRuby: http://hotruby.yukoba.jp/ http://hotruby.yukoba.jp/ - Smalltalk: http://clamato.net/ http://clamato.net/ - Haxe: http://haxe.org/ http://haxe.org/ - Mascara: http://www.mascaraengine.com/ 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-languages-that-compile-to-JS https://github.com/jashkenas/coffee-script/wiki/List-of-lang...
      - bcrescimanno 15y ago
        I disagree that any language that "compiles" into another language can be considered an "alternative." I'm not bashing CoffeeScript; I haven't played with it much and don't know enough about it say anything one way or the other; but at the end of the day, the result is still Javascript.
    - dionidium 15y ago
      Well, yeah, but you might as well say that JavaScript is just an alternative syntax for writing assembly language or machine code.
- chihiro 15y ago
  Use a good webframework http://ukijs.org/ http://ukijs.org/
- augustl 15y ago
  > So, how does one become a good, non-spaghetti-code javascript developer for the web? 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.
- irahul 15y ago
  > how does one become a good, non-spaghetti-code javascript developer for the web? 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.
- Ruudjah 15y ago
  GWT solves it for me while javascript has these problems.
  - bad_user 15y ago
    IMHO, now you've got 2 problems.
troels 15y ago
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 the fault of Sinatra.rb to not provide the functionality of Rails.
- aristus 15y ago
  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 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 http://jsrosettastone.com) There are newer frameworks (eg JavelinJS) that aim to be to jQuery what jQuery was to other frameworks.
  - smokeyj 15y ago
    > 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.
    - aristus 15y ago
      One can always argue "you're doing it wrong". People say the same about ror and perl. But in my experience, even with a good mvc and object model, and world-class folks, complex applications in jquery tend to become hard to maintain. I believe part of the reason is the tight coupling of state and events to the DOM. 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.
nezumi 15y ago
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 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.
- irahul 15y ago
  > can someone point to a coding standard / style guideline for Javascript + jQuery? 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.
- arijo 15y ago
  http://www.javascriptmvc.com http://www.javascriptmvc.com
- troels 15y ago
  I think the most important, and often violated principle is to keep model and presentation code separated. If your widget has any kind of even slightly complex logic, don't rely on the dom to be your model, or you'll get into a mess quickly. The dom (and thus jquery) is presentation (controller/view). Create separate objects for your model and have your controller code (even handlers) update this and your view be updated from it.
- emehrkay 15y ago
  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/ http://code.keetology.com/company/ its a different approach to solving the same problem(s) as backbone
jokull 15y ago
I was hoping for a Backbone.js mention. A tool like that will get you a long way in structuring your frontend code.
- rmurphey3 15y ago
  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.
emehrkay 15y ago
People at my job call all JavaScript jQuery, it is so annoying. Even more annoying is that their code (jQuery or not) plain sucks
- emehrkay 15y ago
  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. 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}); }); and var collection = jQuery('a'), collected = (function(){ var c = []; $.each(collection, function(i, item){ c.push(jQuery(item)); }); return c; })(); this second way allows you to select an item from collected without having to rewrap it with the jquery object. I dont have any data on it, but it seems like rerunning jQuery() with every mouseover/mouseleave/event etc seems like a waste of processing. 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.
  - arethuza 15y ago
    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 });
    - emehrkay 15y ago
      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.
OzzyB 15y ago
About time someone came out and said this, good job.
- ars 15y ago
  Said what? Did I miss it? He seemed to just stop midway. 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.
  - rmurphey3 15y ago
    I can't speak to what else you missed or didn't miss, but you do seem to have missed that he is a she, so ...
    - rodh257 15y ago
      doesn't change the original point
  - sambeau 15y ago
    'He' is a she: Rebecca Murphey http://twitter.com/#!/rmurphey http://www.rebeccamurphey.com/
  - pampa 15y ago
    The problem is, "this isn't pretty" is pretty much all we've got. There is very little information on how to organize javascript apps, or how to write javascript at all. Nobody knows the solution yet. 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.
chopsueyar 15y ago
Maybe the MVC design pattern doesn't work so well with jQuery in the view, acting as a controller and also for display logic. 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.
joetyson 15y ago
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.
- qusiba 15y ago
  Exactly. I see closure as an ambitious effort to make JavaScript a better language for real complicate applications.
- eneveu 15y ago
  It does look like an interesting library. It's weird that the community seems so small. Here is Michael's blog: http://blog.bolinfest.com/ http://blog.bolinfest.com/ And the HN discussion from when it was first open sourced: http://news.ycombinator.com/item?id=924426 http://news.ycombinator.com/item?id=924426 Compiler : http://code.google.com/closure/compiler/ http://code.google.com/closure/compiler/ Library : http://code.google.com/closure/library/ http://code.google.com/closure/library/ (UI / widgets) Templates: http://code.google.com/closure/templates/ http://code.google.com/closure/templates/
krosaen 15y ago
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.
mcdaid 15y ago
Nice presentation, I am not sure about most people here but I started using jQuery because the documentation was excellent, easy to navigate, with lots of examples. Hence trying it out was simple and I got hooked. 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.
rodh257 15y ago
I don't like presentations like this. What suggestions or solutions were offered? Perhaps the audio mentioned some good resources to use to learn how to properly architect a complex, Javascript/JQuery heavy application, or perhaps I just missed it in the slides, but to me it just seemed like a rant. Sure it's identifying an issue but it would be a whole lot more useful if it gave some links to books/articles/etc with details on how to layout your code in a maintainable manner.
- rmurphey3 15y ago
  I'd encourage you to bear in mind the original audience of the presentation: the very small number of experienced JavaScript developers who managed to obtain a ticket to the 2010 JSConf.eu in Berlin. 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.
suyash 15y ago
great post, I remember last year I interviewed with Flixster and they joked with me that who programs in JavaScript anymore, we all just use jQuery and don't need to write raw JavaScript.
Fluxx 15y ago
jQuery is popular because you don't need any programming experience to be productive. I was introduced to jQuery by our in-house web designer like 3 years ago because he used it and really liked it. He spoke HTML, the DOM and CSS and so does jQuery. And there are far more HTML/CSS literate people doing Javascript than there are CS-educated software engineers doing Javascript. In fact most software engineers I know don't know crap about Javascript. Thankfully I read "Javascript: The Good Parts" and have a much better appreciation for the language. 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.
robfig 15y ago
Since no particular solutions were offered in the talk... HN: What are the best technologies for writing large JS apps? I have experience writing Closure (http://code.google.com/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?

157 points by binarray2000 15y ago

Here is a video of the talk you refer to: http://jsconfeu.blip.tv/file/4308069/ http://jsconfeu.blip.tv/file/4308069/

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?

ionfish 15y ago
James Coglan has written a lot [1] about these issues. His series on evented programming [2] is a good place to start. [1] http://blog.jcoglan.com/ http://blog.jcoglan.com/ [2] http://blog.jcoglan.com/2010/02/21/events-theyre-not-just-for-the-dom-you-know/ http://blog.jcoglan.com/2010/02/21/events-theyre-not-just-fo...
DanielRibeiro 15y ago
No alternatives? Coffeescript is always an alternative to js: http://jashkenas.github.com/coffee-script/ http://jashkenas.github.com/coffee-script/
- bcrescimanno 15y ago
  Coffeescript "compiles" to JS--so it's not an alternative to using Javascript; just an alternative syntax for writing javascript.
  - DanielRibeiro 15y ago
    Coffeescript is a different language though. It has different grammar, different keywords and so on. It shares the same object model, and it is usually used on compile form. There are other alternatives as well[1], such as: - LLVM languages: http://syntensity.blogspot.com/2011/04/emscripten-10.html http://syntensity.blogspot.com/2011/04/emscripten-10.html - HotRuby: http://hotruby.yukoba.jp/ http://hotruby.yukoba.jp/ - Smalltalk: http://clamato.net/ http://clamato.net/ - Haxe: http://haxe.org/ http://haxe.org/ - Mascara: http://www.mascaraengine.com/ 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-languages-that-compile-to-JS https://github.com/jashkenas/coffee-script/wiki/List-of-lang...
    - bcrescimanno 15y ago
      I disagree that any language that "compiles" into another language can be considered an "alternative." I'm not bashing CoffeeScript; I haven't played with it much and don't know enough about it say anything one way or the other; but at the end of the day, the result is still Javascript.
  - dionidium 15y ago
    Well, yeah, but you might as well say that JavaScript is just an alternative syntax for writing assembly language or machine code.
chihiro 15y ago
Use a good webframework http://ukijs.org/ http://ukijs.org/
augustl 15y ago
> So, how does one become a good, non-spaghetti-code javascript developer for the web? 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.
irahul 15y ago
> how does one become a good, non-spaghetti-code javascript developer for the web? 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.
Ruudjah 15y ago
GWT solves it for me while javascript has these problems.
- bad_user 15y ago
  IMHO, now you've got 2 problems.

troels 15y ago

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 the fault of Sinatra.rb to not provide the functionality of Rails.

aristus 15y ago
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 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 http://jsrosettastone.com) There are newer frameworks (eg JavelinJS) that aim to be to jQuery what jQuery was to other frameworks.
- smokeyj 15y ago
  > 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.
  - aristus 15y ago
    One can always argue "you're doing it wrong". People say the same about ror and perl. But in my experience, even with a good mvc and object model, and world-class folks, complex applications in jquery tend to become hard to maintain. I believe part of the reason is the tight coupling of state and events to the DOM. 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.

nezumi 15y ago

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 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.

irahul 15y ago
> can someone point to a coding standard / style guideline for Javascript + jQuery? 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.
arijo 15y ago
http://www.javascriptmvc.com http://www.javascriptmvc.com
troels 15y ago
I think the most important, and often violated principle is to keep model and presentation code separated. If your widget has any kind of even slightly complex logic, don't rely on the dom to be your model, or you'll get into a mess quickly. The dom (and thus jquery) is presentation (controller/view). Create separate objects for your model and have your controller code (even handlers) update this and your view be updated from it.
emehrkay 15y ago
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/ http://code.keetology.com/company/ its a different approach to solving the same problem(s) as backbone

jokull 15y ago

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

rmurphey3 15y ago
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.

emehrkay 15y ago

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

emehrkay 15y ago
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. 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}); }); and var collection = jQuery('a'), collected = (function(){ var c = []; $.each(collection, function(i, item){ c.push(jQuery(item)); }); return c; })(); this second way allows you to select an item from collected without having to rewrap it with the jquery object. I dont have any data on it, but it seems like rerunning jQuery() with every mouseover/mouseleave/event etc seems like a waste of processing. 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.
- arethuza 15y ago
  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 });
  - emehrkay 15y ago
    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.

OzzyB 15y ago

About time someone came out and said this, good job.

ars 15y ago
Said what? Did I miss it? He seemed to just stop midway. 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.
- rmurphey3 15y ago
  I can't speak to what else you missed or didn't miss, but you do seem to have missed that he is a she, so ...
  - rodh257 15y ago
    doesn't change the original point
- sambeau 15y ago
  'He' is a she: Rebecca Murphey http://twitter.com/#!/rmurphey http://www.rebeccamurphey.com/
- pampa 15y ago
  The problem is, "this isn't pretty" is pretty much all we've got. There is very little information on how to organize javascript apps, or how to write javascript at all. Nobody knows the solution yet. 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.

chopsueyar 15y ago

Maybe the MVC design pattern doesn't work so well with jQuery in the view, acting as a controller and also for display logic. 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.

joetyson 15y ago

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.

qusiba 15y ago
Exactly. I see closure as an ambitious effort to make JavaScript a better language for real complicate applications.
eneveu 15y ago
It does look like an interesting library. It's weird that the community seems so small. Here is Michael's blog: http://blog.bolinfest.com/ http://blog.bolinfest.com/ And the HN discussion from when it was first open sourced: http://news.ycombinator.com/item?id=924426 http://news.ycombinator.com/item?id=924426 Compiler : http://code.google.com/closure/compiler/ http://code.google.com/closure/compiler/ Library : http://code.google.com/closure/library/ http://code.google.com/closure/library/ (UI / widgets) Templates: http://code.google.com/closure/templates/ http://code.google.com/closure/templates/

krosaen 15y ago

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.

mcdaid 15y ago

Nice presentation, I am not sure about most people here but I started using jQuery because the documentation was excellent, easy to navigate, with lots of examples. Hence trying it out was simple and I got hooked. 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.

rodh257 15y ago

I don't like presentations like this. What suggestions or solutions were offered? Perhaps the audio mentioned some good resources to use to learn how to properly architect a complex, Javascript/JQuery heavy application, or perhaps I just missed it in the slides, but to me it just seemed like a rant. Sure it's identifying an issue but it would be a whole lot more useful if it gave some links to books/articles/etc with details on how to layout your code in a maintainable manner.

rmurphey3 15y ago
I'd encourage you to bear in mind the original audience of the presentation: the very small number of experienced JavaScript developers who managed to obtain a ticket to the 2010 JSConf.eu in Berlin. 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.

suyash 15y ago

great post, I remember last year I interviewed with Flixster and they joked with me that who programs in JavaScript anymore, we all just use jQuery and don't need to write raw JavaScript.

Fluxx 15y ago

jQuery is popular because you don't need any programming experience to be productive. I was introduced to jQuery by our in-house web designer like 3 years ago because he used it and really liked it. He spoke HTML, the DOM and CSS and so does jQuery. And there are far more HTML/CSS literate people doing Javascript than there are CS-educated software engineers doing Javascript. In fact most software engineers I know don't know crap about Javascript. Thankfully I read "Javascript: The Good Parts" and have a much better appreciation for the language. 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.

robfig 15y ago

Since no particular solutions were offered in the talk... HN: What are the best technologies for writing large JS apps? I have experience writing Closure (http://code.google.com/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?