What Is The Best Way To Include jQuery In A Rails App?

Today, jQuery is the most popular JavaScript library both within and outside the Rails community. It's small, fast, cross-platform and rich in feature JavaScript library, designed to uncomplicate the client-side scripting of HTML. Making things like the document traversal and manipulation, animation, AJAX and event handling in HTML straightforward with its easy-to-use API which runs on several types of browsers. jQuery appears to be the most popular, and the most extendable, although there are enough other JavaScript frameworks out there.

Rules of thumb

• Organize your site-wide scripts logically in the app/assets/javascripts/ folder.
• Copy external JavaScript libraries, like the jQuery plugins to the vendor/assets/javascripts folder.
• Allow the asset pipeline of Rails to combine all of it in a smaller application.js file.
• Now the scripts, list them in the app/assets/javascripts/application.js manifest.
• Even for JavaScript used on a single page, make use of the Rails asset pipeline. You’ll avoid complexity once you copy the external scripts to the application and gain the performance benefits of the Rails asset pipeline. By letting the present page instance remain alive and replacing just the page BODY and the title in the HEAD, the Turbolinks feature helps improve performance. The Turbolinks mechanism will be able to provide its “turbo” speed boost, as long as the HEAD element is identical between pages. This adds to the significance of avoiding all extra script tags on certain pages.

Principles of performance

It can get hard to iron out the advice and hearsay around JavaScript and Rails. So, we have jotted down some basic principles you need to keep in mind to help improve website performance.

• Your browser can either execute JavaScript or render the UI at the same time. Remember, JavaScript is single-threaded, meaning only one operation can be performed at a time.
• Downloading files will take a lot more time than parsing and then executing browser code. Today’s web browsers can download files (CSS files, scripts, or images) in parallel. This is because modern web browsers have to cache files to reduce download requests, both within and across sites. Even so, multiple files can be slower than single files, with parallel downloads and caching.
• The lesser script tags you use, the faster your pages will load. Our modern web browsers download scripts in parallel. However, each script tag has to be parsed and evaluated to determine whether a file is cached and current. So, dynamic loading, from within another script, is faster than using an additional script tag.
• With Amazon’s CloudFront, you can easily and cheaply set up a CDN for your application. Here, you have the advantage of a CDN for files you’ve added to the Rails asset pipeline, letting you combine popular JavaScript libraries with your code for first-page delivery faster than your server. Then again, the only advantage is for first-page delivery.
• Content delivery networks take a lot less time to deliver well-known JavaScript libraries than your web server. But, CDNs have no other advantage once a file is cached. CDNs make sense for landing pages, but when it comes to large sites, where caching is at work, not so much of an advantage. CDNs offer no advantages if a visitor has a library cached from a visit to another site, for popular JavaScript libraries.
• Inline JavaScript, blocks loading and the rendering of the page, these are ones mixed in your HTML code. Additionally, it's messy to mix Ruby, JavaScript, and HTML in a view template. Put JavaScript in the Rails assets directories in its files.
• Like the application.js with the Rails asset pipeline, scripts concatenated into a single file reduce the time taken to download and could be cached for use, site-wide. You can copy and concatenate external JavaScript libraries into a single file to reduce download time. When your application requires a specific version, make your copy of an external library. Use dynamic loading, rather than making a copy, when you want to rely on a third party to update and maintain the library.
• Dynamically load external JavaScript libraries which are likely to be cached from visits to other websites from within your local JavaScript code. Dynamically loading scripts eliminates the overhead of parsing and further evaluating the several script tags and the loading of scripts asynchronously along with the use of cached files.
• Don't copy external JavaScript libraries which introduce security vulnerabilities, like codes handling credit cards, into your application asset directories. Rather, through dynamic loading, include the external script in an application.js script.
• When JavaScript used site-wide with JavaScript intended for use on individual pages is combined by a single application.js script, the conditional execution of page-specific JavaScript will reduce execution overhead, if the page-specific JavaScript is tied to elements on an individual page.
• Often, it's less time consuming to download a single script combining site-wide and page-specific JavaScript (for a first page) and reads from a cache (for subsequent pages) than it is to download several scripts on individual pages. The exception is a very long script used on a single page that is not visited by most of the site’s visitors. Now, rather than including page-specific “big code” in the application.js script, this exceptional case means you have to add an additional script to an individual page with the help of a second script tag. And only performance testing will tell you whether this optimization is warranted.
• Just about all jQuery commands don't function right unless its run after the DOM has entirely loaded. jQuery's solves this with the help of "document ready block." This waits until the document is ready, then fires off the function passed to ready. When using jQuery in Rails, treat JavaScript the way you treat CSS. You're not binding style, but behavior, to a particular set of elements identified by a particular markup.

 The standard issue with using jQuery with Rails in an application of higher or moderate complexity is the trade-off between including all of it in a single application.js and having multiple, modular files. This will be an issue for you if you plan to use Rails more than the users of Rails who seek to use the jQuery library as a drop-in replacement by making use of Prototype helpers.

TL;DR

It's a Rails plugin that you activate by adding <%= includejquery %> in your application.rhtml. The moment you start the server, it parses all your JavaScript files and identifies selectors within those files. Further, when includejquery is called in your layout, it'll get the rendered HTML and use Hpricot, that shares syntax with jQuery to figure out whether any instances of the selectors identified, are present on server startup. The JavaScript files having selectors, also present in your HTML will be loaded, and run as expected.

In short:

Create your JavaScript files, using selectors as usual

Use include_jquery in your layout

And there, you have it.