Bug Tracker

Opened 7 years ago

Closed 7 years ago

Last modified 6 years ago

#11015 closed enhancement (worksforme)

Integrate with Closure Compiler

Reported by: dmethvin Owned by: dmethvin
Priority: high Milestone: 1.8
Component: misc Version: 1.7.1
Keywords: 1.8-discuss Cc:
Blocked by: Blocking:

Description (last modified by dmethvin)

There are several steps to this, we can break them out later:

1) Work with the Closure Compiler team to ensure that CC can parse jQuery correctly and work with the ADVANCED_OPTIMIZATIONS option.

2) Update jQuery's style guide, code, and unit tests to ensure we'll be able to use CC going forward.

3) Create a style guide for plugin writers and jQuery developers to ensure their own code is CC-worthy. Perhaps we can add some indication of CC-worthiness at the plugins site?

4) Document critical dependencies that will hamper minimization, such as using ambiguous methods like .load() or .show() (see #10997).

5) Provide a tool to users that allows them to combine jQuery with their own plugins and code for best minimization.

It's unlikely this will all get done in 1.8 but we need to figure out where it goes on the roadmap.

Change History (11)

comment:1 Changed 7 years ago by dmethvin

Component: unfiledmisc
Keywords: 1.8-discuss added
Milestone: None1.8
Owner: set to dmethvin
Priority: undecidedhigh
Status: newassigned
Type: bugenhancement

comment:2 Changed 7 years ago by timmywil

Description: modified (diff)

+1, We should keep in mind this is only for power users. We should still be concerned about regular gzip size.

comment:3 Changed 7 years ago by mikesherov

+1

comment:4 Changed 7 years ago by Rick Waldron

Description: modified (diff)

+0

comment:5 Changed 7 years ago by jaubourg

Description: modified (diff)

-1, Size will grow and all users EXCEPT power users will suffer.

comment:6 Changed 7 years ago by dmethvin

Description: modified (diff)

Our current plan is to put CCAO in a branch based on the final 1.8. The team consensus is that the jsdoc comments and in particular the inline type annotations make the code much less readable. Some of the CCAO code changes may be pulled into master, but in total they are 200 bytes so it's unlikely we will pull them all in.

For this to progress further after 1.8, we will require community assistance to help maintain CCAO compatibility and provide help for users wanting to build their own projects with jQuery and CCAO (see the task list above). If there is sufficient interest and participation, we will consider further integration.

comment:7 Changed 7 years ago by joseprio

+1, I've been waiting for this capability for a long while, so it's great to see that it's in progress.

However, I think it's a mistake to put it on a separate branch, specially because of a 200 bytes size increase; in my opinion, a user that cares about 200 bytes increase will definitely consider using something ADVANCED_OPTIMIZATIONS to save kbs; in most scenarios, the websites only use a portion of the full JQuery functionality.

Also, if this is aimed at power users, I don't see the point of task #5; this process can be done with tools that already exist (i.e. Apache Ant), so maybe sample scripts would suffice, instead of reinventing the wheel.

comment:8 Changed 7 years ago by dmethvin

@joseprio, it's not just the 200 bytes, it is the increase in noise in the source code and an ongoing responsibility to maintain CCAO compatibility once we've merged it into master.

Any large JavaScript code base is not going to get that much smaller unless the entire thing can be compiled via CCAO. Having jQuery Core at that point is a good first step, but not very useful unless the user's own code, third-party jQuery plugins, jQuery UI, jQuery Mobile, Backbone.js, Ember.js, etc are also CCAO-safe.

If you and other CCAO users are interested in stepping up and maintaining / testing / documenting / evangelizing its use with jQuery 1.8 and the rest of the JavaScript ecosystem, we welcome it! That's the best way to guarantee that jQuery maintains CCAO compatibility into the future.

comment:9 Changed 7 years ago by dmethvin

Resolution: worksforme
Status: assignedclosed

I'm going to close this, we're on track to have a Closure Compiler branch that can be used for testing after 1.8 is released.

Wasn't quite sure how to set the resolution. It's ongoing.

comment:10 Changed 6 years ago by benjamin.j.mccann@…

Is there a Closure Compiler branch? I don't see it on GitHub. I'd probably help with it. I haven't used jQuery thus far because it's not compatible, but the API is nicer the Closure Library's so I would like to be able to use it.

comment:11 Changed 6 years ago by dmethvin

We're letting the Closure Compiler community lead this effort. Chad Killingsworth has done quite a bit over the past year but nobody else has stepped up to participate so there isn't much going on.

https://groups.google.com/forum/?fromgroups=#!searchin/closure-compiler-discuss/jquery/closure-compiler-discuss/IqLpcoU2BrE/15Hyhja6N2IJ

I'd start in their forum and see if anyone will help, then post followup discussion to our forum: http://forum.jquery.com/developing-jquery-core

You could start by creating a new externs file for 1.9 and 2.0 when they come out, I'm sure that would help since several APIs have been revised or changed. An upgrade guide will be available shortly and you'll see a blog post at blog.jquery.com when the 1.9 beta is released.

Note: See TracTickets for help on using tickets.