Remove usages of jquery and add sugar.js from garden-o-matic.

Remove usages of jquery and add sugar.js from garden-o-matic.

Use sugar.js to replace usages of jquery and replace any extraneous
uses as well. Didn't touch the custom event stuff (bind/trigger) or
the tabs UI code. Those will naturally go away as we port things to
polymer. Kept this patch for mechanical simple changes.

The only non-mechanical bits are $.param --> base.queryParam and
fadeIn/fadeOut --> element.animate.

NOTRY=true

Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=177188

[ojan, 2014-06-30 04:15:41]

This patch is big. I can split it up if you want. But it's almost entirely
mechanical changes and it's not *that* big if you collapse the sugar.js file.

The tests pass and I did manual verification that things still worked as I went.

[abarth-chromium, 2014-06-30 04:26:03]

LGTM

https://codereview.chromium.org/359283003/diff/60001/Tools/GardeningServer/sc...
File Tools/GardeningServer/scripts/garden-o-matic.js (right):

https://codereview.chromium.org/359283003/diff/60001/Tools/GardeningServer/sc...
Tools/GardeningServer/scripts/garden-o-matic.js:107:
window.addEventListener('load', function() {
ready -> DOMContentLoaded, right?

https://codereview.chromium.org/359283003/diff/60001/Tools/GardeningServer/sc...
File Tools/GardeningServer/scripts/summary-mock.js (right):

https://codereview.chromium.org/359283003/diff/60001/Tools/GardeningServer/sc...
Tools/GardeningServer/scripts/summary-mock.js:148:
window.addEventListener('load', function() {
ditto

https://codereview.chromium.org/359283003/diff/60001/Tools/GardeningServer/sc...
File Tools/GardeningServer/scripts/ui/notifications.js (right):

https://codereview.chromium.org/359283003/diff/60001/Tools/GardeningServer/sc...
Tools/GardeningServer/scripts/ui/notifications.js:58: }.bind(this));
What's the point of using requestAnimationFrame?  Can't we just program the
animation?

https://codereview.chromium.org/359283003/diff/60001/Tools/GardeningServer/sc...
File Tools/GardeningServer/scripts/ui/results.js (left):

https://codereview.chromium.org/359283003/diff/60001/Tools/GardeningServer/sc...
Tools/GardeningServer/scripts/ui/results.js:181: // FIXME: Use addEventListener
once WebKit adds support for mouseleave/mouseenter.
Did that happen?

https://codereview.chromium.org/359283003/diff/60001/Tools/GardeningServer/ui...
File Tools/GardeningServer/ui/ct-sheriff-o-matic.html (left):

https://codereview.chromium.org/359283003/diff/60001/Tools/GardeningServer/ui...
Tools/GardeningServer/ui/ct-sheriff-o-matic.html:7: <script
src="https://ajax.googleapis.com/ajax/libs/jquery/1.6.2/jquery.min.js"></script>
\o/

[ojan, 2014-06-30 04:49:59]

https://codereview.chromium.org/359283003/diff/60001/Tools/GardeningServer/sc...
File Tools/GardeningServer/scripts/garden-o-matic.js (right):

https://codereview.chromium.org/359283003/diff/60001/Tools/GardeningServer/sc...
Tools/GardeningServer/scripts/garden-o-matic.js:107:
window.addEventListener('load', function() {
On 2014/06/30 04:26:03, abarth wrote:
> ready -> DOMContentLoaded, right?

Ah. I didn't realize that. Done.

https://codereview.chromium.org/359283003/diff/60001/Tools/GardeningServer/sc...
File Tools/GardeningServer/scripts/ui/notifications.js (right):

https://codereview.chromium.org/359283003/diff/60001/Tools/GardeningServer/sc...
Tools/GardeningServer/scripts/ui/notifications.js:58: }.bind(this));
On 2014/06/30 04:26:03, abarth wrote:
> What's the point of using requestAnimationFrame?  Can't we just program the
> animation?

It didn't work to do it synchronously. I didn't feel like digging in to
understand why as this code will probably just become a regular CSS animation
when we port this to polymer. Will add a FIXME though.

https://codereview.chromium.org/359283003/diff/60001/Tools/GardeningServer/sc...
File Tools/GardeningServer/scripts/ui/results.js (left):

https://codereview.chromium.org/359283003/diff/60001/Tools/GardeningServer/sc...
Tools/GardeningServer/scripts/ui/results.js:181: // FIXME: Use addEventListener
once WebKit adds support for mouseleave/mouseenter.
On 2014/06/30 04:26:03, abarth wrote:
> Did that happen?

As best I can tell it did. I tested it in plexode before changing this code.

[ojan, 2014-06-30 04:52:44]

The CQ bit was checked by ojan@chromium.org

[commit-bot: I haz the power, 2014-06-30 04:53:07]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/ojan@chromium.org/359283003/100001

[commit-bot: I haz the power, 2014-06-30 05:11:22]

Change committed as 177188

[Dirk Pranke, 2014-06-30 21:24:49]

This change seems problematic to me (sorry!)

1) I'm not really sure why we're switching from jquery to sugar. I'm not at all
familiar w/ sugar, so ... do we need things that sugar provides that the
platform doesn't and that jquery doesn't? I would say that jquery is not small
and has a bunch of stuff we don't need, but if sugar is 7800 lines of code, it's
not small either?

2) We're not allowed to check third_party code into arbitrary parts of the tree,
even if it has the right license (which sugar, being MIT, does). We have to
follow a little more bureaucracy.

See http://www.chromium.org/developers/adding-3rd-party-libraries .

At the very least, you need to create a couple other files to track where we got
sugar.js from, and it needs a third-party OWNER review. Given that
garden-o-matic is a standalone tool and it doesn't really make sense to try and
pull a single file from src/third_party or some such thing, it's probably okay
to create the third_party dir under Tools/GardeningServer as you've done, but
since I'm not a third-party OWNER, we need to get someone else to approve this,
too.

[esprehn, 2014-06-30 22:44:41]

On 2014/06/30 at 21:24:49, dpranke wrote:
> This change seems problematic to me (sorry!)
> 
> 1) I'm not really sure why we're switching from jquery to sugar. I'm not at
all familiar w/ sugar, so ... do we need things that sugar provides that the
platform doesn't and that jquery doesn't? I would say that jquery is not small
and has a bunch of stuff we don't need, but if sugar is 7800 lines of code, it's
not small either?

jQuery doesn't understand Shadow DOM or Polymer, it also leads to really messy
DOM mutation code that you should never be doing once you're using polymer
properly. We need to get rid of jQuery, Polymer + Sugar is the future.

> 
> 2) We're not allowed to check third_party code into arbitrary parts of the
tree, even if it has the right license (which sugar, being MIT, does). We have
to follow a little more bureaucracy.

Lets just add a bower dep for sugar in bower.json instead. There's no reason to
check this in at all.

[ojan, 2014-07-01 02:45:51]

On 2014/06/30 at 22:44:41, esprehn wrote:
> On 2014/06/30 at 21:24:49, dpranke wrote:
> > This change seems problematic to me (sorry!)
> > 
> > 1) I'm not really sure why we're switching from jquery to sugar. I'm not at
all familiar w/ sugar, so ... do we need things that sugar provides that the
platform doesn't and that jquery doesn't? I would say that jquery is not small
and has a bunch of stuff we don't need, but if sugar is 7800 lines of code, it's
not small either?
> 
> jQuery doesn't understand Shadow DOM or Polymer, it also leads to really messy
DOM mutation code that you should never be doing once you're using polymer
properly. We need to get rid of jQuery, Polymer + Sugar is the future.

The concern isn't code size. It's functionality. Sugar does give some things
that the platform doesn't provide (e.g. Object.keys, String.pluralize, etc).
Some of it happens to overlap with jQuery. Unlike jQuery though it doesn't
encourage coding practices that we're trying to avoid (e.g. string-based DOM
creation, a magic global object, etc).

Sugar does have some bloat that we certainly don't need (e.g. String.zenkaku),
but it doesn't really cost us anything than a small number of bytes over the
network.

> > 2) We're not allowed to check third_party code into arbitrary parts of the
tree, even if it has the right license (which sugar, being MIT, does). We have
to follow a little more bureaucracy.
> 
> Lets just add a bower dep for sugar in bower.json instead. There's no reason
to check this in at all.

Sure. I was just cargo-culting the codereview tool