Discussion: pure-js (2.x) vs. jquery-js (3.x) #326
Comments
|
This is a very neat solution. I like it a lot! |
|
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. |
|
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). |
|
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? |
|
Perfectly! |
ghost
assigned 
|
there are numerous jQuery uploaders available while... your pure-js is the only one! Keep the good work and uniqueness of your solution!!! |
|
I would expect most users to be more concerned with features, support,
|
|
@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! |
|
@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. |
|
@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. |
|
I can certainly put that into my TODO list when developing 3.0 (which has On Wed, Sep 19, 2012 at 1:11 PM, reinink notifications@github.com wrote:
|
|
@rnicholus Done. ;) |
|
@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. |
|
@rnicholus Makes good sense to me!!! |
|
Moving to jQuery? so you are heading to a clone of the http://blueimp.github.com/jQuery-File-Upload/ ? What about solutions that don't want to rely on the fat jQuery? |
|
@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. |
|
I've created a poll to see what interested users think. |
|
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. All events need be similar to jQuery, like FileUpload.on('eventName', callback). |
|
@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. |
|
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.
So, when you build, you will have only two files:
Another advantage is: you can create more wrappers (to prototype, for instance):
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... |
|
@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. |
|
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:
|
ooops, sorry for having used the word clone Take it easy. Just my poor english :)
Right, I've read that in the meantime. Ok then. Great! MANY Thanks coz good pure-js uploaders are v. seldom!
Coz some projects come WITHOUT jQuery. External specs aso. |
|
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! |
... but you wrote too:
and jQ uploaders are already here, |
|
@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. |
|
Quite a lively conversation here. Never thought this would be so controversial. 😏 |
|
Maybe I'm missing some things, but here's what I'd do.
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¢ |
|
@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. |
|
@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. |
|
Hmm, i don't recall saying i was going to use jquery ui.
|
|
I may have picked that up from someone else's comment, sorry about that. |
|
@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. |
|
@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. |
|
@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. |
|
@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 |
|
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? |
|
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. |
|
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. |
|
...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. |
|
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. |
|
I didnt really take your assertion as a criticism. I'm happy to hear I'll need to give some more thought to 3.0 over the next few days or so. 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 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.
|
|
Final vote: For jQuery: 40 (78%) I'd like to hear more discussion here from both sides. Please see my post above this one. |
|
I voted against, because we use FineUploader with GWT. |
|
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:
|
+1 P.S.
Fantastic! THANKS!!! ++ see http://headjs.com/ |
|
First I heard about MicroJS. Pretty cool indeed. |
|
Headjs is interesting, but I envisioned using a tool to combine all On Mon, Sep 24, 2012 at 2:15 PM, Emmanuel notifications@github.com wrote:
|
|
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:
|
|
Check out the 3.0 branch from time to time if you are interested in my progress. |
I make this topic to discuss about the pure-js ans jquery-js version of library.
Supposedly will exists two versions of Fine Uploader:
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:
Events, methods and vars need be the same to both.
Files can be:
fileuploader.jsjquery-fileuploader.js(requiresfileuploader.js)prototype-fileuploader.js(requiresfileuploader.js) -- for instanceThe 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(requiresfileuploader-core.jsonly)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.
The text was updated successfully, but these errors were encountered: