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

Drop jQuery as a dependency #25208

Closed
dhh opened this Issue May 31, 2016 · 62 comments

Comments

Projects
None yet
@dhh
Member

dhh commented May 31, 2016

We should now be able to write our data-remote, data-confirm, XHR wrapping, and the few other hooks we rely on using vanilla JavaScript. Things have progressed well enough for that. This is not a verdict on jQuery. There are still plenty of other reasons for someone to want to use that, but it needn't be part of the default stack any more.

//cc @sstephenson @javan

@dhh dhh added the railties label May 31, 2016

@dhh dhh added this to the 5.1.0 milestone May 31, 2016

@simi

This comment has been minimized.

Contributor

simi commented May 31, 2016

Actually I'm working on jquery-ujs rewrite to pure JS. My first test is living in https://github.com/simi/jquery-ujs/tree/no-jquery.

@gsamokovarov

This comment has been minimized.

Contributor

gsamokovarov commented May 31, 2016

I think @pixeltrix wanted to do this as GSoC project, so I'm pinging him here as well.

@simi

This comment has been minimized.

Contributor

simi commented May 31, 2016

I think I can't attend GSoC, but definitely I'm really interested in this and I would like to finish it. At least I can provide alternative implementation.

@javan javan self-assigned this May 31, 2016

@javan

This comment has been minimized.

Member

javan commented May 31, 2016

Grabbed assignment for this one. @simi (and others), I'd be happy to review your implementation if you want to see it through.

@sgrif

This comment has been minimized.

Member

sgrif commented May 31, 2016

I do agree that this would make a lot of sense as a GSoC project, or a first patch for a newcomer, as it's a solid self contained change that's pretty straightforward. We'd be doing a disservice to those trying to find a way to get into OSS by handling this ourselves

@maclover7

This comment has been minimized.

Member

maclover7 commented May 31, 2016

Sounds like a good time to apply our newest label, good-first-patch!

@sgrif

This comment has been minimized.

Member

sgrif commented May 31, 2016

Note: There's no reason that someone looking to work on this needs to do the entire migration as a single PR -- changing one piece of ujs to not rely on jQuery at a time would make sense

@sgrif sgrif unassigned javan May 31, 2016

@benjamingr

This comment has been minimized.

benjamingr commented Jun 1, 2016

Hey, what form of browser support are you looking for here?

I don't mind personally landing a hand. If browser support needs to work for older IE versions than I doubt it'll save much space because of polyfills but it will still be worth our while.

@kirushik

This comment has been minimized.

kirushik commented Jun 1, 2016

There is also https://github.com/hauleth/vanilla-ujs

@dhh

This comment has been minimized.

Member

dhh commented Jun 1, 2016

Don't think that supporting legacy browsers is something we need to have
built-in by default. Happy to go with these baselines:
https://basecamp.com/help/3/guides/account/browsers

On Wed, Jun 1, 2016 at 2:38 PM, Benjamin Gruenbaum <notifications@github.com

wrote:

Hey, what form of browser support are you looking for here?

I don't mind personally landing a hand. If browser support needs to work
for older IE versions than I doubt it'll save much space because of
polyfills but it will still be worth our while.


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#25208 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AAAKtf_Vg2Vkxiy_HgHQ05jmUG10I87kks5qHX05gaJpZM4Iqa33
.

@dhh

This comment has been minimized.

Member

dhh commented Jun 1, 2016

Ah, https://github.com/hauleth/vanilla-ujs looks like exactly what we've been searching for. @javan do you want to take a look at that? If we can just adopt that, all the better.

@javan

This comment has been minimized.

Member

javan commented Jun 1, 2016

vanilla-ujs looks pretty solid, and perhaps we can use it as a starting point. I don't like that it exposes some unnecessary globals (I spotted window.CSRF, window.LiteAjax, and window.matches).

@benjamingr

This comment has been minimized.

benjamingr commented Jun 1, 2016

@javan I just checked - it only exposes them for debugging they are not actually required. It will trigger a DOM custom event with ajax:before on form submission which appends the CSRF token.

It is only exposed with https://github.com/hauleth/vanilla-ujs/blob/master/lib/assets/javascripts/vanilla-ujs/csrf.js#L20 - it is not used anywhere sans tests and can be safely removed.

IE8 and below are not supported but then again we shouldn't really support legacy browsers.

LiteAjax and others can be shared, I think this can be easily build into a single module wrapped in an IIFE - other things aren't using window.

@mhuggins

This comment has been minimized.

mhuggins commented Jun 1, 2016

@simi vanilla ujs has existed for quite some time. :)

@javan

This comment has been minimized.

Member

javan commented Jun 1, 2016

LiteAjax and others can be shared, I think this can be easily build into a single module wrapped in an IIFE - other things aren't using window.

👍

Additionally, it would be nice to use fetch in browsers that support it.

@simi

This comment has been minimized.

Contributor

simi commented Jun 1, 2016

@mhuggins nice. I'm reviewing that also.

@warmwaffles

This comment has been minimized.

warmwaffles commented Jun 1, 2016

That'd be nice

@dhh

This comment has been minimized.

Member

dhh commented Jun 1, 2016

@hauleth What do you think about turning vanilla-js into a Rails PR?

@lucaspiller

This comment has been minimized.

lucaspiller commented Jun 1, 2016

@dhh I know Rails doesn't treat backwards compatibility as an important goal, but only supporting modern browsers will mean maintaining legacy Rails applications is going to be even more challenging. There are still plenty of places where developers are stuck supporting users on legacy browsers.

It would be great if the current version of ujs was kept around and officially supported (maybe renamed ujs-legacy?), keeping jQuery and hence support for older browsers. Assuming the ujs API isn't going to drastically change, it won't be much work to maintain.

@simi

This comment has been minimized.

Contributor

simi commented Jun 1, 2016

@lucaspiller current implementation lives in https://github.com/rails/jquery-ujs. I think it will be still supported and you'll be able to point manually in gemfile to that.

The current approach is to make new default and avoid https://github.com/rails/jquery-ujs.

PS:

I know Rails doesn't treat backwards compatibility as an important goal.

That's not true IMHO.

@dhh

This comment has been minimized.

Member

dhh commented Jun 1, 2016

@lucaspiller What @simi said. The current jquery-based approach would still be available as a plugin, but the default would change.

@hauleth

This comment has been minimized.

hauleth commented Jun 1, 2016

@dhh I would be pleased.

@Ser1aL

This comment has been minimized.

Ser1aL commented Jun 1, 2016

One of the main ideas in the philosophy of a software framework is to ease the burden of program developer. Rails does this perfectly nowadays by providing a really useful set of tools and libraries.

On the other hand, Ruby on Rails developers often do Javascript code, which in most cases lives in the Rails application itself and always quite often relies on JQuery.

I understand the idea behind this issue is to decrease the number of dependencies. However in reality this change means that most developers will do the manual installation of JQuery as the first step after "rails new [app]".

So -- combining the statements above with JQuery download stats (http://npm-stat.com/charts.html?package=jquery), the question:

Is it really really a good decision?

@rafaelfranca

This comment has been minimized.

Member

rafaelfranca commented Jun 1, 2016

I think so.

Also you can easily do rails new -j jquery [app]. That is going to keep working and jquery-rails is going to keep being maintained.

@cannikin

This comment has been minimized.

cannikin commented Jun 1, 2016

I assumed that vanilla-ujs was meant to be a drop-in replacement for jquery-ujs but it currently only fires two (ajax:before and ajax:complete) of the defined UJS callbacks.

@waits

This comment has been minimized.

waits commented Jun 5, 2016

@liudangyi Right, of course, thanks.

@mhuggins

This comment has been minimized.

mhuggins commented Jun 5, 2016

@jjb Do you have evidence that CoffeeScript is preferred over JS by Rubyists? I for one have come to loathe CoffeeScript, so I'm curious what the basis of your consideration is.

@jjb

This comment has been minimized.

Contributor

jjb commented Jun 5, 2016

I do not have evidence. My statement was based on coffeescript syntax and grammar being more similar to ruby than it is to javascript.

@marekkirejczyk

This comment has been minimized.

Contributor

marekkirejczyk commented Jun 5, 2016

@dhh @rafaelfranca Which approach is better?
a) Make vanilla ujs code part of rails code
or
b) Create new gem (or extend existing e.g. vanilla-ujs) and point to it from default Gemfile?

@simi

This comment has been minimized.

Contributor

simi commented Jun 5, 2016

I think @liudangyi's approach will be the best.

@connorshea

This comment has been minimized.

Contributor

connorshea commented Jun 9, 2016

ActionCable had cable.coffee replaced by cable.js for exactly this reason, I'd prefer that CoffeeScript was avoided as a dependency.

@liudangyi

This comment has been minimized.

liudangyi commented Aug 1, 2016

Hello, all. I have finished most of the work now, which is available here. All tests are passed, with some necessary modifications in API. However, I cannot test all the cases, so any reviews or suggestions are welcome. :)

@sgrif

This comment has been minimized.

Member

sgrif commented Aug 1, 2016

Please do open a pull request with the changes.

On Mon, Aug 1, 2016 at 1:46 AM Dangyi Liu 刘当一 notifications@github.com
wrote:

Hello, all. I have finished most of the work now, which is available here
http:///liudangyi/jquery-ujs. All tests are passed, with some necessary
modifications in API. However, I cannot test all the cases. Any reviews or
advices are welcome. :)


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#25208 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABdWK5uAmhDAZSCOhP2FEzIY2HcGatTBks5qbYgpgaJpZM4Iqa33
.

@guilleiguaran

This comment has been minimized.

Member

guilleiguaran commented Oct 19, 2016

FYI, rails/jquery-ujs#474 is finished and ready for review

@guilleiguaran

This comment has been minimized.

Member

guilleiguaran commented Nov 18, 2016

The vanilla ujs implementation by @liudangyi is now living in https://github.com/rails/rails-ujs

I'll ask to get #26836 updated so the users of Yarn can get this in their default package.json file instead of jquery and jquery-ujs, but we still need to decide how to Rails distribute this to users not using Yarn/npm/Bower, in this case we can:

  1. Copy dist/rails.js file directly to Rails (inside of railties? a new gem living under rails/rails? copy to user app when the app is generated?)
    or
  2. Create a new rails-ujs gem and add it to default Gemfile

What do you prefer?

/cc @dhh @rafaelfranca @pixeltrix @sgrif @liudangyi

@dhh

This comment has been minimized.

Member

dhh commented Nov 18, 2016

I'm partial to #1. It's just one compiled file. Seems a little much to distribute as a gem and make it a dependency. I would have it be part of Action View since it's needed as a baseline for those helpers to work.

@rafaelfranca

This comment has been minimized.

Member

rafaelfranca commented Nov 18, 2016

But that means that if we need to upgrade that file for security reasons we
need to release rails. I think this make our release process more
complicated. My preference is to have it being managed as node module but
for those who don't have node, a gem should not be hard to create.
On Fri, Nov 18, 2016 at 8:21 AM David Heinemeier Hansson <
notifications@github.com> wrote:

I'm partial to #1 #1. It's just
one compiled file. Seems a little much to distribute as a gem and make it a
dependency. I would have it be part of Action View since it's needed as a
baseline for those helpers to work.


You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
#25208 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAC66HEHQsZc90Huodlrst56bGImFmF1ks5q_aZwgaJpZM4Iqa33
.

@dhh

This comment has been minimized.

Member

dhh commented Nov 18, 2016

If there's an update, we can also just release that dist file again for people to copy in. Don't think that should be the blocker.

Agree that for people who use a dependency manager, that should be the default. But if we are not committing to that as a requirement at the moment, then I think a single dist file is fine.

But I also don't care THAT much. So if you're very passionate about a gem wrapper, then fine by me.

On Nov 18, 2016, at 18:08, Rafael França notifications@github.com wrote:

But that means that if we need to upgrade that file for security reasons we
need to release rails. I think this make our release process more
complicated. My preference is to have it being managed as node module but
for those who don't have node, a gem should not be hard to create.
On Fri, Nov 18, 2016 at 8:21 AM David Heinemeier Hansson <
notifications@github.com> wrote:

I'm partial to #1 #1. It's just
one compiled file. Seems a little much to distribute as a gem and make it a
dependency. I would have it be part of Action View since it's needed as a
baseline for those helpers to work.


You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
#25208 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAC66HEHQsZc90Huodlrst56bGImFmF1ks5q_aZwgaJpZM4Iqa33
.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

@guilleiguaran

This comment has been minimized.

Member

guilleiguaran commented Nov 20, 2016

The pull request for this: #27113

@professorNim

This comment has been minimized.

professorNim commented May 20, 2017

What happened to the github repo? https://github.com/rails/rails-ujs is showing 404 not found...did you decide to revert back to jquery-ujs?

@matthewd

This comment has been minimized.

Member

matthewd commented May 20, 2017

It was merged into actionview, in rails/rails: https://github.com/rails/rails/tree/master/actionview/app/assets/javascripts

@professorNim

This comment has been minimized.

professorNim commented May 20, 2017

Given that it has been merged into actionview, does one still need to install it via npm or yarn? I saw some discussion re: a gem for rails-ujs, will that continue to be maintained? For those of us used to working with gems rather than npm or yarn, I'd prefer the gem route rather than having to remember to update via some other method (e.g. npm/yarn).

@javan

This comment has been minimized.

Member

javan commented May 20, 2017

@ybakos

This comment has been minimized.

Contributor

ybakos commented Jun 23, 2017

Isn't the Working with Javascript in Rails doc now quite misleading? Almost all of the code relies on jQuery. Is an update to this doc on the core team agenda, or are PR's welcome here?

@Dark-Schneider-666

This comment has been minimized.

Dark-Schneider-666 commented Jul 31, 2017

Hi, I will repeat here my opinion about the topic.

Then it is confusing. Following the tutorials of the Unobtrusive JavaScript you get coffeescript errors (silent error indeed), and it should work out-of-the-box.
IMHO the correct behavior would be the opposite, include it so the coffeescripts would work by default, and then if programmer do not want it, simply remove.
But removing JQuery you get the behavior of things not working OOTB, and I think that is as Rails was intended to be.

I'll try to elaborate more my reply:

  • I think JQuery has not been declared deprecated.
  • Most of the codes shared are jquery like.
  • It is easier, compare the typical code for setting event listener + ajax.

Then, I think Rails was created with the intention to be the on the easy way. By default everything should be included, so everything (typical) would work out-of-the-box, the easy way. Look i.e. that all objects are included by default. After, any user could freely attune the config to the application.
But the other way IMO is opposite, with some lacks in the application, and needing user additions for make the typical to work.

tortuetorche added a commit to efficiently/jquery-laravel that referenced this issue Dec 13, 2017

Experimental support for Laravel 5.5
* Add jQuery 3.2.1 library (jquery3.2.js)
* Update Rails UJS library
* Add Rails UJS with File Upload support (rails-ujs-file-upload.js), see rails/jquery-ujs#499
* Add Rails UJS without jQuery dependancy (rails-ujs-no-jquery.js), see rails/rails#25208
* Add Laravel 5.5 providers directive
* Add PHP 7.2 in Travis CI builds
* Remove HHVM support from Travis CI builds
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment