Skip to content
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
Closed

Drop jQuery as a dependency #25208

dhh opened this issue May 31, 2016 · 62 comments

Comments

@dhh
Copy link
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
Copy link
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
Copy link
Contributor

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

@simi
Copy link
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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

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

@sgrif
Copy link
Contributor

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
Copy link

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
Copy link

kirushik commented Jun 1, 2016

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

@dhh
Copy link
Member Author

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 <[email protected]

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
Copy link
Member Author

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
Copy link
Contributor

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
Copy link

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
Copy link

mhuggins commented Jun 1, 2016

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

@javan
Copy link
Contributor

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
Copy link
Contributor

simi commented Jun 1, 2016

@mhuggins nice. I'm reviewing that also.

@warmwaffles
Copy link

That'd be nice

@dhh
Copy link
Member Author

dhh commented Jun 1, 2016

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

@lucaspiller
Copy link

@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
Copy link
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
Copy link
Member Author

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
Copy link

hauleth commented Jun 1, 2016

@dhh I would be pleased.

@max-reznichenko
Copy link

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
Copy link
Member

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
Copy link

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
Copy link
Contributor

waits commented Jun 5, 2016

@liudangyi Right, of course, thanks.

@mhuggins
Copy link

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
Copy link
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
Copy link
Contributor

@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
Copy link
Contributor

simi commented Jun 5, 2016

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

@connorshea
Copy link
Contributor

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

@liudangyi
Copy link

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
Copy link
Contributor

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 刘当一 [email protected]
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
Copy link
Member

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

@guilleiguaran
Copy link
Member

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
Copy link
Member Author

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
Copy link
Member

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 <
[email protected]> 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
Copy link
Member Author

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 [email protected] 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 <
[email protected]> 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
Copy link
Member

The pull request for this: #27113

@sjnims
Copy link

sjnims 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
Copy link
Member

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

@sjnims
Copy link

sjnims 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
Copy link
Contributor

javan commented May 20, 2017

@professorNim, you can install it either way. See https://github.com/rails/rails/tree/master/actionview/app/assets/javascripts#readme

@ybakos
Copy link
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
Copy link

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
* 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
Projects
None yet
Development

No branches or pull requests