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.
http://david.heinemeierhansson.com/2012/rails-is-omakase.htm...
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.
In time rails will need to replace this out, as the JS tooling keeps evolving, better solutions will arise.
While I wouldn't use vanilla rails & UJS much today, I still think it has value in getting things going.
I'm fairly certain there's not much of a point having jQuery in Ember and there's certainly no point in using it in jQuery (unless you just blatantly append random UI libraries -- most jQuery UI widgets can be implemented with fewer lines of React).
Most sites require jQuery, most developers are happy using it, why put the effort into getting rid of it?
Luckily Grails 3 dropped it, but the project I'm working on at the moment is stuck on Grails 2... and Grails 3 is a complete rewrite of the framework
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?
Now the remaining part of your comment is unfair. Pure frontend is just one small part of webapp development: templating, controller, ORM, i18n, user and session management, security, testing, etc.
You can do a lot of web backend stuff without websocket. Django is ok for that and if you combine it with Django Rest Framework, you get powerful tools at your disposal.
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.
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.
For example, at my previous job we used Django for our main request/response API and Tornado for our push API. Later on, the Tornado part was rewritten in Java. Given the Django experience of the team, this architecture proved to be easier to maintain than having to rewrite the entire API, since there were far more request/response endpoints than push endpoints.
Nowadays there's Pushpin, which I created after the above experience.
I like Django to build "hybrid" apps where e.g. public sites, registration form, etc. are rendered by the backend using only a couple of lines of js (not even using jQuery or similar) to enhance user expirience and another part of the app being a fullblown SPA using Django as a REST api.
Getting opinionated about js stacks at the moment could backfire hugely and alienate a chunk of their userbase. The policy is basically "Stuff should be left as 3rd party apps until a de facto winner emerges."
Not sure if that's likely to happen any time soon in anything related to front end code so keeping the core framework neutral seems like the best option. Mini-ecosystems can arise where neccesary.
I'd love to see some good, practical examples of a full-featured (ie. integrated) Django app with a js frontend. Pointers welcome!
Now is it better than assembling a little stack yourself with an ORM + a micro web framework? Well, perhaps not - though you still got the admin which can be handy. But next time you're going to need do to a project that won't benefit at all from being a SPA, Django will be helpful.
You can turn the question on its head - if you're just providing a relatively thin API, whatever you choose probably won't be terribly important as long as it is not something fragile that will be gone in 2 years. So don't invest too much thought into it.
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...
https://github.com/rails/rails/commit/63ac6255ba3553b529f4b2...
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).
Attempting to reproduce these errors by refreshing the current page and repeating whatever you just did will not work, since the Javascript state will be wiped clean - you'll need to navigate through the same path that you took to get to that page in the first place. (This happened to me recently; as you may imagine, it took me a while to figure out what was going on!)
It's possible to work around this by "cleaning up" whenever a Turbolinks change event fires, of course, but the point is that you can't just add Turbolinks to your project and expect everything to work as it did before.
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.
But you still have to make a lot of decisions. How do you handle user management ? ACL in a Rails app ? AFAIK Rails doesn't come with a default solution to these problems. What do you think is more important for an application ? User management or turbolinks by default ? The former would make more sense in a full stack framework. In fact both Django and Symfony 2 come with default solutions for this use case.
Finally, the JS ecosystem is moving so fast that decoupling JS from Ruby would make Rails maintenance a lot easier, Rails can't keep up with the front-end ecosystem and its avalanche of "good practice du jour". It's not like RDBMS which are fairly stable and didn't change in 10 years.
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.
This option should be opt in, not opt out which is the whole point of my comment.