This repository has been archived by the owner. It is now read-only.

Discussion: pure-js (2.x) vs. jquery-js (3.x) #326

Closed
rentalhost opened this Issue Sep 12, 2012 · 50 comments

Comments

Projects
None yet
8 participants
@rentalhost

rentalhost commented Sep 12, 2012

I make this topic to discuss about the pure-js ans jquery-js version of library.

Supposedly will exists two versions of Fine Uploader:

  • 2.x will be pure-js
  • 3.x will be jquery-compatible

My opnion is not do that. Will be maintenance be extremally hard and could create inconsistencies between versions. My suggestion is create a pure-js API and a wrapper in jQuery (all will be 3.x version).

For instance:

var up = qq.FileUpload(x);
var up = jQuery.FileUpload(x); // -> call qq.FileUpload(x)

Events, methods and vars need be the same to both.

Files can be:

  • fileuploader.js
  • jquery-fileuploader.js (requires fileuploader.js)
  • prototype-fileuploader.js (requires fileuploader.js) -- for instance

The desvantages will be couldn't use jQuery helpers. But can be create an advanced solution for that in files. For instance:

  • fileuploader.js (full version, core + helpers)
  • fileuploader-helpers.js (helpers only file, if you don't uses jQuery)
  • fileuploader-core.js (core only file)
  • jquery-fileuploader.js (requires fileuploader-core.js only)

Or an include once, in build process.

  • fileuploader.js (full version, core + helpers version)
  • jquery-fileuploader.js (core + jQuery wrapper version)

So you need include only one version.

@walterdavis

This comment has been minimized.

walterdavis commented Sep 12, 2012

This is a very neat solution. I like it a lot!

@rnicholus

This comment has been minimized.

Member

rnicholus commented Sep 12, 2012

To be honest, this sounds like more of a maintenance nightmare than my initial proposal, and it doesn't solve any of the problems that would be solved by moving entirely to jQuery. My plan is to eventually phase out the "native js" Fine Uploader. Why? Because it is much easier and faster to evolve the product using a library like jQuery, along with all of the available plug-ins (including jQuery-UI). The existing "native js" Fine Uploader will remain, but will not evolve after a point in the near future. I will continue to fix critical bugs in this version, but new feature development will eventually happen in the jQuery version. I realize that not everyone will be happy with this, but I expect most users will appreciate the move to jQuery. I know I will. If someone, for whatever reason, does not want to depend on jQuery, they will be able to use the non-jQuery version. It's not going away, it just won't evolve.

I noticed you referenced Prototype. I have used Prototype in the past, and have no plans to write anything using Prototype by choice in the future. Prototype's decision to extend the DOM was a poor one. jQuery's choice to wrap the DOM, instead, was a good one. Putting that aside, jQuery has a huge amount of plug-ins, and many more users by comparison.

@rentalhost

This comment has been minimized.

rentalhost commented Sep 12, 2012

I agree totally with you. But I had understood that will have two versions (pure and jQuery). If you will develop only jQuery, I think that is better! I'm a jQuery user too and I think too great you develop for it.

There are some pure-js upload libraries on internet, so users will have two option: use it or use 2.x version (with fewer features).

@rnicholus

This comment has been minimized.

Member

rnicholus commented Sep 12, 2012

Well, there will be two versions. However, the 2.x version will be considered a "legacy" version of Fine Uploader. I'll maintain it, at least for a while, by patching it with critical bugfixes. The 3.x version will be the jQuery re-write version, and will be considered the main version where new features will be added. It's going to take a little while to get the 3.x (jQuery) version into a usable state since I haven't started on it yet and I will be doing this in my free time. Initially, 3.x will be in a beta phase until all major issues have been worked out. Once it is "released", the 2.x version will go into a legacy-sustaining mode, and new feature development/evolution will only occur in 3.x.

Once 3.x is out of beta, users can continue to choose the 2.x version, but feature requests will not be honored. At some point, the 2.x version may be EOLed altogether.

Does this make sense?

@rentalhost

This comment has been minimized.

rentalhost commented Sep 12, 2012

Perfectly!

@rentalhost rentalhost closed this Sep 12, 2012

@rnicholus rnicholus reopened this Sep 13, 2012

@ghost ghost assigned rnicholus Sep 13, 2012

@emanwebdev

This comment has been minimized.

emanwebdev commented Sep 19, 2012

there are numerous jQuery uploaders available

while...

your pure-js is the only one! Keep the good work and uniqueness of your solution!!!

@rnicholus

This comment has been minimized.

Member

rnicholus commented Sep 19, 2012

I would expect most users to be more concerned with features, support,
reliability, and ease-of-use over the uniqueness of the codebase.
On Sep 19, 2012 5:18 AM, "Emmanuel" notifications@github.com wrote:

there are numerous jQuery uploaderes available

while...

your pure-cs is the only one! Keep the good work and uniqueness of your
solution!!!


Reply to this email directly or view it on GitHubhttps://github.com/valums/file-uploader/issues/326#issuecomment-8686593.

@reinink

This comment has been minimized.

reinink commented Sep 19, 2012

@rnicholus Agreed...and while there are lots of jQuery uploaders available, this one really is the best I have come across.

Honestly, the only reason I could see you moving to a jQuery plugin version is to increase it's popularity. I think there are lots of developers who will be searching for a jQuery uploader—even though this uploader (in it's current state) works perfectly fine. They know jQuery, and they know how jQuery plugins work. I think it's all a little ridiculous...but that's the way it is.

Moreover, my two cents on version three. Whatever new features you add, please keep FileUploaderBasic in its current state more-or-less. FileUploaderBasic is really what attracted me to this file uploader. I personally want control over the UI. Give me callbacks to work with. Too many other uploaders create big, complex interfaces, which can be really difficult to implement into your unique software application.

Keep up the good work!

@rnicholus

This comment has been minimized.

Member

rnicholus commented Sep 19, 2012

@reinink I'm not sure FileUploaderBasic will exist in 3.0 as you know it now. However, my goal is to make 3.0 as flexible as possible, so that users can use their own upload button, their own file list, their own css, or choose to omit one or more of these items and simply rely on callbacks. Please see the google doc referenced in the readme on master if you would like to specify features/considerations for me to take into account when developing 3.0.

@reinink

This comment has been minimized.

reinink commented Sep 19, 2012

@rnicholus I'm not opposed to one plugin, as long as we have the control available now. I get the need for some of this functionality to be built in—as long as it doesn't get too big or too complicated to remove all that stuff.

Put differently, I'd love version three to not require any assets (CSS, images)—just the JavaScript file.

@rnicholus

This comment has been minimized.

Member

rnicholus commented Sep 19, 2012

I can certainly put that into my TODO list when developing 3.0 (which has
already started, though i haven't done much at all yet). Could you please
codify this request and any others in this spreadsheet, if possible?
https://docs.google.com/spreadsheet/ccc?key=0AnQh9-ZBDuh_dEJGZFY1dEl2SDlGUGZNLUVfanZKeXc#gid=0

On Wed, Sep 19, 2012 at 1:11 PM, reinink notifications@github.com wrote:

@rnicholus https://github.com/rnicholus I'm not opposed to one plugin,
as long as we have the control available now. I get the need for some of
this functionality to be built in—as long as it doesn't get too big or too
complicated to remove all that stuff.

Put differently, I'd love version three to not require any assets (CSS,
images)—just the JavaScript file.


Reply to this email directly or view it on GitHubhttps://github.com/valums/file-uploader/issues/326#issuecomment-8700698.

@reinink

This comment has been minimized.

reinink commented Sep 19, 2012

@rnicholus Done. ;)

@rnicholus

This comment has been minimized.

Member

rnicholus commented Sep 19, 2012

@reinink I should add that the main reason I would move to jQuery is not to increase its popularity, but to make it easier to maintain and add features. Relying on a library like jQuery allows me to remove a lot of noise from the code, that is, functions that jQuery already provides. The help that jQuery provides in terms of cross-browser support and helper functions, to name a couple, make it very compelling to move in that direction.

@reinink

This comment has been minimized.

reinink commented Sep 19, 2012

@rnicholus Makes good sense to me!!!

@emanwebdev

This comment has been minimized.

emanwebdev commented Sep 20, 2012

Moving to jQuery? so you are heading to a clone of the http://blueimp.github.com/jQuery-File-Upload/ ?
or similar to its basic plugin version (https://github.com/blueimp/jQuery-File-Upload/wiki/Basic-plugin)
Why to re-do what already exists?

What about solutions that don't want to rely on the fat jQuery?

@rnicholus

This comment has been minimized.

Member

rnicholus commented Sep 20, 2012

@emanwebdev Just because the uploader is written in jQuery, does not mean that it must be a clone of some other uploader also written in jQuery. To put it simply, as I've stated in this case many times already, the product will be more difficult to evolve if we do not add a crutch, such as jQuery, to the codebase. Code that does not evolve eventually dies. Also, as I have already noted in this case, the non-jquery version will still exist, but it will eventually be in a bugfix-only mode.

I don't plan on cloning anything. The 3.0 version will be a port of the existing features found in Fine Uploader 2.0 to a jQuery plug-in, along with a host of other features, some of which are listed in the google doc referenced in the readme.

Why are you opposed to including jQuery in your source code? The minified version is 93 KB and this file can be cached more easily if we rely on a CDN.

@rnicholus

This comment has been minimized.

Member

rnicholus commented Sep 20, 2012

I've created a poll to see what interested users think.

@rentalhost

This comment has been minimized.

rentalhost commented Sep 20, 2012

Maybe my first suggestion be a good thing. Create a pure-js (core) version and a jQuery bind. User can choice between both versions. jQuery only will use the core, instead of define structures.

jQuery.fn.FileUpload = function() {
  return new FileUpload();
}

All events need be similar to jQuery, like FileUpload.on('eventName', callback).

@rnicholus

This comment has been minimized.

Member

rnicholus commented Sep 20, 2012

@david-proweb Unless I am misunderstanding, you are suggesting that the core code will not be written in jQuery, which defeats the purpose of using jQuery at all, IMHO. I'm not fond of adding more complexity to the project by creating these types of wrappers.

@rentalhost

This comment has been minimized.

rentalhost commented Sep 20, 2012

Yeah, basically. The difference is that your project will be compatible with pure-js and jquery users. You don't will have too much difficulty. Basically you need to work with four files, like I suggest before.

  1. core: will contains all core (FileUpload class, for instance);
  2. helper: will contains all helpers, need to core;
  3. shared: will contains all helpers that is not found in jQuery, need to core;
  4. jquery-wrapper: will contains all helpers (of jQuery, obvious) and the jQuery wrapper;

So, when you build, you will have only two files:

  1. pure version: core + helper + shared;
  2. jquery version: core + shared + jquery-wrapper;

Another advantage is: you can create more wrappers (to prototype, for instance):

  1. prototype version: core + helper + shared + prototype-wrapper -- note the helper, it'll be need to wrapper, once that you only will accept jquery-helpers. It'll turn development easy;

So, the helper will be used if jQuery doesn't exists. You need only replicate jQuery task (in simplied form) if it is really need. For instance: if you need jQuery.ajax, you need create your own jQuery.ajax, but simplified (only with the features that you really will use). Yeah! It's the complicated part!

The shared file will be used to declare functions that is not found with pure js or in jQuery helpers, like... hum... Shared.fileChunker(file, size), for instance.

@rnicholus

This comment has been minimized.

Member

rnicholus commented Sep 20, 2012

@david-proweb If I am going to re-write the app using jQuery, the most benefit is received from rewriting core using jQuery. If the majority of users vote to not go the jQuery route in the poll, I may consider your idea, but, even without a wrapper, it is trivial for non-jQuery users to integrate Fine Uploader into their application. I am actually doing this now with several of the projects I am working on. I'm just not sure it's worth the trouble to write wrappers.

@walterdavis

This comment has been minimized.

walterdavis commented Sep 20, 2012

But if you rewrite the core to depend on jQuery, you make it nearly impossible to use in a non-jQuery environment. Believe it or not, those do exist.

It's not about the file size of jQuery + FU3 vs file size of a monolithic FU3 that we're concerned with here either. It's a need to make elements that are library-agnostic so they can cooperate with whatever existing code-base they find themselves in.

I completely understand the argument to incorporate a library -- to spackle over all the many divots in the various JS implementations on browsers and operating systems and major and minor versions of same. That's a noble thing that the librarians do for us -- I get that.

But not everybody gets to choose their library, and not every application that could benefit from this uploader will be compatible with jQuery.

Walter

On Sep 20, 2012, at 5:05 PM, Ray Nicholus wrote:

@david-proweb If I am going to re-write the app using jQuery, the most benefit is received from rewriting core using jQuery. If the majority of users vote to not go the jQuery route in the poll, I may consider your idea, but, even without a wrapper, it is trivial for non-jQuery users to integrate Fine Uploader into their application. I am actually doing this now with several of the projects I am working on. I'm just not sure it's worth the trouble to write wrappers.


Reply to this email directly or view it on GitHub.

@emanwebdev

This comment has been minimized.

emanwebdev commented Sep 20, 2012

Just because the uploader is written in jQuery, does not mean that it must be a clone of some other uploader also written in jQuery.
I don't plan on cloning anything.

ooops, sorry for having used the word clone Take it easy. Just my poor english :)

Also, as I have already noted in this case, the non-jquery version will still exist, but it will eventually be in a bugfix-only mode.

Right, I've read that in the meantime. Ok then. Great! MANY Thanks coz good pure-js uploaders are v. seldom!

Why are you opposed to including jQuery in your source code? The minified version is 93 KB and this file can be cached more easily if we rely on a CDN.

Coz some projects come WITHOUT jQuery. External specs aso.

@rentalhost

This comment has been minimized.

rentalhost commented Sep 20, 2012

Well... Let consider that exists a lot of jQuery, Prototype, MooTools, ... If user prefer use Prototype, they need search a Prototype compatible. Same to jQuery.

If you are a jQuery developer, I think that you need create it only for jQuery. You don't will rebuild the wheel, just will make it like you think. Just not abandon the project. Follow your ideas to not abandon it by disinterest. I abandoned some projects because I think in all people of the world, and not only in a specific group of peoples (including me).

Users that work with pure-js can have two motives: 1. is a starter and probably not will work with uploads. 2. don't know frameworks. Hard users/real developers prefer jQuery, Prototype or MooTools (etc), so it need search a library for your work.

So, my final opinion: make it for jQuery!

@emanwebdev

This comment has been minimized.

emanwebdev commented Sep 20, 2012

So, my final opinion: make it for jQuery!

... but you wrote too:

You don't will rebuild the wheel

and jQ uploaders are already here,
so why spend energy & time to rebuild the wheel instead of improving this brilliant pure-js uploader????

@rnicholus

This comment has been minimized.

Member

rnicholus commented Sep 20, 2012

@walterdavis As I've said, if I go ahead w/ 3.0, the non jQuery-version will still be available, and serious bugs will be patched in this branch after 3.0 is released, but there are compelling reasons to not re-invent the wheel in the codebase and let a library like jQuery make evolution of the product easier.

I'll look at the results of the poll after a few days and see what users as a whole think before I spend more time on a 3.0/jQuery version of Fine Uploader.

@rnicholus

This comment has been minimized.

Member

rnicholus commented Sep 20, 2012

Quite a lively conversation here. Never thought this would be so controversial. 😏

@h3

This comment has been minimized.

h3 commented Sep 23, 2012

Maybe I'm missing some things, but here's what I'd do.

  1. Core js uploader becomes a low level API
  2. A native js uploader client which extends the core can be created
  3. A jQuery (or any other framework) js uploader client can be created

As far as I'm concerned, the jQuery (Prototype or whatever) wrapper can even be an external project. And it probably should. It doesn't matter if the wrappers features are not harmonized. The only thing important is that they don't alter the low level API.

And yes jQuery is popular and everyone loves it (including me). But technology moves fast and even the most popular technologies are eventually supplanted. Native JS is not going away any time soon. For this simple reason, you should not tie the core to a specific framework.

And of course jQuery (or any other JS framework) could ease the maintenance of this project and slim down its code base a lot. But overall, the benefits ends there. And there is still a maintenance cost to use a framework, because frameworks API change a lot more than native JS.

TL;DR: Frameworks should use your code, not the other way around.

My 2¢

@rnicholus

This comment has been minimized.

Member

rnicholus commented Sep 23, 2012

@h3 It really doesn't make much sense to me to re-write fine uploader in native javascript. I imagine I'd end up writing pretty much the same code we have now. To say that the benefits end at easing maintenance and evolution of the product along with reducing noise in the code is like saying the benefits of bypass surgery end at the years of life the procedure adds to a patient's life. If you think about it, that is a very apt analogy.

As far as the cost of using a framework such as jQuery, the API really has not changed very much at all since its inception. Sure, functions have been added, and others have been deprecated, but very few breaking changes have occurred in quite some time. You mention that native JS is not going away anytime soon, but you haven't really defined native JS. What is native JS exactly? ECMAScript has undergone several revisions. Will the newest planned revision, Harmony, be fully backwards compatible, syntax-wise? Who knows. This is, perhaps an argument for using a framework like jQuery. Perhaps the layer of abstraction jQuery provides will shield javascript developers from any breaking changes once Harmony becomes a reality.

@cleer73

This comment has been minimized.

cleer73 commented Sep 23, 2012

@rnicholus I think you are missing the point about keeping the upload library as stand alone product. My problem is having this code base tied to some other code base, that your project has no control over. Also, I HATE jQuery UI, it is a bloated pile of crap, which is sad since jQuery itself is amazing. But that's all fine, I can just fork it for myself.

Good luck.

@rnicholus

This comment has been minimized.

Member

rnicholus commented Sep 23, 2012

Hmm, i don't recall saying i was going to use jquery ui.
On Sep 23, 2012 1:08 PM, "Jacob Lee" notifications@github.com wrote:

@rnicholus https://github.com/rnicholus I think you are missing the
point about keeping the upload library as stand alone product. My problem
is having this code base tied to some other code base, that your project
has no control over. Also, I HATE jQuery UI, it is a bloated pile of crap,
which is sad since jQuery itself is amazing. But that's all fine, if you
decide to screw this project royally I can just fork it for myself.

Good luck.


Reply to this email directly or view it on GitHubhttps://github.com/valums/file-uploader/issues/326#issuecomment-8800977.

@cleer73

This comment has been minimized.

cleer73 commented Sep 23, 2012

I may have picked that up from someone else's comment, sorry about that.

@rnicholus

This comment has been minimized.

Member

rnicholus commented Sep 23, 2012

@cleer73 No problem, but I should say that I don't really appreciate your original comment, that you have since removed. Please keep in mind that this is not a commercial product, I am not paid to do this. I maintain and evolve this in my spare time since I use and like this library. I also want to make the best decision for Fine Uploader to ensure that it is useful and appreciated for as long as possible. I don't intend to take the project in a direction that most users object to. This is why I have kept this discussion open and have created a poll. My mind is not made up yet regarding the future of Fine Uploader. I'd like to make a decision that everyone will like, but that is usually not possible. I also want to ensure that maintenance and development of this product does not consume more time than I have. I see introducing jQuery as a way to streamline future development and maintenance of this library.

@rnicholus

This comment has been minimized.

Member

rnicholus commented Sep 23, 2012

@cleer73 Looks like I may have referenced jQuery I in a couple places. Such as here and here, but rest assured I really would like to avoid introducing any dependencies other than jQuery. While jQuery UI has a couple plug-ins that would be useful, such as DnD and sortable, I think it would be easy enough to support these behaviors w/out introducing another dependency.

@cleer73

This comment has been minimized.

cleer73 commented Sep 23, 2012

@rnicholus I agree, and that is why I revised it, I realized it was snarky and inappropriate. I am sorry for that, very.

I appreciate that this is a spare time project for you. I hope that you make the very best decisions for you self and the project. And while satisfying everyone is a noble goal, it's really almost impossible.

That said, have you considered using Sizzle.js to stop maintaining your own DOM functions (I am guessing this is why the jQuery move is on the table). I believe this is what the jQuery project uses for there own CSS selections, and I am pretty sure it was started by John Resig to solve a problem of his own.

http://sizzlejs.com/

@rnicholus

This comment has been minimized.

Member

rnicholus commented Sep 23, 2012

@cleer73 Yes, using sizzle would certainly give me an advantage as far as element selection is concerned. You're right, BTW: Sizzle was developed by Resig and is now the selector engine for jQuery. Strangely enough, Prototype uses sizzle as well (1.7+).

As I mentioned, using sizzle would aid in element selection, but I don't gain any of the other advantages that jQuery offers, such as events, DOM manipulation, DOM traversal, ajax support, effects, and other utilities (such as data(), each(), extend(), etc). I tend to think that some of these elements of jQuery will be useful to me.

@rnicholus

This comment has been minimized.

Member

rnicholus commented Sep 23, 2012

Another option is to use jQuery inside of Fine Uploader code, but not implement it as a jQuery plug-in. jQuery would still be a required dependency, though. Users who do not want to write any jQuery code would not have to. Also, the use of jQuery would be completely internal and transparent to users of Fine Uploader.

Perhaps a jQuery plug-in could also exist that wraps Fine Uploader (again, Fine Uploader core would be written using jQuery). This wrapper would allow those who choose to use it the ability to register for events, pass in jQuery objects as arguments for certain options, etc.

Thoughts on this approach?

@cleer73

This comment has been minimized.

cleer73 commented Sep 23, 2012

I would say that if you are going to make jQuery a dependency, you might as well make it a plugin for jQuery. Unless of course you could not meet your personal design goals while implementing Fine Uploader as a plugin.

Another option I thought of, to stop having to maintain all those nice utils, would be to try to roll in Sizzle.js and Underscore.js (I think this would cover all the other needs you listed). In my mind rolling sizzle and underscore into your code base could be a real pain in the ass, over time.

To me, this decision comes down to respecting your time and availability. And if you are going to be the only maintainer then I would go with it as a jQuery plugin. Those of us who dislike having external dependencies can always fork this project (which I have already done) to make sure they have what they like.

Another option would be to start allowing more devs to get involved to ease the work load, taking more of code reviewer role. But this is based on my perception, not fact, that you are not accepting a whole lot of pull requests. So feel free to correct me on this point.

@rnicholus

This comment has been minimized.

Member

rnicholus commented Sep 23, 2012

I certainly could allow more devs to get involved. Unfortunately, I don't have admin access to this repo yet. I'd have to talk to Andrew about that.

Why do you think I'm not accepting a lot of pull requests? I have closed a bunch of really old pull requests, but I personally went through all 130 or so issues/PRs over the last month and marked the ones I see as interesting/potentially useful. The rest I closed. As far as new PRs, if the PRs are javascript-related, I tend to be a bit picky, no argument there. If I see a PR with a concept that seems truly useful, I will "massage" it a bit before merging it into master. "Massaging" the PR code is prudent if I see something has been left out, if it does not pass some quick tests I run, or if the design of the new code goes against some existing architectural decisions already in place in Fine Uploader. One example of this would be including an option and/or code for a feature in FileUploaderBasic when it only applies to FileUploader. I've also massaged or outright rejected PRs with code that seems redundant to me or, in my opinion, adds "noise" to the codebase when there are other, existing methods to achieve the same goal. I'm also hesitant to add adjustments for really old browsers (although I don't recall seeing any such PRs recently). I don't plan on supporting IE6 or older, for example.

@rnicholus

This comment has been minimized.

Member

rnicholus commented Sep 23, 2012

...I would like to add that my suggestion to write the code code in jQuery and create a jQuery plug-in wrapper as an optional add-on would only be a useful avenue to pursue if those who voted "nay" on the jQuery proposal have a problem with cluttering up their code base by writing the own jQuery to interface with the plug-in. Perhaps these people have an otherwise jQuery-free project (speaking of their own handwritten code) or are using some other library such as Prototype or some other similar library. If the naysayers simply object to including jQuery as a dependency, this idea is not a useful one, though.

I would like to know, specifically, why some object to simply including jQuery as a dependency. If this is your specific objection, perhaps you could elaborate.

@cleer73

This comment has been minimized.

cleer73 commented Sep 24, 2012

So far as the management goes, those are your choices, it was not ment as a criticism. It was just my impression of your stance on the management, I am sorry I offended you. As I seem to have made a total jack ass of myself on this thread I will drop all other points, and respond to your very last statement:

For my work, I actually use jQuery, so it's not so much that I would have to include jQuery in my projects to continue using your uploader. It's that if I ever decided to move on from jQuery, for whatever reason in the future, I would have to drop your codebase and find another, with comparable features. It just gives me more flexibility in future projects, and I think it gives you a broader audience base in the long run.

@rnicholus

This comment has been minimized.

Member

rnicholus commented Sep 24, 2012

I didnt really take your assertion as a criticism. I'm happy to hear
constructive criticism or suggestions for improvement, along with ideas.
So, don't feel that you need to back down.

I'll need to give some more thought to 3.0 over the next few days or so.
I'll post my conclusion when i reach one.

I'll probably close the poll in the next hour or so.

For those who voted for jquery, care to share what you would think/do if
the decision did not go in your favor? That is, what if i decided not to
rewrite in jquery? What if i consider the suggestion to write an (optional)
jquery plugin wrapper? This may result in slower progress as far as
features and bugfixes are concerned, and may rule out some planned
features. I guess I'm trying to figure out if anyone is as pro-jquery
plug-in as some of the commenters that are anti-jquery plug-in.

To put it even simpler: Some people are clearly pissed off with my plan to re-write Fine Uploader using jQuery. Would anyone be pissed off if I decided to keep the core library in plain 'ole naked js? Again, I might write an optional jQuery plug-in wrapper if I went this route. Note that, if I went this route, there may be some notable refactoring of the existing code.
On Sep 23, 2012 7:14 PM, "Jacob Lee" notifications@github.com wrote:

So far as the management goes, those are your choices, it was not ment as
a criticism. It was just my impression of your stance on the management, I
am sorry I offended you. As I seem to have made a total jack ass of myself
on this thread I will drop all other points, and respond to your very last
statement:

For my work, I actually use jQuery, so it's not so much that I would have
to include jQuery in my projects to continue using your uploader. It's that
if I ever decided to move on from jQuery, for whatever reason in the
future, I would have to drop your codebase and find another, with
comparable features. It just gives me more flexibility in future projects,
and I think it gives you a broader audience base in the long run.


Reply to this email directly or view it on GitHubhttps://github.com/valums/file-uploader/issues/326#issuecomment-8804529.

@rnicholus

This comment has been minimized.

Member

rnicholus commented Sep 24, 2012

Final vote:

For jQuery: 40 (78%)
Against: 11 (22%)

I'd like to hear more discussion here from both sides. Please see my post above this one.

rnicholus pushed a commit that referenced this issue Sep 24, 2012

@tvernum

This comment has been minimized.

tvernum commented Sep 24, 2012

I voted against, because we use FineUploader with GWT.
It took some work to get it integrated into GWT, and I don't think I would be in a position to do that again with a jQuery-ised version.
If 3.0 becomes tied to jQuery, then we'll need to stick with 2.x or fork it.

@walterdavis

This comment has been minimized.

walterdavis commented Sep 24, 2012

I think I've made my point, but I want to refine one bit of it: visit MicroJS.com to see a growing number of specialized JS libraries that don't rely on any monolithic framework. By cherry-picking individual bits, you can build up just the behavior you need for your application -- often with a smaller total footprint than just jQuery itself. This is incredibly important for mobile devices with limited memory.

It is so unique and rare to see a refined uploader like yours that doesn't rely on a framework. This makes it work for everyone, not just those who pick the same library as you.

I've had to include both jQuery and another framework into the same application, and I only did so because it was in the admin console, and I could guarantee nobody was going to use a phone to edit the intranet documents. I would never want to be forced into choosing a framework -- often that choice has already been made before I get the project.

Walter

On Sep 24, 2012, at 2:26 AM, tvernum wrote:

I voted against, because we use FineUploader with GWT.
It took some work to get it integrated into GWT, and I don't think I would be in a position to do that again with a jQuery-ised version.
If 3.0 becomes tied to jQuery, then we'll need to stick with 2.x or fork it.


Reply to this email directly or view it on GitHub.

@emanwebdev

This comment has been minimized.

emanwebdev commented Sep 24, 2012

It is so unique and rare to see a refined uploader like yours that doesn't rely on a framework

+1

P.S.

MicroJS.com

Fantastic! THANKS!!!

++ see http://headjs.com/

@rnicholus

This comment has been minimized.

Member

rnicholus commented Sep 24, 2012

First I heard about MicroJS. Pretty cool indeed.

@rnicholus

This comment has been minimized.

Member

rnicholus commented Sep 24, 2012

Headjs is interesting, but I envisioned using a tool to combine all
3rd--party js files into one file for each release. In the master branch,
they would be split out into separate files, with instructions for those
who want to combine them. I also would consider splitting up
fileuploader.js into separate files to aid in future development and
bugfixes. Again, they would be combined in all releases.

On Mon, Sep 24, 2012 at 2:15 PM, Emmanuel notifications@github.com wrote:

It is so unique and rare to see a refined uploader like yours that
doesn't rely on a framework

+1

P.S.

MicroJS.com

Fantastic! THANKS!!!

  • see http://headjs.com/


    Reply to this email directly or view it on GitHubhttps://github.com/valums/file-uploader/issues/326#issuecomment-8830897.

@rnicholus

This comment has been minimized.

Member

rnicholus commented Sep 25, 2012

I've come to a conclusion.

While I don't necessarily agree with the arguments presented by the very vocal group of users against re-writing the library using jQuery, I respect their concerns. Perhaps I can make everyone happy here.

The plan:

  • I will not make jQuery a dependency.
  • There may, however, be a lot of refactoring in 3.0.
  • There will most definitely be some breaking changes as well. When this happens, I'll do my best to document the breaking changes to those upgrading can do so as painlessly as possible. (Off-topic note: Some of the 2.x releases may have minor breaking changes as well, but, again, they will be well documented for those upgrading.)
  • I will likely create an optional jQuery plug-in wrapper that will give jQuery users all of the benefits of a jQuery plug-in.
  • Not sure what 3rd party-libraries I will use in 3.0 or if I will use any 3rd-party code at all. MicroJS is something to consider. Please see this comment regarding use of 3rd-party libraries and code organization.
  • Please see the google doc in the readme if you want to add suggestions for 3.0 features.

@rnicholus rnicholus closed this Sep 25, 2012

@rnicholus

This comment has been minimized.

Member

rnicholus commented Sep 27, 2012

Check out the 3.0 branch from time to time if you are interested in my progress.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.