[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.