Drop jQuery as a dependency from Rails
github.com
github.com
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 also not sure I'd call document ready the most fundamental as a lot of people (including me) used to use onclick='' and onload='' directly on elements back then when we all loaded script tags in the head.
But I didn't hit them, because I mostly did everything on the server side.
When I switched to SPAs, I used ExtJS.
Then ExtJS, then a short stint with Ember and after that React.
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 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 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...
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.
https://github.com/jquery/jquery/blob/3.0.0-rc1/dist/jquery....
--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-keepshttp://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...
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.
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.
This option should be opt in, not opt out which is the whole point of my comment.
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.
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 do agree that it should get out of default Rails. GJ community.
This single comment absolutely confirms that point of view: https://github.com/rails/rails/issues/25208#issuecomment-222...
I honestly can't believe a back end framework has minimum supported browser requirements that are basically "use the latest or GTFO".
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.
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.
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.
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.
I think you're seeing the web through SV tinted glasses.
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.
For me, it was the amount of magic involved in everything. I'm just glad I gave up and moved onto other things.
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.
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 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).
Browser support for fetch is still pretty weak, so you'll need some kind of polyfill to use it today.
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.