
Drop jQuery as a dependency from Rails - robermiranda
https://github.com/rails/rails/issues/25208
======
stevepike
The github thread itself is a nice example of a vibrant open source community.
They're thinking about whether the project can be a good entry point for
others into OSS, considering adopting outside libraries rather than re-writing
it themselves, and generally operating in a pretty positive manner.

~~~
pducks32
Helping newcomers find an entry point really helps them feel like they are
contributing and helps them get involved. It's also important to be
understanding when their code fails CI tests a few times.

------
monk_e_boy
As a web dev for the last 15 years or so, this is amazing news. The browsers
are finally getting to a point where the pain jQuery solved, is going away.

~~~
k__
Is this a legacy thing?

I'm a web dev for 10 years now and never used jQuery directly. (I used Ember
for half a year, which seems to have jQuery as dependency)

~~~
jcbrand
So did you do JS development back in 2006 without jQuery?

~~~
brianwawok
I started with Prototype. Not sure if it came out before or after the first
jQuery, but it was the cool kid for a while. Then the world realized it was a
disaster and started moving to jQuery...

~~~
DCoder
Too bad Magento devs missed that newsflash. Nowadays it still bundles
Prototype.js, and every theme and 50% third-party modules you install carry
their own copies of jQuery, all at different versions, placed in random
locations, and embedded into the page differently.

------
jacobsenscott
For everyone who thinks rails installs too much by default, and hasn't ever
tried `rails -h` - here are some options:

\--skip-gemfile \--skip-git \--skip-keeps \--skip-active-record \--skip-
sprockets \--skip-spring \--skip-javascript \--skip-turbolinks \--skip-test-
unit

~~~
molecule
The --skip options are handy. For reuse, they can be put into ~/.railsrc,
_e.g._

    
    
        --skip-gemfile
        --skip-git
        --skip-keeps

------
spriggan3
Rails should stop messing with Javascript all together. Drop JQuery,
CoffeeScript, TurboLinks and what not and let the users decide what to use,
make it optional. Rails shouldn't require a JS engine in order to run.

~~~
zeemonkee3
This is one of the best things about Django - outside the admin interface it's
not opinionated about your frontend setup.

~~~
bad_user
Of course "not opinionated" in this case is an euphemism and really means that
Django doesn't help you at all and so you have to suffer the incomplete and
abandoned middleware of others to have something that resembles an asset
pipeline. And that's actually odd, because both Rails and Django are
frameworks born for building frontends to MySQL databases, which means these
frameworks really are about HTTP 1.1 _frontend_ stuff.

For building backends and web APIs, especially web APIs that do constant
streaming of data, maybe through WebSocket, there are actually much better
options, so this raises the question, why use Django at all?

~~~
zeemonkee3
Take away templates and add Django Rest Framework and you have a very capable
platform for building large CRUD APIs complete with models, permissions,
serializers and so forth.

Is it the best solution when you just want to stream data down a socket? No.
That doesn't mean it's useless for many other things.

If I'm going down the SPA route I'd just build the frontend separately using
ember-cli or webpack or some other "native" solution and forget any asset
pipeline.

~~~
rbanffy
> If I'm going down the SPA route I'd just build the frontend separately using
> ember-cli or webpack or some other "native" solution and forget any asset
> pipeline.

It's a good approach. There is no need to treat front and back-ends as a
single application, bound by the same rules - they use completely different
stacks and completely different tooling.

------
Gonzih
I never understood why rails has javascript helpers at all. It just does not
bring any value in the long run, just complicates stuff. Rails should be js
libraries agnostic and not provide any js related helpers out of the box in my
opinion.

~~~
captain_crabs
I'm one of the (formerly) silent, happy masses who uses the default stack
gleefully. Turbolinks is amazing, ujs is wonderful, and coffeescript is
adequate until all the latest JS goodness is out for real. Make it so only the
first page load happens as an HTML request, everything after that happens via
ajax for a couple lines more code sprinkled throughout, and I still get the
regular html fallbacks? Yes please.

I'm able to quickly make entire complex interaction flows happen smoothly and
maintainably on a single page. Now, there's a point, where when you have to
start maintaining the state of various widgets on the page with each other, it
gets pretty iffy and its helpful to bust out React. But even then, it's
actually usually quicker to prototype out the templates/api for the widgets
using vanilla Rails.

The javascript helpers that Rails have are wonderful because they let me
quickly build useful software for people, and the fact that they're
idiomatically consistent with the Rails request/response setup (is it an html
response, or a js one?) throughout projects and apps cuts out a ton of cost of
me or other developers (some who'd never even used it before!) dropping back
into code I've written later to efficiently change things. Not, "what's being
used here? What's the api for that? how is this set up?" etc etc.

I've found that, across many projects with many people, in the long run, these
JS helpers are amazingly helpful and clarifying. So I'm going to have to
firmly - but respectfully - disagree with your opinion that Rails shouldn't
include them, simply because your opinion doesn't provide an alternative that
gives me better benefits than what's currently there. It just strikes me as
though it will divert engineering on actual hard problems of value to a lot
more of simply engineering for engineering's sake. I'm not saying I won't
change my mind...I'm saying, show me something better, and let's talk!

------
kendallpark
So I did this in my own recent project. Then other JS libraries I was using
needed jquery and it went right back in. I think many people will run into
this.

I do agree that it should get out of default Rails. GJ community.

------
stephenr
There was an article about a week ago that makes the claim that Rails is
tailor-made for Basecamp.

This single comment absolutely confirms that point of view:
[https://github.com/rails/rails/issues/25208#issuecomment-222...](https://github.com/rails/rails/issues/25208#issuecomment-222980490)

~~~
bronson
Lots of websites have those browser requirements. Many of them aren't written
in Rails. Care to explain your "absolutely confirms" logic?

~~~
stephenr
Lots of websites _require_ a browser that was released in the last 2 1/2
years?

I think you're seeing the web through SV tinted glasses.

~~~
bronson
Sure, since all major browsers auto-update now. This has been a thing for
years.

[https://technet.microsoft.com/en-
us/library/dn531055.aspx](https://technet.microsoft.com/en-
us/library/dn531055.aspx)

[http://meta.stackexchange.com/questions/56161/which-
browsers...](http://meta.stackexchange.com/questions/56161/which-browsers-are-
officially-supported-and-what-else-do-i-need)

[https://support.google.com/mail/answer/6557?hl=en](https://support.google.com/mail/answer/6557?hl=en)

[https://support.google.com/a/answer/33864?hl=en](https://support.google.com/a/answer/33864?hl=en)

[http://www.amazon.com/gp/help/customer/display.html?nodeId=2...](http://www.amazon.com/gp/help/customer/display.html?nodeId=200306330)
(notable exceoption for IE8, would love to know the reason)

etc.

------
tlrobinson
Related:
[http://youmightnotneedjquery.com/](http://youmightnotneedjquery.com/)

------
aphextron
An irrelevant framework drops another irrelevant framework as a dependency.

------
applecore
_Omakase_ implies a certain level of excellence in all the individual choices.

I believe Rails is In-N-Out Burger. While it offers few choices, it's reliable
and the hamburger is very good. The fries and frontend framework are
acceptable but no one goes to In-N-Out for the fries.

~~~
dang
We detached this subthread from
[https://news.ycombinator.com/item?id=11814018](https://news.ycombinator.com/item?id=11814018)
and marked it off-topic.

------
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](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.

