6 ms·

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 optiona

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.
    - sanderjd 10y ago
      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.
      - agmcleod 10y ago
        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.
    - fbonetti 10y ago
      React's server-side rendering solves the blank page issue.
  - vinceguidry 10y ago
    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.
  - asimuvPR 10y ago
    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.
- tlrobinson 10y ago
  I prefer Giles Bowkett's dramatic reading version: https://www.youtube.com/watch?v=E99FnoYqoII https://www.youtube.com/watch?v=E99FnoYqoII
- hellodevnull 10y ago
  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?
zeemonkee3 10y ago
This is one of the best things about Django - outside the admin interface it's not opinionated about your frontend setup.
- olavgg 10y ago
  Same thing with Grails, though they've improved support for Angular lately. I prefer vanilla js anyway, its what I used 15 years ago, and it is what I will continue to use the next 15 years and hopefully a lot longer.
  - berdario 10y ago
    OTOH Grails 2 invites people to use the awful formRemotes, which apparently are an idea lifted from old versions of Rails, and are a mishmash of html and javascript. Seems quite an opinionated approach on how you should build your frontend. 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
- bad_user 10y ago
  Of course "not opinionated" in this case is an euphemism and really means that Django doesn't help you at all and so you have to suffer the incomplete and abandoned middleware of others to have something that resembles an asset pipeline. And that's actually odd, because both Rails and Django are frameworks born for building frontends to MySQL databases, which means these frameworks really are about HTTP 1.1 frontend stuff. 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?
  - St-Clock 10y ago
    Right. The frontend story of Django is non-existent and it is a pain to reinvent the wheel each time. Need AJAX to work with CSRF protection? Just copy this snippet of code. Want to use SASS? Try to find a django app that provides an asset pipeline, or copy some django snippets, or do it yourself by bringing grunt/gulp/whatever is the latest hyped js build tool. 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.
jsmith0295 10y ago
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-and-turbolinks.html https://www.nateberkopec.com/2015/05/27/100-ms-to-glass-with...
- wavesplash 10y ago
  Sadly, you can't just remove the gem anymore. At least not if you want to use ActionCable. ActionCable generators only generate Coffeescript.
  - mieko 10y ago
    ActionCable generators can now generate either JS or Coffeescript. This is relatively recent, but the direction is clearly toward decoupling. https://github.com/rails/rails/commit/63ac6255ba3553b529f4b23846ec756b7a7a746d https://github.com/rails/rails/commit/63ac6255ba3553b529f4b2...
AznHisoka 10y ago
Yep, I use Rails to host Sidekiq background workers. Have absolutely no use for the front-end stuff.
- shawabawa3 10y ago
  You might be interested to know Rails 5 has merged in Rails API[0], which strips out most of the front end stuff [0] https://github.com/rails-api/rails-api https://github.com/rails-api/rails-api
matthewmacleod 10y ago
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.
swalsh 10y ago
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.
- danneu 10y ago
  "There is nothing so permanent as a temporary solution"
arnvald 10y ago
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).
- kendallpark 10y ago
  First thing I do when creating any Rails app is take out Turbolinks. It's like autopilot.
  - pbreit 10y ago
    Turbolinks seem really great for the user. What do you not like about them?
    - gobusto 10y ago
      One problem I've run into is that the Javascript state isn't reset when Turbolinks pretend-reloads the page. This can lead to "interesting" bugs if setInterval() calls or websocket-rails response handlers hang around when you navigate away from the page that they "expect" to be run on. 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.
whizzkid 10y ago
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.
ryanSrich 10y ago
Rails philosophy is a full stack framework. Not having to make decisions about your first web app is a huge draw to the framework.
- spriggan3 10y ago
  > Rails philosophy is a full stack framework. Not having to make decisions about your first web app is a huge draw to the framework. 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.
  - deleted 10y ago
    [deleted]
  - dhagz 10y ago
    This is interesting, the problems you're describing are exactly the ones I want to take care of implementing myself. I don't want built-in user management - the way I want to handle users will more than likely vary between projects. I'd rather worry about the implementation of the app than stitching together frameworks to start out. I can go from `rails new appname` to having a working blog in about 15 minutes, which is an awesome way to start a project. Get it working, then worry about whether you want Turbolinks or not. Because starting out, Turbolinks and jQuery are Good Enough™ to get most projects going.
elektronaut 10y ago
It is completely optional, just pass the --skip-javascript option when you generate a new app.
- spriggan3 10y ago
  > It is completely optional, just pass the --skip-javascript option when you generate a new app. This option should be opt in, not opt out which is the whole point of my comment.
lucisferre 10y ago
And asset-pipeline altogether. Replace it with a simple optional gem to integrate with Webpack.
- ch4s3 10y ago
  For all the faults of the assets pipeline, it's dead simple to use out of the gate for a lot of apps. We use webpack and it's a pain sometimes; there's no documentation and when something breaks, good luck finding a fix on GitHub issues or StackOverflow.
wmeredith 10y ago
I agree. It's just cruft I have to work around or rip out.
kendallpark 10y ago
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.

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.
  - sanderjd 10y ago
    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.
    - agmcleod 10y ago
      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.
  - fbonetti 10y ago
    React's server-side rendering solves the blank page issue.
- vinceguidry 10y ago
  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.
- asimuvPR 10y ago
  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.
tlrobinson 10y ago
I prefer Giles Bowkett's dramatic reading version: https://www.youtube.com/watch?v=E99FnoYqoII https://www.youtube.com/watch?v=E99FnoYqoII
hellodevnull 10y ago
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?

zeemonkee3 10y ago

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

olavgg 10y ago
Same thing with Grails, though they've improved support for Angular lately. I prefer vanilla js anyway, its what I used 15 years ago, and it is what I will continue to use the next 15 years and hopefully a lot longer.
- berdario 10y ago
  OTOH Grails 2 invites people to use the awful formRemotes, which apparently are an idea lifted from old versions of Rails, and are a mishmash of html and javascript. Seems quite an opinionated approach on how you should build your frontend. 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
bad_user 10y ago
Of course "not opinionated" in this case is an euphemism and really means that Django doesn't help you at all and so you have to suffer the incomplete and abandoned middleware of others to have something that resembles an asset pipeline. And that's actually odd, because both Rails and Django are frameworks born for building frontends to MySQL databases, which means these frameworks really are about HTTP 1.1 frontend stuff. 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?
- St-Clock 10y ago
  Right. The frontend story of Django is non-existent and it is a pain to reinvent the wheel each time. Need AJAX to work with CSRF protection? Just copy this snippet of code. Want to use SASS? Try to find a django app that provides an asset pipeline, or copy some django snippets, or do it yourself by bringing grunt/gulp/whatever is the latest hyped js build tool. 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.

jsmith0295 10y ago

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-and-turbolinks.html https://www.nateberkopec.com/2015/05/27/100-ms-to-glass-with...

wavesplash 10y ago
Sadly, you can't just remove the gem anymore. At least not if you want to use ActionCable. ActionCable generators only generate Coffeescript.
- mieko 10y ago
  ActionCable generators can now generate either JS or Coffeescript. This is relatively recent, but the direction is clearly toward decoupling. https://github.com/rails/rails/commit/63ac6255ba3553b529f4b23846ec756b7a7a746d https://github.com/rails/rails/commit/63ac6255ba3553b529f4b2...

AznHisoka 10y ago

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

shawabawa3 10y ago
You might be interested to know Rails 5 has merged in Rails API[0], which strips out most of the front end stuff [0] https://github.com/rails-api/rails-api https://github.com/rails-api/rails-api

matthewmacleod 10y ago

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.

swalsh 10y ago

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.

danneu 10y ago
"There is nothing so permanent as a temporary solution"

arnvald 10y ago

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

kendallpark 10y ago
First thing I do when creating any Rails app is take out Turbolinks. It's like autopilot.
- pbreit 10y ago
  Turbolinks seem really great for the user. What do you not like about them?
  - gobusto 10y ago
    One problem I've run into is that the Javascript state isn't reset when Turbolinks pretend-reloads the page. This can lead to "interesting" bugs if setInterval() calls or websocket-rails response handlers hang around when you navigate away from the page that they "expect" to be run on. 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.

whizzkid 10y ago

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.

ryanSrich 10y ago

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

spriggan3 10y ago
> Rails philosophy is a full stack framework. Not having to make decisions about your first web app is a huge draw to the framework. 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.
- deleted 10y ago
  [deleted]
- dhagz 10y ago
  This is interesting, the problems you're describing are exactly the ones I want to take care of implementing myself. I don't want built-in user management - the way I want to handle users will more than likely vary between projects. I'd rather worry about the implementation of the app than stitching together frameworks to start out. I can go from `rails new appname` to having a working blog in about 15 minutes, which is an awesome way to start a project. Get it working, then worry about whether you want Turbolinks or not. Because starting out, Turbolinks and jQuery are Good Enough™ to get most projects going.

elektronaut 10y ago

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

spriggan3 10y ago
> It is completely optional, just pass the --skip-javascript option when you generate a new app. This option should be opt in, not opt out which is the whole point of my comment.

lucisferre 10y ago

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

ch4s3 10y ago
For all the faults of the assets pipeline, it's dead simple to use out of the gate for a lot of apps. We use webpack and it's a pain sometimes; there's no documentation and when something breaks, good luck finding a fix on GitHub issues or StackOverflow.

wmeredith 10y ago

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

kendallpark 10y ago

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.