10 ms·

Drop jQuery as a dependency from Rails

292 points by robermiranda 10y ago

tacos 10y ago
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 10y ago
  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 10y ago
    > 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 10y ago
      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.
monk_e_boy 10y ago
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__ 10y ago
  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)
  - jaitsu 10y ago
    If you've been a web dev for 10 years then you'll know that the most fundamental tool for scripting is a pain point (document ready), jQuery did a good job of abstracting the nuances away, see: http://stackoverflow.com/questions/799981/document-ready-equivalent-without-jquery http://stackoverflow.com/questions/799981/document-ready-equ...
    - mattmanser 10y ago
      And the incompatible ajax interfaces. And the inconsistent element selection. And the... I'm also not sure I'd call document ready the most fundamental as a lot of people (including me) used to use onclick='' and onload='' directly on elements back then when we all loaded script tags in the head.
      - k__ 10y ago
        I know these problems, yes. But I didn't hit them, because I mostly did everything on the server side. When I switched to SPAs, I used ExtJS.
    - minitech 10y ago
      Document ready is hardly the most fundamental “tool” for scripting, and it has always been easy to resolve in a cross-browser way: stick your scripts before </body>.
  - 10y ago
spriggan3 10y ago
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.
- xentronium 10y ago
  You're missing the central point of default rails stack. http://david.heinemeierhansson.com/2012/rails-is-omakase.html http://david.heinemeierhansson.com/2012/rails-is-omakase.htm...
  - pluma 10y ago
    Sure, except in this case the Rails defaults are totally at odds with how the larger JS ecosystem has evolved. CoffeeScript was basically the logical complement to Haml (Ruby-like syntax for HTML) and Sass (Ruby-like syntax for CSS) -- although Sass has since dropped its original syntax and moved on with the CSS-like SCSS. Since then CS has lost a lot of popularity outside the Rails community. Babel and TypeScript provide similar syntactic niceties based on actual additions to the language (Babel is basically letting you use unfinished future additions to JavaScript before they are actually implement or even published). Sass in many projects has been replaced with libsass used via Node.js bindings. Entire toolchains like Grunt, Gulp, Browserify and Webpack have sprung up around Node.js. Not to mention that universal/isomorphic apps are now a thing and anything nontrivial generally assumes you're using a Node.js backend. The default Rails stack is precisely that: a Rails stack. Rails is backend software. It has been around long enough to have seen the massive changes the frontend has undergone from being basically "just some assets" to an entire ecosystem of its own right. The Rails asset pipeline is simply not sufficient for any serious frontend project anymore. This is not Rails' fault. It's just a natural evolution all backend software has observed. Rails is still a good solution for building API servers or even simple frontends. But it's not a complete solution anymore and it can't be.
    - agmcleod 10y ago
      I agree it's not the complete solution, but I think rails does a pretty good job at providing tools for making a progressive webapp. Many of us see the apps that have a blank page until data is loaded and the front end JS then renders. It's just a yuck experience. I dislike the fact that it happens in one of my own projects. While I find the concept of turbo links weird with pulling raw html over XHR and then rendering it, it does essentially just speed up a non-js capable website. In time rails will need to replace this out, as the JS tooling keeps evolving, better solutions will arise.
Gonzih 10y ago
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.
- viiralvx 10y ago
  Concurred. I'd previously only used Rails for building out APIs to be used in combination with libraries/frameworks like React and Ember.js. I'm recently working on a full-stack Rails app that has frequent usage of "remote: true" and some JS magic for things to work "the Rails way". The Rails JS "magic" is sort of confusing/horrifying when actually working with it and I'm finding it the cause of mysterious bugs that are hard to debug. :/ Why they just didn't use AJAX for these remote forms, I don't know. But it's annoying to deal with.
- timdorr 10y ago
  data-method is probably the biggest reason why. When your biggest auth library (Devise) makes logging out, one of the most common actions you'll add to an app after signing in, a DELETE request, then having a quick one-attribute means to provide that link is very valuable to have.
- phillmv 10y ago
  You have to look at in context; Rails got started in ~2006, long before you could do everything in JS, and its purpose was to enable you to build a web app from top to bottom. At a glance, I don't think you can really claim that the JS frontend world is mature or stable, so in the meantime muddling-along seems equally valid.
- captain_crabs 10y ago
  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!
stevepike 10y ago
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 10y ago
  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.
applecore 10y ago
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.
- alexnaspo 10y ago
  Animal Fries tho
  - rplas 10y ago
    New on Medium: Rails is Animal Fries
  - AJRF 10y ago
    inb4 dang comes and kills the fun
- KurtMueller 10y ago
  Animal fries
- astrowilliam 10y ago
  Animal Fries!!!
  - officialchicken 10y ago
    I'm not anywhere near an In-and-Out right now but I did learn: A) they have a secret menu, B) Animal fries look delicious[0]. [0] http://hackthemenu.com/in-n-out/secret-menu/animal-style-fries-3/ http://hackthemenu.com/in-n-out/secret-menu/animal-style-fri...
- jtmarmon 10y ago
  animal fries dawg
- awjr 10y ago
  Now I'm hungry ;)
stephenr 10y ago
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-222980490 https://github.com/rails/rails/issues/25208#issuecomment-222...
- statictype 10y ago
  Do you have a link to the article?
  - stephenr 10y ago
    http://www.akitaonrails.com/2016/05/23/rails-has-won-the-elephant-in-the-room http://www.akitaonrails.com/2016/05/23/rails-has-won-the-ele... HN discussion: https://news.ycombinator.com/item?id=11757993 https://news.ycombinator.com/item?id=11757993
- rajahafify 10y ago
  Sure, DHH said it himself. Rails is for basecamp like apps. Whats the deal?
  - stephenr 10y ago
    But is it "for Basecamp like apps". Or is it "for the Basecamp app"? I honestly can't believe a back end framework has minimum supported browser requirements that are basically "use the latest or GTFO".
    - jacobsenscott 10y ago
      It is for "most web apps" because most web apps are like basecamp, and it isn't "use the latest or GTFO". It is "use the latest by default or add a single line to your gem file if you want to support older browsers." Most web apps are only tested on the latest browsers anyway, even if they claim to support older browsers. This is true unless you have a very popular app and a very large team.
kendallpark 10y ago
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.
jacobsenscott 10y ago
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 10y ago
  The --skip options are handy. For reuse, they can be put into ~/.railsrc, e.g. --skip-gemfile --skip-git --skip-keeps
tlrobinson 10y ago
Related: http://youmightnotneedjquery.com/ http://youmightnotneedjquery.com/
aphextron 10y ago
An irrelevant framework drops another irrelevant framework as a dependency.

292 points by robermiranda 10y ago

tacos 10y ago

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 10y ago
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 10y ago
  > 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 10y ago
    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.

monk_e_boy 10y ago

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__ 10y ago
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)
- jaitsu 10y ago
  If you've been a web dev for 10 years then you'll know that the most fundamental tool for scripting is a pain point (document ready), jQuery did a good job of abstracting the nuances away, see: http://stackoverflow.com/questions/799981/document-ready-equivalent-without-jquery http://stackoverflow.com/questions/799981/document-ready-equ...
  - mattmanser 10y ago
    And the incompatible ajax interfaces. And the inconsistent element selection. And the... I'm also not sure I'd call document ready the most fundamental as a lot of people (including me) used to use onclick='' and onload='' directly on elements back then when we all loaded script tags in the head.
    - k__ 10y ago
      I know these problems, yes. But I didn't hit them, because I mostly did everything on the server side. When I switched to SPAs, I used ExtJS.
  - minitech 10y ago
    Document ready is hardly the most fundamental “tool” for scripting, and it has always been easy to resolve in a cross-browser way: stick your scripts before </body>.
- 10y ago

spriggan3 10y ago

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.

xentronium 10y ago
You're missing the central point of default rails stack. http://david.heinemeierhansson.com/2012/rails-is-omakase.html http://david.heinemeierhansson.com/2012/rails-is-omakase.htm...
- pluma 10y ago
  Sure, except in this case the Rails defaults are totally at odds with how the larger JS ecosystem has evolved. CoffeeScript was basically the logical complement to Haml (Ruby-like syntax for HTML) and Sass (Ruby-like syntax for CSS) -- although Sass has since dropped its original syntax and moved on with the CSS-like SCSS. Since then CS has lost a lot of popularity outside the Rails community. Babel and TypeScript provide similar syntactic niceties based on actual additions to the language (Babel is basically letting you use unfinished future additions to JavaScript before they are actually implement or even published). Sass in many projects has been replaced with libsass used via Node.js bindings. Entire toolchains like Grunt, Gulp, Browserify and Webpack have sprung up around Node.js. Not to mention that universal/isomorphic apps are now a thing and anything nontrivial generally assumes you're using a Node.js backend. The default Rails stack is precisely that: a Rails stack. Rails is backend software. It has been around long enough to have seen the massive changes the frontend has undergone from being basically "just some assets" to an entire ecosystem of its own right. The Rails asset pipeline is simply not sufficient for any serious frontend project anymore. This is not Rails' fault. It's just a natural evolution all backend software has observed. Rails is still a good solution for building API servers or even simple frontends. But it's not a complete solution anymore and it can't be.
  - agmcleod 10y ago
    I agree it's not the complete solution, but I think rails does a pretty good job at providing tools for making a progressive webapp. Many of us see the apps that have a blank page until data is loaded and the front end JS then renders. It's just a yuck experience. I dislike the fact that it happens in one of my own projects. While I find the concept of turbo links weird with pulling raw html over XHR and then rendering it, it does essentially just speed up a non-js capable website. In time rails will need to replace this out, as the JS tooling keeps evolving, better solutions will arise.

Gonzih 10y ago

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.

viiralvx 10y ago
Concurred. I'd previously only used Rails for building out APIs to be used in combination with libraries/frameworks like React and Ember.js. I'm recently working on a full-stack Rails app that has frequent usage of "remote: true" and some JS magic for things to work "the Rails way". The Rails JS "magic" is sort of confusing/horrifying when actually working with it and I'm finding it the cause of mysterious bugs that are hard to debug. :/ Why they just didn't use AJAX for these remote forms, I don't know. But it's annoying to deal with.
timdorr 10y ago
data-method is probably the biggest reason why. When your biggest auth library (Devise) makes logging out, one of the most common actions you'll add to an app after signing in, a DELETE request, then having a quick one-attribute means to provide that link is very valuable to have.
phillmv 10y ago
You have to look at in context; Rails got started in ~2006, long before you could do everything in JS, and its purpose was to enable you to build a web app from top to bottom. At a glance, I don't think you can really claim that the JS frontend world is mature or stable, so in the meantime muddling-along seems equally valid.
captain_crabs 10y ago
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!

stevepike 10y ago

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 10y ago
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.

applecore 10y ago

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.

alexnaspo 10y ago
Animal Fries tho
- rplas 10y ago
  New on Medium: Rails is Animal Fries
- AJRF 10y ago
  inb4 dang comes and kills the fun
KurtMueller 10y ago
Animal fries
astrowilliam 10y ago
Animal Fries!!!
- officialchicken 10y ago
  I'm not anywhere near an In-and-Out right now but I did learn: A) they have a secret menu, B) Animal fries look delicious[0]. [0] http://hackthemenu.com/in-n-out/secret-menu/animal-style-fries-3/ http://hackthemenu.com/in-n-out/secret-menu/animal-style-fri...
jtmarmon 10y ago
animal fries dawg
awjr 10y ago
Now I'm hungry ;)

stephenr 10y ago

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-222980490 https://github.com/rails/rails/issues/25208#issuecomment-222...

statictype 10y ago
Do you have a link to the article?
- stephenr 10y ago
  http://www.akitaonrails.com/2016/05/23/rails-has-won-the-elephant-in-the-room http://www.akitaonrails.com/2016/05/23/rails-has-won-the-ele... HN discussion: https://news.ycombinator.com/item?id=11757993 https://news.ycombinator.com/item?id=11757993
rajahafify 10y ago
Sure, DHH said it himself. Rails is for basecamp like apps. Whats the deal?
- stephenr 10y ago
  But is it "for Basecamp like apps". Or is it "for the Basecamp app"? I honestly can't believe a back end framework has minimum supported browser requirements that are basically "use the latest or GTFO".
  - jacobsenscott 10y ago
    It is for "most web apps" because most web apps are like basecamp, and it isn't "use the latest or GTFO". It is "use the latest by default or add a single line to your gem file if you want to support older browsers." Most web apps are only tested on the latest browsers anyway, even if they claim to support older browsers. This is true unless you have a very popular app and a very large team.

kendallpark 10y ago

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.

jacobsenscott 10y ago

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 10y ago
The --skip options are handy. For reuse, they can be put into ~/.railsrc, e.g. --skip-gemfile --skip-git --skip-keeps

tlrobinson 10y ago

Related: http://youmightnotneedjquery.com/ http://youmightnotneedjquery.com/

aphextron 10y ago

An irrelevant framework drops another irrelevant framework as a dependency.