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.
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.
For everyone who thinks rails installs too much by default, and hasn't ever tried `rails -h` - here are some options:<p>--skip-gemfile
--skip-git
--skip-keeps
--skip-active-record
--skip-sprockets
--skip-spring
--skip-javascript
--skip-turbolinks
--skip-test-unit
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.
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.
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.<p>I do agree that it should get out of default Rails. GJ community.
There was an article about a week ago that makes the claim that Rails is tailor-made for Basecamp.<p>This single comment absolutely confirms that point of view: <a href="https://github.com/rails/rails/issues/25208#issuecomment-222980490" rel="nofollow">https://github.com/rails/rails/issues/25208#issuecomment-222...</a>
<i>Omakase</i> implies a certain level of excellence in all the individual choices.<p>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.
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.<p>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.<p>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.<p>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.