[tacos]

Someone in DHH's position could approach jQuery and request a subset containing what he needs. And then other projects could benefit from the refactor.

If there's even a benefit. This same post by the leader of any other project would involve a study of which components and apps use jQuery. And would state how far back compatibility is to be maintained.

So, for example, if commonly used gems require it, or if 90+% of the rails apps in the field require jQuery for other reasons, then this is just code churn for no benefit.

And why is this even a "rewrite"? You can suck the relevant lines of code out of jQuery and call it done. This is not a "Summer of Code" length endeavor.

[pluma]

The problem isn't jQuery, the problem is that 90% of the use cases for jQuery can now be solved with native APIs (or polyfills if compatibility with older browsers is a requirement).

The main feature is basically element.querySelectorAll (or document.querySelectorAll for the global version). The XHR wrapper can easily be replaced with the fetch API. Class list manipulation is easy with element.classList. The event listener API has also been consistently standardized across all browsers for quite a while.

There are a handful of things you might still want a utility library for (non-CSS animation among other things) but there are smaller, more specialised libraries for those. The utility belt approach of jQuery is no longer necessary.

The same is true for libraries like lodash/underscore, btw. If you target modern JavaScript environments or use polyfills and a transpiler like Babel most use cases of lodash are a solved problem -- not to mention that 90% of all code using lodash in the wild could be written using the native array methods that have been available since ES5 (and IE9).

[jwmerrill]

> The XHR wrapper can easily be replaced with the fetch API.

Browser support for fetch is still pretty weak, so you'll need some kind of polyfill to use it today.

http://caniuse.com/#feat=fetch

[tacos]

Right. My argument is that you could fork the relevant subset of jQuery and own your own compatibility story in the event that Rails wants to push this on apps for some reason (I don't see the benefit of that).

An alternative would be to initiate a discussion with jQuery as obviously Rails isn't the only framework that's dealing with this issue. Let the jQuery guys do what they're great at, let Rails do what it does.