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.
Sass has not dropped it's namesake syntax. They just recognized that the CSS-like syntax is easier for newcomers to parse and so enabled it by default.
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.
The "blank page" argument was once fairly compelling, but both React and Ember (that I know of) have been increasingly successful at solving that issue.
For sure. I've found getting that to work with a rails stack & webpack setup to be rather challenging. react_rails is pretty straight forward, but then you have a lot of global react components, and it gets trickier to leverage NPM. With webpack there's react_on_rails which is a sizable & complex gem, but it does work.
While I wouldn't use vanilla rails & UJS much today, I still think it has value in getting things going.
From experience, projects that use any of the available javascript frameworks also use jquery in some way or another. Including it is a tone saver. But coffee script should be removed as a default.
AngularJS (1) was heavily built around jQuery but I can't think of any current one (i.e. more recent than Backbone and Knockout) that justifies that statement.
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).
Then why drop jQuery? "It needn't be part of the default stack any more" doesn't hold up as a reason any more because it's not about whether something's needed or not but whether it's useful.
Most sites require jQuery, most developers are happy using it, why put the effort into getting rid of it?
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.