This Week in Rails: jQuery no longer part of Rails, and more

In a way, it's an end of an era. What jQuery did for the industry when it first came out was amazing. Normalizing differing browser APIs, making cumbersome APIs more palatable, providing powerfully expressive query selectors, enabling fairly trivial plugin development, and the nifty monadic chaining.

Some of those issues have been addressed by browsers, making vanilla JS a little less unreasonable. For other bits, rails-ujs provides some niceties that aren't worth carrying all of jQuery to have. These days most developers will want to use le framework du jour, and don't need jQuery for DOM querying and manipulation.

swalsh• 10 years ago

Let's be honest, jQuery was a patch for the IE6 bug.

xutopia• 10 years ago

It was much more than that. jQuery made difficult things easy and paved the way for future technologies by using browser specific abilities and providing a unified API for developers to use.

It also standardized around a plugin architecture making it easy for people to write code others could easily reuse.

If you think there is only one iE6 bug that jQuery helped alleviate you'd be wrong. There are thousands of quirks/bugs/proprietary crap that jQuery handled for web developers.

Reducing it to an IE6 bug fix is out of touch with reality.

crdoconnor• 10 years ago

It was primarily a saner query language for the DOM.

akhilcacharya• 10 years ago

Never used RoR, was this just used in the scaffolding system?

awestroke• 10 years ago

No, ujs is used to automaticslly implement RoR functions declared in your rails templates. Eg, you can add a confirm attribute to a link, which is then implemented by ujs in the browser, causing a confirm dialog when clicking the link

aamederen• 10 years ago

Can anyone explain when did jQuery start to fall back in the tech era? What were its failures? It is a bit sad to say goodbye to such an old friend.

nikanj• 10 years ago

It just works, and that makes it old and boring. I'm only 40% joking.

untog2• 10 years ago

I don't think there are any failures in it - it could have grown outwards to become what React is today, or something, but it always kept to the principle of doing one thing and doing it well: unifying browser APIs across vendors and simplifying them. (yes, I realise that's two things, but...)

These days there are many fewer differences between vendors, and things like the Fetch API are making the kind of simplifications jQuery pioneered a core part of the browser experience.

jdavis7032• 10 years ago

jQuery to me was always meant as a DOM manipulation library. It didn't fall behind per se, it's just that browsers became good enough and standard enough that you no longer needed this type of tool. I think it would have been a huge mistake for jQUery to have attempted to become a Backbone, Angular or React, because it really was never meant for building web apps (of course you could still use jQuery in Backbone and Angular, and in fact those projects kind of assumed you were using it, or at least something that was API compatible).

ofcapl_• 10 years ago

yup, I've also always used jQuery for ajax requests - a lot simpler/quicker/less-line-er for development than defining plain xhr requests

aindhaden4• 10 years ago

it would have been a huge mistake for jQUery to have attempted to become a Backbone, Angular or React

What would you call jQuery UI?

3131s• 10 years ago

I can't answer that, but I'll say that I still include it in most projects without a second thought. Maybe I'm not aware of some existing superior replacement, but since I don't care much for the popular modern JS frameworks JQuery + vanilla JS is still my goto choice. Following good coding principles, I haven't yet had any project grow to be too messy, but maybe I'm just not working on extremely complex front-ends.

pault• 10 years ago

It didn't have any failures, the browser APIs have just finally caught up with it. I would guess that 99% of jQuery usage was for ajax, event normalization, and CSS selector queries, which are now trivial and cross platform in vanilla JS (with a little help from the fetch polyfill for ajax). I personally haven't used jQuery in a project for at least two years, and I doubt I'm in the minority of front end developers in that regard.

sjwright• 10 years ago

Jquery did two things well: it provided a terse, sane syntax for many common tasks, and it provided robust cross browser support.

Modern browsers have partially solved both these issues. (The former with .querySelector() and the latter with the deprecation of MSIE 6/7/8.)

donw• 10 years ago

Although the comparison isn't perfect, you can think of jQuery as PHP in the late 90s and early 00s.

PHP made web development accessible to the masses. Because PHP is embedded in the HTML itself, it is way easier to work with than Perl or Java, especially in the context of The Web In 1999.

In the same vein, jQuery filled a very important niche when the web was just getting started. It made Javascript accessible, by smoothing out the differences between browsers, and by providing a useful set of abstractions over the mountain of quirks that is client-side Javascript.

Most importantly, jQuery made hard things that people wanted to do stupidly simple.

But in 2016, there are fewer differences between browsers, and more importantly, our knowledge of How To Build Software has massively improved through lots of trial, error, and iteration.

And things that used to be really hard in Javascript are now a lot easier, thanks to improvements in browsers, languages, and tooling... well, the tooling still needs work, but that's a different discussion.

The world that jQuery served no longer exists, and it has largely been replaced by more effective abstractions. It will never truly go away, but neither will it be the choice for most people that are looking to create something new.

dispose134324• 10 years ago

PHP made web development accessible to the masses. Because PHP is embedded in the HTML itself, it is way easier to work with than Perl or Java, especially in the context of The Web In 1999.

PHP didn't make it easy. It made it possible.

Until fairly recently, getting a VPS was insanely expensive, so any learner, hobby, startup went to shared hosting.

As a result, any tech which required starting servers or elevated permissions was out, so Java and ISAPI (remember that?) were out.

So the only choice was PHP/ASP or perl/C/tcl cgi scripts.

cgi scripts had to be located in the /cgi-bin directory, so they looked ugly in the URL and simply wasn't designed for the web (so no url_parsing libraries (but no register_globals!)) and no git/github/blogs/stackoverflow whee to just go and download them.

So one had a choice between PHP and ASP.

ASP costed quite a bit more for the license, so PHP took over the internet.

Eric_WVGG3• 10 years ago

I apologize in advance and mean no disrespect, but I think this analogy is terrible.

PHP was browser-agnostic. PHP was a flawed tool that existed alongside other tools, and survived based on various merits and despite various drawbacks.

jQuery was a life preserver. Javascript is wholly browser dependent, and at the time of its inception, browser compatibility was a jungle full of king kongs and velociraptors.

Before jQuery, your javascript might work. With jQuery, it would work.

Since then, browser compatibility has gotten better, and the language has advanced. Much of what was previously speculative has become basic.

Pour one out for jQuery, but don’t feel sorry for it’s demise; be grateful for where it brought us.

wfleming• 10 years ago

Nikanj isn't wrong (and is funny), but I think the other (more justifiable) reason is that jQuery largely isn't necessary anymore: when it came out, there were an uncountable number of browser incompatibilities that needed painting over, and APIs for remote requests, DOM querying & manipulation and the like were very immature, so a library to make everything usable was extremely valuable.

Now, those APIs are mature & standardized & it's generally not too hard to write vanilla JS that works across all the major browsers.

I don't think jQuery has failed, but for the kind of baked-in functionality Rails wants it's not really needed, and there are good reasons not to pack another dependency into your framework if it will increase page download size & is increasingly unlikely to be used by the framework's users.

dom0• 10 years ago

Exactly. For my little JS needs I just use vanilla JS (even though the APIs are poor and the language is worse), since it will very likely work across all browsers I care about (recent FF/Chrome/Edge).

mercer9• 10 years ago

I recall reading that element.querySelector(All) was inspired by jQuery. If true, it means jQuery was so much of a success that parts of it were implemented natively in browsers!

(I couldn't confirm this by googling, so if anyone can confirm or deny that this is the case I'd love to know!)

fusiongyro• 10 years ago

jQuery is for adding behavior to web _pages_. It thrived in the era where most web development happened on the backend and frontend development was really about sprinkling interactivity and effects onto a page. jQuery does not supply powerful-enough abstractions for writing applications. Early attempts to layer MVC on top of jQuery did not meet with much success; Angular and other libraries used it initially for DOM manipulation but as time went on they mostly found ways to drop the dependency.

I still think that if you're building _pages_ instead of an application, you should consider it. Plus, it is a great tool for understanding and manipulating the DOM. I think it will continue to be popular with casual web developers for a long time, although frontend engineers have probably not been using it for years. I think the death of jQuery is exaggerated, but only time will really tell.

Eric_WVGG3• 10 years ago

jQuery never fell back. It’s whole raison d'etre was to be a crutch. The rest of the industry stepped up.

aphextron• 10 years ago

It is a bit sad to say goodbye to such an old friend.

I see this as more of correcting a poor design decision on the part of Rails, rather than having anything to do with the relevance and usefulness of jQuery today.

TheAceOfHearts• 10 years ago

If you're just targeting modern browsers, You Might Not Need jQuery [0]. jQuery was great when dealing with browser inconsistencies and when all you had to do was wire up a few things.

If you're building a marketing website or a lightweight app, I think using jQuery is fine. But if you're building anything more sophisticated, like a highly interactive web app you'll probably skip on jQuery and just use React or something similar.

I think context is very important. Are you building something that is being maintained by multiple engineers? Does it have to accommodate regularly changing requirements? You can go really far with server-side rendered Rails and a few bits of jQuery thrown into the mix. But once you're past that point, embracing the ecosystem becomes more useful.

[0] http://youmightnotneedjquery.com/

LostInTheWoods2• 10 years ago

jQuery isn't dead, and wasn't a failure. It is still widely used and probably will be for some time to come. There are many different types of web projects! For those that require more than vanilla js, and less than a full blown framework (Angular, etc.), jQuery still has its place.

marclave• 10 years ago

Really interesting, the replacement is a vanilla js implementation called rails-ujs and was made by someone who went through Google Summer Of Code!

"The new rails-ujs was developed by @liudangyi as part of Google Summer of Code, all credits for this goes to him and to his mentor @pixeltrix " - https://github.com/rails/rails/pull/27113

jon-wood• 10 years ago

rails-ujs has been around for a long time (I want to say since the Rails 3 era, but not certain), the change here is to move that from jQuery to vanilla JS, just as back in the day it was once migrated from Prototype.js to jQuery

untog2• 10 years ago

jQuery is/was incredible, and deserves every single bit of praise heaped upon it. But it is nice to see coding going back towards "vanilla" JS - it wasn't so long ago that every JS answer on Stack Overflow just assumed you were using jQuery and you struggled to find an answer that didn't require it. That's not the case any more.

bezzi• 10 years ago

Now they just need to replace coffeescript with es6/babel.

anonova• 10 years ago

`--webpack` and `--yarn` are both coming, so they definitely seem to be headed that way.

[1] https://github.com/rails/webpacker [2]: https://github.com/rails/rails/pull/26836#issuecomment-26424...

BinaryIdiot2• 10 years ago

I'm not a fan of CoffeeScript but do they really need to lug the huge amount of dependencies babel brings along with it? Why not target ES5 with some ES2015 sprinkles in depending on compatibility and slowly work towards ES6?

paublyrne2• 10 years ago

I'm not sure how you slowly 'work towards' ES6. Unless you decide to only support bleeding edge browsers, you cannot use ES6 or ES7 features in production applications.

The only way we can use them is through transpiling. This will be the case for at least another three or four years.

mythz7• 10 years ago

Pour one out for jQuery!

jQuery was a major productivity boost when first released but it didn't scale well and encouraged creation of tightly coupled glue code. It's decline being the result of evergreen browsers maintaining good parity where "vanilla JS" is now a feasible option and from it no longer being needed in the premier JS SPA frameworks which scales better and allows for the creation of better componentized and modular code-bases.

In someways we've digressed significantly and made it ridiculously more complicated to build a modern web app in contrast to what jQuery gives you out-of-the-box with a simple script include. Now to create a basic Angular2 App you need to download 32k+ files from npm and become an Angular2 build master just to setup your development environment and configure your package/deploy scripts.

You can still go a long way with just Bootstrap + jQuery - which would still be my goto if I just need to spruce up a web page with some behavior. Although that's happening less and less and find myself reaching for VS.NET/TypeScript/JSPM/React as my choice SPA stack which scales well with a great ecosystem, minimal complexity and maximum utility.

MrBra• 10 years ago

minimal complexity

compared to?

mythz7• 10 years ago

The premier SPA frameworks: Angular/2, Ember, Polymer, Aurelia, Knockout,...

Fundamentally React has a one major concept "Components" which is very easy to create and JSX gives you the full power of JS without needing to learn the nuances of a crippled templating language. I use Redux to manage state which like React is simple and extremely powerful and centralizes all your App's state in clean data structures. E.g. with very little effort you can create a "Networked Time Traveller App" [1].

I also believe React's "Learn Once, Write Anywhere" approach lets you get maximum utility for your existing knowledge and decent code-reuse where you can use it to build cross-platform native iOS/Android Apps with arguably a more productive development workflow than the native iOS/Android toolkits on offer, although it's still a bit immature atm but has great momentum with a bright future.

[1] https://github.com/ServiceStackApps/typescript-redux

pavlov• 10 years ago

It's not just Angular. I really do like React, but the ecosystem complexity is staggering there as well.

Facebook's "create-react-app" tool does a great job of packaging all the pieces... But the cost is apparent when looking at the size of an empty create-react-app boilerplate app:

85,174,715 bytes (148.8 MB on disk) for 23,387 items

This is on Mac, so the wasteful HFS+ file system means that an empty web frontend project takes up 150 MB of disk space. Each project I make with create-react-app will have this same overhead. That's fairly incredible.

People think C++ is complex, but a full C++14 compiler and dozens of libraries will fit in less space than a web boilerplate.

mythz7• 10 years ago

Yep React's also culpable to npm's "micro module" madness, where often the scope of a npm package is wrapping a single function! Which explains why blank SPA templates requires 1000's of files.

But I've got my choice SPA stack down to a solution I'm happy with, where a blank App is down to:

   - TypeScript (using Type Definitions in npm package or @types)
   - JSPM (package/dep management, module loader + bundler)
   - Gulp (automate all tasks in reusable scripts)
   - React

JSPM `bundle` feature also lets you combine all React's deps into a single .js file which speeds up iterative dev workflow by combining the 100's of runtime dep requests down to 1 .js file.

Also using jspm@beta means I don't have to configure a separate tool like Webpack as JSPM reuses your dependencies where its 'build' feature rolls up your app into a single stand-alone, minified .js file to give you an optimal packaged app for deployment.

Using the TypeScript integration in VS.NET means I don't have to run any external processes or watchers as TypeScript automatically re-compiles every modified .ts file on save where it's ready by the time I reload the page.

Unfortunately it looks like npm has passed the point of no return and every developer is stuck building on this complexity. Honestly if it wasn't for the potential of React Native I'd strongly consider moving to Vue.js (https://vuejs.org/v2/guide/) since it's still a modern well supported SPA fx, but lets you reference a single script include. Ideally React would offer a simplified solution where it also maintains a parallel "react-dev" npm package with no deps, but it's unlikely since it goes against npm's micro module madness trend - but it's something I'm keen on exploring if I ever get the free time.

k__• 10 years ago

I only used jQuery through Ember, never directly.

It seemed to me, that the problem of jQuery wasn't how it was designed, but how it was used.

I mean, if you simply use it to "directly" do your thing, without any framework/modularity pattern, you gonna have a bad time.

But you could simply assume jQuery was the "browser API" and build your application framework on top of it, like Ember and others did.

I mean, even the Sencha devs did their own abstraction layer and built their frameworks on top of it.

mythz7• 10 years ago

jQuery still boils down to mutating DOM state, forcing you to become a bookkeeper where you have to carefully ensure your App's state and rendered DOM are in constant sync and you also have to deal with interim state transitions where it's easy to run into bugs for state transitions you've never tested or thought about, which gets complicated quickly.

React's Virtual DOM means you only have to care about the representation of a given state and React takes care of transparently and optimally handling all the DOM mutations required to sync the DOM with your App's state. React also has great componentization making it natural and easy to encapsulate reusable logic. The benefits really stand out in medium to large code-bases where it scales much better than jQuery. It's still ok for Apps maintaining little state, but there's a large class of Apps I'd never consider creating in jQuery which I've found trivial to develop with in React.

mattmanser• 10 years ago

There was never a 'problem' with jQuery apart from that it's quite a heavy file, especially for mobile, and some people want to stop having to download it.

It's never been faced by the problems that backbone, angular, react, etc. where they rapidly die as soon as something else comes along, because it's a well built utility library, not a framework that had to include nasty hacks to work.

But, technically, there are no problems with it. If it were included by default in browsers, everyone would still be using it over vanilla javascript as even the new vanilla javascript has really poorly designed and wordy APIs.

mercer9• 10 years ago

In someways we've digressed significantly and made it ridiculously more complicated to build a modern web app in contrast to what jQuery gives you out-of-the-box with a simple script include.

That's true, but I find that things are complicated because either 1) the complexity is higher because we're dealing with a proper app, in which case jQuery wouldn't be much simpler (you'd probably use Backbone.js at the very least, and that gets messy quick), or 2) people use a lot of 'state of the art' stuff that they don't really need.

In regards to 2: if what you need to do can be done with a script tag and jQuery, you probably wouldn't need anything beyond 'plain' React and it would still be a benefit. And if you go for something like Preact, the download size is smaller than jQuery, so you could even consider using both at the same time; preact for dom updates, and jQuery for everything else.

More and more I find myself opting for (p)react even for simple things like a slideshow widget or a tabbed element. I find it nicer than jQuery and if you avoid using all the 'cool stuff' (redux, etc.) it's simpler too.

michaelbuckbee• 10 years ago

I think what drives me nuts is that so often jQuery+Bootstrap would deliver a faster quicker product. While the big frameworks are incredible, they really are designed [1] for really large applications, ala Angular and Gmail. But, I see them being pushed onto what would otherwise be very simple projects: static websites, sites with a single contact form, etc.

1 - http://www.planningforaliens.com/blog/2016/04/11/why-js-deve...

arenaninja2• 10 years ago

Yeah I get flak when I still use jQuery in new projects. Why do I use it? It fucking works, with no need to depend on npm, the application is a lot snappier than using Angular.

If I move on from jQuery, it won't be to Angular. I tried React, but I also found it too much boilerplate. I'm trying VueJS next.

spiderfarmer• 10 years ago

I've noticed that the people that ridicule you for using stuff that works (like jQuery) are the same people that have trouble maintaining their own older code, because they'd much rather just start over.

paulddraper2• 10 years ago

Why do I use it? It fucking works

Nowdays that true of vanilla JS. (Didn't use to be.)

addEventListener, documentQuerySelector, XMLHttpRequest...yes not everything is a one character function name ($), but it's all quite usuable if you value barebones-no-dependency simplicity.

ukyrgf• 10 years ago

The other day I downloaded project files from somebody and extracted it to my Dropbox folder before realizing it had a node_modules folder... crashed Dropbox on every single computer I had attached to it. I have to do the full Git remote repository push/pull dance, with each PC 'npm install'ing, just to work on any small project that might be related to Node.

mouzogu• 10 years ago

i still personally find vanilla js quite cumbersome for dom manipulation but that's partly because i've grown used to the jquery way.

mercer9• 10 years ago

Yeah, it's a bit more verbose, although some of that can be alleviated with a helper function or two, well enough that it's worth it for me in many cases.

But I still regularly find myself just using jQuery for convenience, as there's still a bunch of gotchas with plain js.

For example, I rather liked the event.path property to deal with event bubbling, only to discover that safari (mobile, at least) doesn't support it. Adding a helper function for that was trivial, but it's still one extra thing to do, and it makes it just a bit harder for other devs to get going. I ran into a number of these minor issues.

kimshibal• 10 years ago

why not replace jQuery with zepto?

ralmidani• 10 years ago

I use Ember on the client-side. Inside components, jQuery is still very relevant for things like form input masks, Bootstrap plugins, etc.

jQuery continues to save countless hours over using vanilla JS. And it's even better when you use it with CoffeeScript.

somecallitblues4• 10 years ago

I will personally continue to use jQuery for many years to come. It's a lot of power in few concise lines of code and it really makes sense. And it comes at the cost of a single request. For the small amount of JS my sites use its perfect. I don't know why everyone in thread is saying goodbye to jQuery. Are that many people coding in vanilla JS?

rajangdavis5• 10 years ago

I think it just depends on what type of web application/site you are making.

For a simple site, it's probably not that big of a deal to hook in jQuery and write some basic scripts.

In my limited experience, if you are writing a Single Page Application, it gets really hard to rationalize changes when everything is hooked in through the DOM. It also gets pretty expensive with mobile browsers as DOM elements carry a huge list of properties and attributes; this why I think libraries like React were made as to have data change and manage state as opposed to the DOM.

At the end of the day, the end user and businesses don't care about what technologies that you use, they just want a site that works and can be delivered on time. I just think that with jQuery, there is a lot of cost in terms of making complex changes in the view that other libraries such as React/Angular/Mithril have been designed to get around. These libraries, however, do have a cost in terms of complexity that I think jQuery never really had.

somecallitblues4• 10 years ago

I agree with you about jQuery getting quickly out of hand if you want to create something like a one page app and you should certainly use something like React or Angular. I do use it. But to do a quick Ajax post, read some data and display a message or show and hide something jQuery is awesome. To tie a quick event listener to a dropdown and do something or to find children of some element jQuery is still few lines of code that don't even need to be cross browser tested. Using vanilla JS for these things when you can do this in few lines of jQuery code seems masochistic.

TekMol3• 10 years ago

I use plain JS.

Can you give an example of a typical line of jQuery that you prefer over vanilla?

somecallitblues4• 10 years ago

See my reply child post. But anything from tying a quick event of any kind to an element and posting a form using Ajax and consuming the response, doing quick show and hide. And the ease of implemting a million different plugins for all kinds of things, from morals to slides, in this jQuery is still a champ.

adamlett• 10 years ago

JQuery still smoothes over browser inconsistencies. For instance, I was recently bit by this:

https://connect.microsoft.com/IE/feedback/details/878564/ele...

mercer9• 10 years ago

I have an example to which maybe you or someone else can suggest a better 'vanilla' solution. Would love to hear suggestions.

With jQuery I'd often do

    $(<root-element>).on('click', <target element>, callback);

crucially, because events bubble up, even a click on a child element of <target element> will register as a click on the target element.

in plain js it doesn't seem to work that way. I'd do <root-elem>.addEventListener(), but I'd run into the problem that the event.target would point at the exact element that was clicked on instead of the parent element that I wanted to register clicks on.

Given the structure ".item .inner .title", I can't just check if event.target.classList contains 'item', because it might only contain 'title' or 'inner'.

event.path to the rescue! I can simply check if any of the parent nodes do contain the 'item' class. Except event.path doesn't work in safari mobile, so it needs a polyfill. Plus on every event handler I have to go up event.path to check.

Obviously it's not that hard to write a helper function that basically emulates .on(), but I can't help but feel that I'm maybe missing some simpler, plain solution. Any suggestions?

lojack• 10 years ago

Maybe check out Zepto. It aims to have the same API as jQuery without all the debt of supporting older browsers. I still prefer to use jQuery over vanilla JS, but often I'm building apps that'll only be used on evergreen browsers, so that tends to be a better choice for me.

rajangdavis5• 10 years ago

jQuery was the my first language that got me into coding; I had started javascript but it became very difficult to write a short amount of code for some basic things that I was working with back in 2012.

Ruby on Rails was my first framework for developing web applications. I still use it today, but would remove jQuery as a dependency. I thought it was strange how much of dependency it was for certain things like deleting objects for Rails; I guess it was the right tool for the time.

jQuery is/was a beautiful thing in that it was a concise and fairly nice API for interacting with the DOM. I feel like it was the right tool for the time but now a lot of developers have come to learn the cost of DOM interactions especially with mobile browsers. I am not too certain about ES6 but that stems from my ignorance and not any technical concerns.

I think that while there has been strides in understanding how to make rich clients with javascript without performance issues, I do not think there has been anything as simple as using jQuery. I prefer to use Angular now or vanilla javascript if it is a small scale application and while I like/understand Angular, it took an incredible amount of time and work to properly understand what I was doing. Vanilla js can be incredibly performant, but often times I have had to write 3 times the amount of code to get something going which is a costly in time and maintenance.

jQuery was literally something that took a day for me to understand as non-developer. I hope as javascript progresses that API developers focus on simplicity and ease of use when creating the next big javascript framework.

dvdhnt• 10 years ago

Javascript is a language; jQuery is only a library written in javascript.

I will concede its API became so ubiquitous that it morphed into some kind of pseudo-DSL.

tn13• 10 years ago

Why is everyone on this thread talking if this is an obituary for jQuery. jQuery is pretty amazing and will continue to be the most popular framework out there for a long time to come. It is just that rails wont ship with it by default.

michaldudek• 10 years ago

I'm not a Ruby/Rails dev, but why the hell was it ever included? :o Isn't Ruby a backend language and Rails a backend framework? :o

paublyrne2• 10 years ago

It's a full stack framework. You can include JavaScript for your views, probably most commonly used to show, hide, and insert and remove elements from the DOM.

aindhaden4• 10 years ago

To expand on this, the tool of choice for the frontend part used to be PrototypeJS. In Rails 3.1 the relevant portions were decoupled and became options rather than baked-in, with jQuery as the default but still an option among several: http://weblog.rubyonrails.org/2011/4/21/jquery-new-default/

rajangdavis5• 10 years ago

I think it was included because it was consistent across browsers.

There's some weird Rails specific things that I am not too sure make sense (like having the ability to use DELETE as a data method for a hyperlink) but make CRUD apps simple to follow in terms of the Rails way-of-thinking.

I'd have to check the source, but I think it was also used for AJAX forms. I think the safe answer is that Rails is great to create something quick but the built-in helpers aren't always very sane.

proyb2• 10 years ago

I only use flexbox in CSS and Svelte for raw JS, less code and speedier workflow. It's more easier when combine Svelte with Redux and transpile with Rollup. With Sever-side Rendering include, this is so much better and doesn't force me to stick to one framework.

pritambarhate• 10 years ago

I somehow still seem to need jQuery. Mainly because I need to use a UI component, and out there one already exists, which does exactly what I need. So jQuery gets in as a dependency. Maybe because I have used it for more than 8 years now, I seem to know the jQuery based components well.

Especially times when one needs things like https://fullcalendar.io/ and Kendo UI jQuery becomes a required dependency.

To those, how to you program enterprise systems, without jQuery? Do you any mature UI toolkits which don't depend on jQuery? I am genuinely interested in knowing about these.

cmg2• 10 years ago

I build pretty simple sites on the public side - mostly restaurants and gyms and other small businesses. I've been moving away from jQuery for everything except my ecommerce sites over the past few months.

The back-end administrative panel of those sites is more complex. It uses Bootstrap, so there's some incentive to include jQuery there, though I don't always use features that require it. But this is an area I struggle with as well - there are so many external components, like date and time pickers, drag & drop image uploads, etc, that aren't easily replaced with vanilla JS components that have feature parity. Curious to see what others have to say about this as well.

hacker_9• 10 years ago

Funny how people here are saying goodbye to jQuery. I'm saying goodbye to Rails.

aantix• 10 years ago

Why is that?

susan_hall• 10 years ago

I loved jQuery when it first appeared, but it is from another era, for sure. The rise of the Single Page Application was one big strike against jQuery. Frameworks such as Angular 1.0 emerged which relied on jQuery, and the software built with those frameworks revealed the dangers of mutable state, especially when combined with something async like Ajax. Anyone who has worked on a large Javascript project is eventually burned by mutable state. Then other frameworks such as React and Om Next emerged, which advocated for immutable data. The team behind Angular realized their mistakes and tried to fix them, so Angular 2.0 was a radical re-write of Angular 1.0, and yet despite that, more and more developers continued to flock to something like React. The immutable frameworks offer the idea that all state should be held in a single immutable atom, and the views should merely be straight reflections of the state that is held in that atom. One could still potentially use jQuery in the background to handle the actual update of the DOM elements, but there are many other ways of updating DOM elements, and many of those other methods are more efficient than jQuery, so jQuery's importance has declined.

Back in 2007, if you wanted to add some simple visual effects to your CRUD app, then jQuery was like a gift from God. But nowadays, given the complex systems that people are building, jQuery has less to offer. It never had an opinion about managing state, so it leaves the core question of building a large app to other frameworks, and those frameworks have various built-in ways of updating the DOM, so the ease-of-use offered by jQuery is no longer such a noticeable advantage.

This Week in Rails: jQuery no longer part of Rails, and more

Related Stories