11 ms·
This Week in Rails: jQuery no longer part of Rails, and more
- EGreg 10y agoFinally
- whatnotests 10y agoI misread it as "JRuby" removed from Ruby on Rails and almost jumped for joy.
- sshconnection 10y agoWhat? Why?
- faitswulff 10y agoDoes supporting JRuby add a significant amount of overhead to Rails?
- shakna 10y agoThere's still some discussion around the options [0], for now, the new native js approach is mandatory, even for jquery users. That might not remain. Also exciting to see Yarn already being supported [1], though not so excited that npm support might get dropped entirely in favour of yarn. [0] https://github.com/rails/rails/pull/27113 https://github.com/rails/rails/pull/27113 [1] https://github.com/rails/rails/pull/26836 https://github.com/rails/rails/pull/26836
- brianshaler 10y agoIn 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 10y agoLet's be honest, jQuery was a patch for the IE6 bug.
- crdoconnor 10y agoIt was primarily a saner query language for the DOM.
- xutopia 10y agoIt 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.
- igravious 10y agoThey meant, the bug that was IE6 (all of it).
- akhilcacharya 10y agoNever used RoR, was this just used in the scaffolding system?
- awestroke 10y agoNo, 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 10y agoCan 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 10y agoIt just works, and that makes it old and boring. I'm only 40% joking.
- untog 10y agoI 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.
- jdavis703 10y agojQuery 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_ 10y agoyup, I've also always used jQuery for ajax requests - a lot simpler/quicker/less-line-er for development than defining plain xhr requests
- aindhaden 10y 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?
- marclave 10y agoReally 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 https://github.com/rails/rails/pull/27113
- jon-wood 10y agorails-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
- untog 10y agojQuery 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.
- jayajay 10y agoI misread it as "Ruby on Rails removed from the planet" and almost jumped for joy. Jokes aside, good riddance! jQuery had a good run, and now it's obsolete (maybe a strong word, and debatable). You don't bring an entire toolbox to pound in a loose nail. You don't import underscore to write "Hello, World". You shouldn't bring in jQuery to write client-side ES6. The one good thing that came from jQuery (maybe) is the DOM lookup syntax. Even then, the vanilla query-style isn't even that bad, and as a beginner, I'm not sure why I let the YouTube videos on the internet convince me that vanilla DOM querying was evil and that I should "always use jQuery". Pro Tip: A software engineer that says "always use X" is a fucking retard, and you should probably punch them in the face and then pull their pants down.
- jeffjose 10y agoThe amount of arrogance in this comment is very telling. While jQuery isnt used to build modern webapps, what jQuery did for web development is no small feat. Yes, you dont use Wright brothers' aircraft to fly people these days, but dont compare an early (and pioneering) tool against best practices of the day
- jayajay 10y agojQuery made it super easy to write shitty code. I used to think it was incredible, then I stopped writing it, and now I realize how fucking useless it is.
- jayajay 10y agoHaha, maybe I should add that I'm 20% joking, and you guys will hate me less.
- ben174 10y ago20% less
- jayajay 10y agoAlright Ben, I'm 100% joking.
- reitanqild 10y agoI don't think you really got it jayajay: You are talking down a tool that saved thousands of engineering hours and helped level the playing field between the browsers. And then it seems you try to lie your way out of it. (The first comment looks nothing like a joke.) Recommendation: own your mistake, be more careful next time. Oh, and skip unnecessary profanities.
- bezzi 10y agoNow they just need to replace coffeescript with es6/babel.
- anonova 10y ago`--webpack` and `--yarn` are both coming, so they definitely seem to be headed that way. [1]: https://github.com/rails/webpacker https://github.com/rails/webpacker [2]: https://github.com/rails/rails/pull/26836#issuecomment-264242030 https://github.com/rails/rails/pull/26836#issuecomment-26424...
- BinaryIdiot 10y agoI'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?
- paublyrne 10y agoI'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.
- gsnedders 10y agoYou can absolutely use some of ES6, but only the library parts, which by and large aren't that interesting.
- BinaryIdiot 10y 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. Not really. First it depends on your target audience. How new are their web browsers? Where are you developing your web applications? Some projects I've worked on have web applications that run in only a single environment so those are easy. Others I've had highly technical websites that the vast, vast majority went to using newer web browsers. Second, pick and choose your ES2015 features. Honestly you don't need ES2015 at all but if you want to use it then some items, like let and const, are supported all over the place but others, like fat arrows, not as much. > The only way we can use them is through transpiling. This will be the case for at least another three or four years. Again all depends on your target audience. Maybe? Then again I've never been the biggest fan of transpiling one language into another just to access a couple of minor feature additions. It's a huge amount of dependencies, build time, etc all to support a few minor things.
- mythz 10y agoPour 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.
- deleted 10y ago[deleted]
- MrBra 10y ago> minimal complexity compared to?
- mythz 10y agoThe 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 https://github.com/ServiceStackApps/typescript-redux
- mouzogu 10y agoi still personally find vanilla js quite cumbersome for dom manipulation but that's partly because i've grown used to the jquery way.
- mercer 10y agoYeah, 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.
- deleted 10y ago[deleted]
- kimshibal 10y agowhy not replace jQuery with zepto?
- ralmidani 10y agoI 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.
- somecallitblues 10y agoI 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?
- rajangdavis 10y agoI 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.
- somecallitblues 10y agoI 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.
- rajangdavis 10y ago
- deleted 10y ago[deleted]
- rajangdavis 10y agojQuery 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 10y agoJavascript 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 10y agoWhy 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 10y agoI'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
- paublyrne 10y agoIt'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.
- aindhaden 10y agoTo 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/ http://weblog.rubyonrails.org/2011/4/21/jquery-new-default/
- rajangdavis 10y agoI 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 10y agoI 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 10y agoI 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/ 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.
- cmg 10y agoI 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 10y agoFunny how people here are saying goodbye to jQuery. I'm saying goodbye to Rails.
- aantix 10y agoWhy is that?
- susan_hall 10y agoI 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.