Skip to content
This repository has been archived by the owner on Nov 20, 2018. It is now read-only.

Remove jQuery wrappers #1310

Open
rnicholus opened this issue Oct 10, 2014 · 10 comments
Open

Remove jQuery wrappers #1310

rnicholus opened this issue Oct 10, 2014 · 10 comments

Comments

@rnicholus
Copy link
Member

The jQuery plug-in wrapper was first introduced in Fine Uploader 3.0 (#372). The original goal was to make it easy for those using jQuery to integrate Fine Uploader into their projects. A lot of developers (unfortunately) see jQuery and JavaScript as one in the same, so the name-recognition and ubiquitousness of jQuery in the front-end development world were also a compelling factor. Allowing the library to be (optionally) wrapped in a jQuery plug-in would appeal to those developers. The jQuery plug-in registry also made Fine Uploader more noticeable.

I have to admit, I used the jQuery plug-in wrapper myself for a while, and used it in internal projects developed by my employer that rely on Fine Uploader. Going forward, I'm no longer using this wrapper when I integrate Fine Uploader into other projects. Why? There aren't any real benefits, in my opinion.

It's awkward to deal with jQuery plug-ins (compared to a plain 'ole JavaScript interface). When calling an API method, you must pass the method name into the plug-in as a string, instead of simply calling the method on the object instance. Event/callback handlers must always include 'Event' as the first parameter (I can't tell you how many integrators have been bitten by this requirement). And nothing is gained by using event handlers in jQuery, since the events do not bubble due to the fact that Fine Uploader's jQuery wrapper uses triggerHandler to trigger events (required to ensure the handler's return value is available to internal code).

I'm personally not using jQuery myself in future projects, as I feel it is less needed due to the prominence of more modern browsers, and fact that IE8 and older are dying off. Quite frankly, I don't have much use for jQuery anymore, as I tend to only target modern browsers in my new projects. I feel this is going to be a more common philosophy among other developers over time as well.

On top of all of this, the fate of jQuery's plug-in registry seems to be in question. It looks like plug-in updates from today and most of yesterday are not present on the registry. The registry's GitHub repo has a recent issue opened by Dave Methvin, discussing the future of the registry. Partially due to the apparent prompting of Addy Osmani, the registry's days may be numbered. NPM will be the likely avenue for distributing plug-ins in the future.

So, due to everything listed above, and the complication of maintaining, testing, building, and curating documentation for the jQuery syntax required, I vote that we remove the plug-in wrapper and everything jQuery-related from a future build of Fine Uploader. I really don't think anyone will miss it. Note that this won't stop anyone from using Fine Uploader in a project that depends on jQuery. That will still be just as possible as it always was.

This also pertains to the jQuery wrapper for the standalone drag & drop module.

@rnicholus
Copy link
Member Author

Note that the jQuery plug-in registry was taken down a couple days ago. I take this as confirmation that the registry is dead.

Just to reiterate a bit, while it is clear jQuery is still used in many web sites/applications, I feel that this trend will not continue as the Web API evolves. Also, and most important, wrapping the library in a jQuery plug-in doesn't have any obvious benefits for users of the library, and in fact makes integration more complicated and awkward.

@PaulParker
Copy link

I agree with your thoughts about jQuery plugins. However, I don't really want to re-write and re-test all my fine uploader-related code at this point. It's important for us to be able to keep up with the fine uploader updates (there have been a number of important ones in V5 alone), and with this breaking change we'll have to rewrite a bunch of stuff in order to stay current.

@rnicholus
Copy link
Member Author

@PaulParker There shouldn't really be any rewriting involved if we were to remove the jQuery plug-in wrapper. There are only a few adjustments you'll need to make, at most (possibly only 1 or 2 in reality):

Constructing

Instead of $('#fineUploaderContainer').fineUploader({...});, you'll need to construct like this:

new qq.FineUploader({
   element: $('#fineUploaderContainer)[0],
   ...
});

Passing elements into Fine Uploader's API

You'll need to pass in an HTMLElement instead of a jQuery object. So, just add a [0] to the end of all portions of your code that construct a jQuery object that interfaces directly with Fine Uploader. For example, if you are setting the button option now as button: $('#myButton), you would simply change this to button: $('#myButton')[0].

Callbacks

If you are using jQuery event handlers for Fine Uploader events/callbacks, you'll need to refactor a small amount of logic.

For example, the jQuery way:

$('#myFineuploaderContainer').on('complete', function(event, id, name, response, xhr) {
   ...
});

Without relying on jQuery event handlers, you'll declare your callback handlers during construction, like this:

new qq.FineUploader({
   callbacks: {
      onComplete: function(id, name, response, xhr) {
         ...
      }
});

The latter approach is recommended over jQuery event handlers anyway. Why? Well, it's more intuitive and efficient. You can (and should) be using the 2nd approach now, even if you are using the jQuery plug-in wrapper.

API calls

The jQuery way looks like this: $('#myFineuploaderContainer').fineUploader('getName', fileId);. Pretty awkward, IMHO.

The native JavaScript way looks like this: uploader.getName(fileId);. I really prefer this syntax. The jQuery syntax is odd and unnecessary.

In the long run, no longer depending on jQuery is a good thing for everyone. When you look at jQuery critically and compare it with what's already provided by the Web API in modern browsers and other micro libraries, jQuery seems unnecessary.

@PaulParker
Copy link

Ok, thanks for the detailed response. I'll take a look at the the things you mentioned.

Thanks,
Paul Parker

On Nov 2, 2014, at 1:55 PM, Ray Nicholus notifications@github.com wrote:

@PaulParker There shouldn't really be any rewriting involved if we were to remove the jQuery plug-in wrapper. There are only a few adjustments you'll need to make, at most (possibly only 1 or 2 in reality):

Constructing

Instead of $('#fineUploaderContainer').fineUploader({...});, you'll need to construct like this:

new qq.FineUploader({
element: $('#fineUploaderContainer)[0],
...
});
Passing elements into Fine Uploader's API

You'll need to pass in an HTMLElement instead of a jQuery object. So, just add a [0] to the end of all portions of your code that construct a jQuery object that interfaces directly with Fine Uploader. For example, if you are setting the button option now as button: $('#myButton), you would simply change this to button: $('#myButton')[0].

Callbacks

If you are using jQuery event handlers for Fine Uploader events/callbacks, you'll need to refactor a small amount of logic.

For example, the jQuery way:

$('#myFineuploaderContainer').on('complete', function(event, id, name, response, xhr) {
...
});
Without relying on jQuery event handlers, you'll declare your callback handlers during construction, like this:

new qq.FineUploader({
callbacks: {
onComplete: function(id, name, response, xhr) {
...
}
});
The latter approach is recommended over jQuery event handlers anyway. Why? Well, it's more intuitive efficient. You can (and should) be using the 2nd approach now, even if you are using the jQuery plug-in wrapper.

API calls

The jQuery way looks like this: $('#myFineuploaderContainer').fineUploader('getName', fileId);. Pretty awkward, IMHO.

The native JavaScript way looks like this: uploader.getName(fileId);. I really prefer this syntax. The jQuery syntax is odd and unnecessary.

In the long run, no longer depending on jQuery is a good thing for everyone. When you look at jQuery critically and compare it with what's already provided by the Web API in modern browsers and other micro libraries, jQuery seems unnecessary.


Reply to this email directly or view it on GitHub.

@rnicholus
Copy link
Member Author

I've started writing a series of blog posts that will hopefully be of use for those who want to move away from jQuery. There are a couple posts already, and I have specific topics I plan to cover in additional posts over time. Maybe this will be of some use to Fine Uploader users.

@andrew-kzoo
Copy link
Contributor

I appreciate your thoughtful blog posts @rnicholus! 👍

@andrewk
Copy link

andrewk commented Jan 14, 2015

Removal of the jQuery wrappers prior to shipping a packaged module (AMD, CJS, ES6, UMD.. i don't care which) would be a bad move. Currently the only way we can use Fine Uploader at all with Webpack is by using the jQuery plugin. This is due to FU's var qq = declaration, and the assumption that the code will be executed at window scope. Remove jQuery, but please do it the release after you fix one of these -https://github.com/FineUploader/fine-uploader/issues?q=is%3Aissue+AMD

@rnicholus
Copy link
Member Author

No worries. There are no specific plans to move forward with this in a near-future release. It's possible that we will never remove the jQuery wrappers, in fact. We'll probably take other actions (such as emphasizing the vanilla JS API/syntax over the jQuery one) long before we even consider tackling this case.

I agree that AMD/ES6 module/UMD support is much more important.

rnicholus added a commit that referenced this issue Apr 9, 2015
...in favor of vanilla JS and Fine Uploader's helper functions.

#1310
@rnicholus rnicholus added this to the 6.0.0 milestone Sep 30, 2015
@rnicholus
Copy link
Member Author

Plan is to remove the jQuery wrappers in Fine Uploader 6.0, provided CommonJS/ES6 module support is completed as well.

@rnicholus
Copy link
Member Author

CommonJS support is set to be released in 5.8.0 (in progress). See #1562 for details.

@rnicholus rnicholus removed the 5 - Done label Feb 7, 2017
rnicholus added a commit that referenced this issue Feb 7, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
4 participants