Drop jQuery as a dependency from Rails (opens in new tab)

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.

Which means that in 10 years, that's true for enterprise software, too.

jQuery helps with browser quirks, though. Search the below file for the string "// Support" to see what I mean. Yes, there are a lot of entries for older browsers, but there are also a lot of entries for relatively recent browsers too.

https://github.com/jquery/jquery/blob/3.0.0-rc1/dist/jquery....

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)

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

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

You're missing the central point of default rails stack.

http://david.heinemeierhansson.com/2012/rails-is-omakase.htm...

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

I think you might be missing the point, though! The main tradeoff of Rails is that it comes with that default setup in-place, and for most modern apps that will include Javascript. The defaults are there for a quick-start, and can easily be removed if you want to use a different approach.

The new TurboLinks is one of the best things about Rails 5, though. You can basically get UX comparable to an SPA with mostly server code.

As for coffeescript, you can just remove the gem and it'll use regular JS.

https://www.nateberkopec.com/2015/05/27/100-ms-to-glass-with...

Rails is a full-stack framework. One of its strengths is that out of the box you have everything there - database integration, http layer, also JavaScript.

Having said that - you have a choice. Rails is about defaults. By default it gives you jQuery, CoffeeScript and TurboLinks, but you don't have to use it at all. I've built a number of Rails apps and most of them use CoffeeScript, but don't use TurboLinks. It took me just a few seconds to remove it from my Gemfile.

Also, Rails API project is a subset of Rails that does not require JS (it was merged to Rails so you'll be able to generate API application in Rails 5).

Rails is a true example of an opinionated framework. So if you think this is the way to go, open an issue on github, bring out your ideas about how this change can help people and see if it works out.

Rails tries to set most of the best practises for you so that you don't need to make bad decisions on out-of-scope things. just focus on the actual problem. If you are well aware of how things are working and it doesn't fit you, then you can start with Sinatra or rewrite the parts that are not good in Rails.

But just saying Rails should drop JS doesn't doesn't add much unless you have a better solution.

I feel like the rails-api built into Rails 5 solves a lot of this. None of these will be installed when you `rails new project --api`. Doesn't help if you're just trying to do static HTML though.

Rails philosophy is a full stack framework. Not having to make decisions about your first web app is a huge draw to the framework.

I think you're right if Rails was built for "production" applications. However, the way most people tend to use Rails is a prototyping framework. The nature of Ruby and the vast ecosystem of components (gems) makes building something very quick. It is definitely my go-to solution If I want to experiment with an idea.

The problem is if the prototype is successful, it becomes the production system and all the things that helped initial development start to hurt maintenance. That though is a different topic.

My point is having Rails give a good set of starting vectors for all things web development is a big part of why it is so quick to get started, it's what makes it great for prototyping.

Yep, I use Rails to host Sidekiq background workers. Have absolutely no use for the front-end stuff.

It is completely optional, just pass the --skip-javascript option when you generate a new app.

And asset-pipeline altogether. Replace it with a simple optional gem to integrate with Webpack.

I agree. It's just cruft I have to work around or rip out.

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!

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.

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.

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.

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

Sure, DHH said it himself. Rails is for basecamp like apps. Whats the deal?

Do you have a link to the article?

Rails is a joke and @dhh is only making it worse. I'm disgusted by his choices. A lot of good devs are moving away from it for several reasons.

For me, it was the amount of magic involved in everything. I'm just glad I gave up and moved onto other things.

We detached this subthread from https://news.ycombinator.com/item?id=11814018 and marked it off-topic.

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