New for Sugar 6.5: In with jQuery, and the beginning of the move away from YUI

sugarcrmdevelopers —  May 14, 2012 — 23 Comments

Sugar 6.5 begins another component change for the platform, which is to include jQuery 1.6.4 as a core component going forward. Over time, we will be using jQuery to replace the usage of YUI thoughout the product; the goal is to initially replace YUI 3, and then longer term to replace the use of YUI 2. Many of the developers across our partner and open source developer community are big fans of jQuery, as are we, and we hope the move to jQuery will make working with JS much easier in the product going forward. This will also enable us to make great strides in the UX and UI of the app as a whole over the next year.

With jQuery, comes a bunch of new functionality in the ease of dealing with HTTP requests and script loading. One such example is getting around problems loading scripts with the AJAX UI, as referenced in this blog post:

I add a javascript file to editview

http://custom/modules/zz_css_job/zz_css_job.acronym%20title=

this worked fine in 5.5 and works in 6.4 if the ajaxui is disabled

but if I use it with the ajaxui I get all sorts of JavaScript issues

any ideas how I can get round this without disable the ajaxui?

While one way is to leverage metadata to load in the javascript components, another simplier way is to use

jQuery has a nice function called $.getScript(), which will load a script and then execute a piece of code once it’s loaded. This enables adding simple widgets in HTML fields for the various views, such as the DetailView. A great example one is the widget provided by the joind.in project, which is a site for managing conference and speaker feedback for events. They have a simple widget for showing the ratings for a talk which is a simple JS piece of code, which with a small bit of refactoring will drop right into a Sugar HTML with the following code segment ( assume the widget field name is joindin_widget and the talk id is in the joindin_id field )

Hopefully the use of jQuery will make developing Sugar customizations and add-ons much easier for our developer community going forward.

23 responses to New for Sugar 6.5: In with jQuery, and the beginning of the move away from YUI

  1. 

    As opposed to YUI 3 where it is Y.Get.js(“http://joind.in/widget/widget.php”, function() {
        joindin.draw(document.getElementById(‘joindin_id’).innerHTML,”joindin_widget”); });

  2. 

    Wasn’t is possible to use 1.7.x branch where delegate events performances have been really increased in jQuery ?

  3. 

    Bad short term decision. YUI3 enforces standards and understanding but why should that bother Sugar developers. Shutup and get programmin’!

  4. 

    Actually YUI is much better at loading resources than jQuery. Like Jude mentions, Y.Get.script does the same, but the difference is that jQuery.getScript uses Ajax which can have cross-domain issues that YUI avoids by using script tags under the hood. Also, YUI also has Y.Get.css which can be very useful for loading stylesheets in cases like yours (loading widgets from code).

    Now that you make thing about it, I’ll add to my YUI Gallery Deferred module the ability to do Y.when(Y.io.script(foo), Y.io.css(bar), function () { }) just like jQuery does.

    It’s a shame that you have to rewrite all your YUI code and miss on its quality tools because of the popularity of the library. Could you tell us what your experience was when you tried to evangelize the library to your community?

  5. 
    Nate Cavanaugh May 14, 2012 at 12:35 pm

    This seems pretty interesting that you guys are switching to jQuery. Not too long ago, we actually did the opposite at Liferay and switched from jQuery to YUI3.
    Having supported numerous people on both libraries for a while now, you guys will hit snags on the other side of the fence.
    On the one hand, I totally understand the desire for the ease of use that jQuery provides, and since that covers a good portion of the most common tasks, however, as you want to accomplish more and more complex tasks, it doesn’t expand as well as YUI3.
    The areas it really does well is on helping guide developers modularization of components (which means much higher reusability, and much easier maintenance), as well as allowing you to decide just how lean you’d like to go.
    I will agree that there is more initial overhead on learning YUI, however, we also have found that our apps have been able to be richer, more powerful, and easier to maintain.

    Of course you guys know your users and developers better than I do, and I know from experience how large of a decision it is to replace an entire UI library, so I’m sure it was well thought out.

    But there are always tradeoffs when choosing libraries, and for us, the tradeoffs heavily leaned in YUI3’s favor 🙂

  6. 

    Switching from YUI3 to jQuery is a bit like switching from cooking all your own meals to eating nothing but frozen TV dinners: sure it’s easier but your long term health (or in this case your application’s health) will soon begin to suffer and not get better.

  7. 

    As a Sugar Developer I completely support the inclusion of jQuery. YUI folks should know that YUI2 is still in the framework and likely will be for sometime. The majority of tasks that need to be accomplished in the Sugar UI are simply easier and more straight forward in jQuery. 

    My advice to the YUI evangelists is to see this as an opportunity to make the library better. I won’t disagree that YUI is a more advanced and even capable library, but it is often far too convoluted and involved when it comes to minor tasks. Perhaps YUI should consider adding an optional aliasing layer on top of the library to make the library more accessible to developers who don’t have super high level JavaScript experience.

    • 

      The majority of tasks NOW are more easily done…if I ever needed a definition of short-term thinking, this would be it. Why not use plain old Javascript for simple tasks and save the heavy lifting for YUI. The library already is better than jQuery

      • 

        At the end of the day the primary reason (in my opinion) that the switch happened is because the majority of developers have worked with and prefer jQuery. 

        This thread is the first indication I’ve ever encountered that people actually like to use YUI. I’m not just saying that to be a smart ass (although the bonus effect of it being interpreted that way is well how do you say… a bonus). 

        Almost any move that Sugar makes which will make it easier for me to develop for, and more importantly train others to develop for, Sugar makes sense to me.

        • 

          You are fixated on ease of development now instead of taking the longer term view, as if it where the only criterion by which a product like Sugar is judged. Sure , its an important consideration, but if the product is unable to continue deliver rich powerful user experiences or another library change is required to do so, bringing its associated pains, then what has been gained?

      • 

        I disagree. Mostly because people mix two big areas: DOM libraries and UI frameworks.

        In the DOM+Ajax+Anim library aspect I don’t think YUI is better than jQuery. http://jsrosettastone.com shows how similar they are. There are subtle differences in which some times one is a little more polished that the other. For example, jQuery recently made a big jump
        for the better in 1.7 with $(foo).on(). YUI’s API does have some duplication in CSS handling that’s hard to figure out (is it .get(‘offsetWidth’), .getStyle(‘width’) or .getComputedStyle(‘width’)?). And jQuery can stop being simple to use once you run into someone else’s code that abuses .end().

        If you use SimpleYUI, you pretty much have an equal to jQuery.

        Where YUI shines is in the UI framework area. YUI is more consistent, feature rich and handles i18n and accessibility. It now even has MVC for those who like it and renders in NodeJS.
        But none of these features apparently cater to Sugar’s community, so the change makes sense for them. As much as I’d love to turn this story around, I don’t see that happening, so instead I’d like to  insist with my previous questions so we can learn from this. Before deciding to switch, have you tried teaching members of your community and showing the advantages of your previous decision? If so, what reactions did you get? Concrete arguments and descriptions would help a lot finding in the path to improving the YUI learning curve. Also, what exactly where your pain points when developing a complex product with YUI? What are you getting from your new choice of tools that you didn’t have before? And finally, you mention a lot YUI2. Most YUI2 widgets are in the YUI Gallery now, made by the community. Have you looked at them? Did you consider using them in your product or did you just ignore them and went for 2in3?

        I’d be grateful for any concrete answers you can give and probably most of the members of the YUI community that posted here would be as well.

  8. 

    Very interesting design decision. Had your team given any thought to:

    1: Writing the common bits in plain idiomatic JavaScript.
    2: Providing thin wrappers for the popular libraries (jQuery, YUI3, Mootools, Dojo, etc.).

    Seems like it would make for a more strategic offering and mitigate any framework controversy.

  9. 

    FWIW – yui3 touch is baked in from the ground up. Try sliding the jquery slider on a touch device .. no touch support. 

  10. 

    UI frameworks aside… 

    I just love jquery core.  I need it all the time to select X and do Y to it.  ❤

    We still use YUI for it's DataGrid.  I think that's one of it's strong suits… but seems clunky to me.  All i know is my mood when dealing with YUI is not happy.  The examples and documentation just aggravate me and are never helpful.  JQuery I'm generally enjoying what i'm doing when i'm doing it. 

    An jquery theme builder is pretty amazing.  Perhaps YUI has improved since i used it last but it used to be you had one choice… you that blue SAM skin for everything.  Customizing it was basically impossible.

  11. 

    These are great news!
    Are you guys also including jQueryUI in the package? If not, why, and are you guys considering including in the near future?

  12. 

    Oh – Em – Gee. I thought I would be slick using YUI3 autocomplete bound to a name field, easy? I almost stuck to old faithful, jQuery and extend UI, but went the hard route as YUI3 is in the core.

Trackbacks and Pingbacks:

  1. TinyMCE in subpanel - June 25, 2012

    […] […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s