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.
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.<p>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.<p>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.<p>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 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.<p>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.
So, how does one become a good, non-spaghetti-code javascript developer for the web?<p>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?
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.)<p>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?<p>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?<p>I'd love to see all that stuff documented in one place. It must be out there somewhere.
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.
jQuery is popular because you don't need <i>any</i> programming experience to be productive. I was introduced to jQuery by our in-house web <i>designer</i> 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.<p>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.
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.<p>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.<p>Also I think a distinction can be made between using jQuery and using the widget factory which does allow for more modular maintainable code.
Maybe the MVC design pattern doesn't work so well with jQuery in the view, acting as a controller and also for display logic.<p>Surely there is a design pattern that does not try to shoehorn AJAX via jQuery into what was once an MVC pattern?<p>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.
Since no particular solutions were offered in the talk...<p>HN: What are the best technologies for writing large JS apps?<p>I have experience writing Closure (<a href="http://code.google.com/closure/" rel="nofollow">http://code.google.com/closure/</a>) 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.<p>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.<p>Is there something better? backbone?