-
Notifications
You must be signed in to change notification settings - Fork 122
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Native version #8
Comments
I vote for option 2, smaller the better. Also, has response always relied on jQuery1.7+? Has it ever used jQuery pre 'on' and 'off'? |
@ay13 Cool—that's what I'm leaning towards too. Pre 1.7 we used .resize() which could have also been done with .bind() - In jQuery 1.7+ all of the jQuery event methods internally route back to on/off/trigger. jQuery is easy enough to upgrade and the usage of on / off is recommended in the docs. Since Response 0.4.0 there is an experimental lazyloading feature that uses on / off / one / trigger on the document |
Is there a timeline for a native version? I am in the middle of a project where it would be very helpful since I can't upgrade (easily) to jQuery 1.7+. |
@ay13 Probably June. In the meantime you can alias to bind/unbind. For the on/off usage in Response this should work: jQuery.fn.on = jQuery.fn.on || jQuery.fn.bind;
jQuery.fn.off = jQuery.fn.off || jQuery.fn.unbind; Or you could use find and replace in Response to replace |
One of my initial goals with Response was to have it run entirely on native code. But back when I first started the project I didn't know how to handle all of it natively and opted to use jQuery for the rest. There are only a few jQuery methods that Response 0.5 relies on: $ / on / off / trigger / ready / html - basically for querying selectors, handling events, detecting the ready state, and inserting html. I pretty sure that I can work out a version that does all of this stuff natively, supports at least down to IE8, and keeps the overall lib <5k gzipped. By 1.0.0 I definitely think it will be worth it to do this— what do you think is a better route to take?
Option 1 - 1 version that detects availability of the needed methods, delegates to them if they exist, and otherwise uses native code. (This is consistent with how we done stuff so far.) I think maintainability would be easier this way.
Option 2 - 2 separate versions—one that requires a jQuery-compatible library and one that is entirely native. This would forego some of the detection and allow each version to be more compact. It might add some initial confusion as far as which version people should to use but I think it could be clearly explained at the top of each file. The public API would be indentical for both.
The text was updated successfully, but these errors were encountered: