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.

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

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.

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

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

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

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

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.

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

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
.

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.

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

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

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

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.

@mhuggins nice. I'm reviewing that also.

That'd be nice

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

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

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

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

@dhh I would be pleased.

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?

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.

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.

@liudangyi Right, of course, thanks.

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

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

@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?

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

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

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. :)

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
.

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

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

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.

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
.

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.

The pull request for this: #27113

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?

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

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

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

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?

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.