Drop jQuery as a dependency from Rails(github.com)
github.com
Drop jQuery as a dependency from Rails
https://github.com/rails/rails/issues/25208
122 comments
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.
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.
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.
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....
https://github.com/jquery/jquery/blob/3.0.0-rc1/dist/jquery....
It does help with browser quirks, but if you aren't supporting <IE10, then you really don't need it. I've made it a point to pull out jQuery from every project I have. Nowadays, I can test in Chrome as I develop and then test any other browsers at the very end and I rarely have any browser specific bugs. Crazy how far web dev has come.
You do really need it, at least for me. I'd rather write $ sign calls instead of getElementByID or querySelector just to start with. The sizzle library in jQuery is so advanced, that you can't do complex queries on the dom yet with today's browser.
There are small libraries that help with making native DOM operations more jQuery-like. We opted just to write our own since we didn't need a good portion or even the smaller libraries.
the industry is moving away from direct DOM mutation and towards v-dom, so this isn't an issue for a lot of devs.
Reading the Jquery source code is fun. It seems like they're doing some really clever stuff there. For example, look at isEmptyObject in the code you linked.
What's the particular cleverness in that? It seems it would also fail for objects with non-enumerable properties and properties with ES6 Symbols for names.
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)
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)
If you've been a web dev for 10 years then you'll know that the most fundamental tool for scripting is a pain point (document ready), jQuery did a good job of abstracting the nuances away, see: http://stackoverflow.com/questions/799981/document-ready-equ...
And the incompatible ajax interfaces. And the inconsistent element selection. And the...
I'm also not sure I'd call document ready the most fundamental as a lot of people (including me) used to use and directly on elements back then when we all loaded script tags in the head.
I'm also not sure I'd call document ready the most fundamental as a lot of people (including me) used to use and directly on elements back then when we all loaded script tags in the head.
I know these problems, yes.
But I didn't hit them, because I mostly did everything on the server side.
When I switched to SPAs, I used ExtJS.
But I didn't hit them, because I mostly did everything on the server side.
When I switched to SPAs, I used ExtJS.
Document ready is hardly the most fundamental “tool” for scripting, and it has always been easy to resolve in a cross-browser way: stick your scripts before </body>.
I would say no. It's everywhere. Even as you mention it's a common dependency or comes bundled with a lot of stuff. I have not sat down and written logic that "does the same thing in more than one browser" in a very long time but I'd venture to guess the part of jquery that is browser javascript api abstraction is still very relevant today.
Interesting :)
To me it always felt kinda strange seeing all these jQuery Stackoverflow questions and answers.
When I switched from server side rendering to SPAs, I had the impression everyone was already hating on jQuery and avoided it. I read "Pro JavaScript Techniques" and "JavaScript the good Parts" and started my JS career :)
ExtJS 4 came out and I did my first SPA with it.
Later I did some university projects with Ember, which seems to use jQuery, but I never had to call one of its functions directly.
After that I started freelancing and ended up in a React project, which I found kinda nice to work with.
To me it always felt kinda strange seeing all these jQuery Stackoverflow questions and answers.
When I switched from server side rendering to SPAs, I had the impression everyone was already hating on jQuery and avoided it. I read "Pro JavaScript Techniques" and "JavaScript the good Parts" and started my JS career :)
ExtJS 4 came out and I did my first SPA with it.
Later I did some university projects with Ember, which seems to use jQuery, but I never had to call one of its functions directly.
After that I started freelancing and ended up in a React project, which I found kinda nice to work with.
So did you do JS development back in 2006 without jQuery?
I started with Prototype. Not sure if it came out before or after the first jQuery, but it was the cool kid for a while. Then the world realized it was a disaster and started moving to jQuery...
Too bad Magento devs missed that newsflash. Nowadays it still bundles Prototype.js, and every theme and 50% third-party modules you install carry their own copies of jQuery, all at different versions, placed in random locations, and embedded into the page differently.
I know a bunch of devs who always preferred Mootools and never did jQuery.
I did, then Safari 1.0 happened, and we all went screaming for a solution. Praise jQuery.
The first few years I did PHP without much client side scripting.
Then ExtJS, then a short stint with Ember and after that React.
Then ExtJS, then a short stint with Ember and after that React.
Ah, ok, so you're not a 10 year JavaScript developer, that's very different thing. If you were doing DOM manip 10 years ago without jQuery / MooTools / Dojo / YUI you would be someone that loves pain.
Yes.
I started with learning vanilla JS and doing my professional stuff with ExtJS.
But as you say, jQuery wasn't a requirement. I knew a few people who hated it with passion back then, they were all using MooTools. That's probably why I avoided it...
I started with learning vanilla JS and doing my professional stuff with ExtJS.
But as you say, jQuery wasn't a requirement. I knew a few people who hated it with passion back then, they were all using MooTools. That's probably why I avoided it...
What was your experience with Ext? I had to use it for a few years, and was never a huge fan. We ran into a lot of obscure bugs in their code which resulted in a number of hackaround "Ext.Overrides," and their support forums (Mitch Simmeons in particular) is a joke.
Which version did you use?
I only used ExtJS 4 and 4.1
I liked their API documentation and the xtypes that allowed for declarative Views. React reminded me of this later.
I only used ExtJS 4 and 4.1
I liked their API documentation and the xtypes that allowed for declarative Views. React reminded me of this later.
I started on 3(.5?) and helped with a migration to 4 (which was a disgusting mistake of a process on our end). I like the format of their docs -- JSDuck was my favorite docset for a quite a while. I also enjoyed their methodology for constructing views and view hierarchies. Ultimately, I'd say I was a fan of what they were doing, I just think the implementation was rather shoddy, and the docs were frequently wrong or outdated, and (as mentioned) support was not good. When I got to React, it actually did bring back some memories of Ext, but without the full MVC hierarchy around views.
Ah yes.
I read about those problems.
First they changed the license then the switch from 3 to 4.
This cost them many customers.
I started with 4, so I didn'T encounter these problems.
I read about those problems.
First they changed the license then the switch from 3 to 4.
This cost them many customers.
I started with 4, so I didn'T encounter these problems.
Yes
For everyone who thinks rails installs too much by default, and hasn't ever tried `rails -h` - here are some options:
--skip-gemfile --skip-git --skip-keeps --skip-active-record --skip-sprockets --skip-spring --skip-javascript --skip-turbolinks --skip-test-unit
--skip-gemfile --skip-git --skip-keeps --skip-active-record --skip-sprockets --skip-spring --skip-javascript --skip-turbolinks --skip-test-unit
The --skip options are handy. For reuse, they can be put into ~/.railsrc, e.g.
--skip-gemfile
--skip-git
--skip-keepsRails 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.
You're missing the central point of default rails stack.
http://david.heinemeierhansson.com/2012/rails-is-omakase.htm...
http://david.heinemeierhansson.com/2012/rails-is-omakase.htm...
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.
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.
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.
While I wouldn't use vanilla rails & UJS much today, I still think it has value in getting things going.
React's server-side rendering solves the blank page issue.
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).
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?
Most sites require jQuery, most developers are happy using it, why put the effort into getting rid of it?
I prefer Giles Bowkett's dramatic reading version: https://www.youtube.com/watch?v=E99FnoYqoII
This is one of the best things about Django - outside the admin interface it's not opinionated about your frontend setup.
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?
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?
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.
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.
Take away templates and add Django Rest Framework and you have a very capable platform for building large CRUD APIs complete with models, permissions, serializers and so forth.
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.
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.
> 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.
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.
Re: websockets/push, another thing you can do is run two frameworks side by side. A load balancer like HAProxy can be used to unify the two, if needed.
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.
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.
Django wants to provide solutions that will stick around for longer than the attention span of the js community ;-)
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.
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.
Django models and migrations are very nice to work with. The Django Rest Framework and new Channels (aka sockets) functionality are quite nice. Getting usable, free user accounts and admin is a pleasure. Why not use Django?
> why use Django at all?
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.
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.
I've found this problematic in Django: How to integrate a good JS frontend that isn't at odds with the built-in templating system. Offloading the templating to React (eg. node / JSX) seems like a good bet -- but then your Django app is little more than a REST API.
I'd love to see some good, practical examples of a full-featured (ie. integrated) Django app with a js frontend. Pointers welcome!
I'd love to see some good, practical examples of a full-featured (ie. integrated) Django app with a js frontend. Pointers welcome!
Python is a good language for writing glue code. Django abstracts a lot away with its ORM. If you stick to just providing an API, you'll still get some help from it.
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.
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.
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.
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
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
Django models are nice and easy to work with for the most part, and the template inheritance is great for building out front-ends. But there's a lot of "Django magic" that goes on behind the scenes so I tend to think of Django as an opinionated front-end. Django forms and how they are handled give me nightmares.
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...
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...
Sadly, you can't just remove the gem anymore. At least not if you want to use ActionCable. ActionCable generators only generate Coffeescript.
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/63ac6255ba3553b529f4b2...
https://github.com/rails/rails/commit/63ac6255ba3553b529f4b2...
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).
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).
First thing I do when creating any Rails app is take out Turbolinks. It's like autopilot.
Turbolinks seem really great for the user. What do you not like about them?
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.
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 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.
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.
> 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.
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.
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.
[deleted]
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.
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.
"There is nothing so permanent as a temporary solution"
Yep, I use Rails to host Sidekiq background workers. Have absolutely no use for the front-end stuff.
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
[0] https://github.com/rails-api/rails-api
It is completely optional, just pass the --skip-javascript option when you generate a new app.
> 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.
This option should be opt in, not opt out which is the whole point of my comment.
And asset-pipeline altogether. Replace it with a simple optional gem to integrate with Webpack.
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.
I agree. It's just cruft I have to work around or rip out.
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.
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!
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.
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.
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.
I do agree that it should get out of default Rails. GJ community.
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.
This single comment absolutely confirms that point of view: https://github.com/rails/rails/issues/25208#issuecomment-222...
This single comment absolutely confirms that point of view: https://github.com/rails/rails/issues/25208#issuecomment-222...
Lots of websites have those browser requirements. Many of them aren't written in Rails. Care to explain your "absolutely confirms" logic?
Lots of websites require a browser that was released in the last 2 1/2 years?
I think you're seeing the web through SV tinted glasses.
I think you're seeing the web through SV tinted glasses.
Sure, since all major browsers auto-update now. This has been a thing for years.
https://technet.microsoft.com/en-us/library/dn531055.aspx
http://meta.stackexchange.com/questions/56161/which-browsers...
https://support.google.com/mail/answer/6557?hl=en
https://support.google.com/a/answer/33864?hl=en
http://www.amazon.com/gp/help/customer/display.html?nodeId=2... (notable exceoption for IE8, would love to know the reason)
etc.
https://technet.microsoft.com/en-us/library/dn531055.aspx
http://meta.stackexchange.com/questions/56161/which-browsers...
https://support.google.com/mail/answer/6557?hl=en
https://support.google.com/a/answer/33864?hl=en
http://www.amazon.com/gp/help/customer/display.html?nodeId=2... (notable exceoption for IE8, would love to know the reason)
etc.
Sure, DHH said it himself. Rails is for basecamp like apps. Whats the deal?
But is it "for Basecamp like apps". Or is it "for the Basecamp app"?
I honestly can't believe a back end framework has minimum supported browser requirements that are basically "use the latest or GTFO".
I honestly can't believe a back end framework has minimum supported browser requirements that are basically "use the latest or GTFO".
It is for "most web apps" because most web apps are like basecamp, and it isn't "use the latest or GTFO". It is "use the latest by default or add a single line to your gem file if you want to support older browsers."
Most web apps are only tested on the latest browsers anyway, even if they claim to support older browsers. This is true unless you have a very popular app and a very large team.
Most web apps are only tested on the latest browsers anyway, even if they claim to support older browsers. This is true unless you have a very popular app and a very large team.
> Most web apps are only tested on the latest browsers anyway
I've worked in web/related fields for about 10 years now, and I've never worked on a project where "fuck it, the latest will do" has been acceptable.
I've worked in web/related fields for about 10 years now, and I've never worked on a project where "fuck it, the latest will do" has been acceptable.
Yeah, same here. This comment thread is bizarre. I've been writing web apps that serve an industry where users don't install their software but their IT department does on their behalf: hospitals, but schools and government agencies are very similar, as well. Many of these apps are required to support back to IE8. For better or worse, that is the world some of these apps must live in.
> This is true unless you have a very popular app and a very large team.
Or you have very important and lucrative clients in government, healthcare, or some other crusty large organization with horribly dated browsers they're not going to replace any time soon. That quickly makes you throw away the latest React-* solution and reach for jQuery, however much you rage inside.
Or you have very important and lucrative clients in government, healthcare, or some other crusty large organization with horribly dated browsers they're not going to replace any time soon. That quickly makes you throw away the latest React-* solution and reach for jQuery, however much you rage inside.
Which is not true. Most frameworks have good support for legacy browsers.
And when some library fails in an old browser is always something so small that I end up making a PR and getting it fixed the same day.
And when some library fails in an old browser is always something so small that I end up making a PR and getting it fixed the same day.
It doesn't. jquery-ujs will still be there if you want it, but depending on jquery brings along a lot of baggage along with the legacy browser support it allows. This discussion is just about what the default should be, and I don't think its unreasonable these days to aim for modern browsers as a default for most sites.
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.
For me, it was the amount of magic involved in everything. I'm just glad I gave up and moved onto other things.
An irrelevant framework drops another irrelevant framework as a dependency.
Omakase implies a certain level of excellence in all the individual choices.
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.
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.
We detached this subthread from https://news.ycombinator.com/item?id=11814018 and marked it off-topic.
alexnaspo(2)
astrowilliam(1)
dboreham(2)
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.
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.
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.
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.
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.
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.
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.
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).
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).
> The XHR wrapper can easily be replaced with the fetch API.
Browser support for fetch is still pretty weak, so you'll need some kind of polyfill to use it today.
http://caniuse.com/#feat=fetch
Browser support for fetch is still pretty weak, so you'll need some kind of polyfill to use it today.
http://caniuse.com/#feat=fetch
Right. My argument is that you could fork the relevant subset of jQuery and own your own compatibility story in the event that Rails wants to push this on apps for some reason (I don't see the benefit of that).
An alternative would be to initiate a discussion with jQuery as obviously Rails isn't the only framework that's dealing with this issue. Let the jQuery guys do what they're great at, let Rails do what it does.
An alternative would be to initiate a discussion with jQuery as obviously Rails isn't the only framework that's dealing with this issue. Let the jQuery guys do what they're great at, let Rails do what it does.