Great job in going through that section, the site is looking so much better than it did before. It's starting to look like something we may actually want to show and that we'd be proud of calling our own portfolio. With all of that being done in this deep dive, I want to take a deeper look at the Rails asset pipeline. The asset pipeline is how Rails is able to manage things such as Javascript files, CSS style sheets, images, videos and all kinds of things that are usually related to what users see. Now, the pipeline has been developed for years and has gone through a number of iterations. What it does for us is much more than just have a set of files that we can dynamically call. It also performs tasks such as compiling all of our code such as all of our Javascript files, all of our CSS files and it performs tasks such as minifying them so that they can load as fast as possible on a user's screen. We're going to talk a little bit more about what the asset pipeline actually does and how we can use it to our advantage.

Switching back into the browser we are going to take a look at a few different items in order to see how the Rails asset pipeline works. This is going to be one of the few deep dives where we're not actually going to do any coding we're simply going to dive into the process that Rails follows when managing assets. We're going to start with our own site right here. Now, you may notice that with our app and if you look at the code and go into say the application.scss file you may see that we have a number of lines of code here. We have it going all the way down to 190 lines of code. This is our main CSS file for the home page and for the items that use the application layout. We also are importing bootstrap, what this actually does, is even though we don't see it what Rails does is it imports all of the bootstrap code here and it slides it in here at the top.

This is more of a function of how sassy stylesheets work with SCSS and that's very helpful for bringing it in. But even if you weren't using SASS Rails has a few ways of putting that all together. If you want to see what that looks like there are a few ways of doing it. If I come to Chrome here and I click on view page source and if I do this you may see a few kind of odd-looking links here. Mainly because it doesn't really look like we put these here. If we switch into the app layout file, you can see our head tag does not have any of those items that are listed. We simply have a stylesheet_link_tag that links to our application.scss file and then our Javascript include tag. But what Rails does is it leverages these and these are just methods like view helpers, and like all the methods that we put together and it compiles these and puts them together.

The very first link is the set of CSS styles and then all of these other ones are all Javascript links. These Javascript links are coming from our application Javascript file and if you go to app/assets/javascripts and go to application.js each one of these items where it says require this is bringing in a set of Javascript files. That's what these are mapped to. Now you may also wonder why we have 'assets/application.' and then there's this crazy long string before it says .css.

What is happening here is Rail's does a lot of performance enhancement for us that we don't even really know about at least in terms of seeing it on the screen. But what Rails does, is it works on performing caching and what caching does is it is a tool that can be utilized by browsers and by other clients that will help to speed up your application. Instead of simply having each one of the JavaScript and CSS files brought in every time you load a new page. What Rails does is it takes it and it creates a separate much faster loading page, that can be stored on the user's computer. The first time they go to the page it may be kind of slow but after that, it actually references these old cached files and that helps improve the speed. Now if I click on this link it'll actually show us the CSS files.

But this is kind of interesting because if you scroll down you can see that it shows us way more CSS styles than we actually have in our file. In fact, if you hit end, you will go all the way down and you'll see I forget the exact number of lines but it is way more than we had. I'm actually going to show you how we can find that out. It also does some very cool things for us such as giving us a point to be able to find where styles are hidden or where they're located. Right here it says that this little mastfoot style is online 140 in our application.scss file.

Whereas if you scroll all the way up and you scroll down you may notice that it does not have the same exact reference. Here it says that this code is on line 144 but not in our app. It's actually in users/admin/.rvm/gems/ruby/gems/bootstrap. This is actually in the core bootstrap code assets/stylesheets/bootstrap/_normalize. This gives you a cool reference where you can go see where the files are. Even if they're not stored in the application they are referenced from the app and they're actually stored on your system which is kind of cool to see. That is the main CSS file. You can click any of these other items to see the Javascript code.

One thing I want you to pay attention to is the fact that you can read all of this code, by that I mean this code right here is on hundreds, thousands, tens of thousands of lines and it's in a much easier to read kind of format. That is because we are in development mode. In development mode Rails treats assets much differently than in production mode. I'm going to go through a way of seeing the difference and how in development mode there is no kind of minification and I'm going to also show you what minification means if you've never seen that before. We're going to compare a production Rails app with our app locally to see what Rails does different in different environments.

I'm going to close us out now and I'm on the DevCamp site here. I'm going to actually go back here and we're going to switch between the two to see the differences because DevCamp is a live site. It's a live Rails site. Here we have a development Rails site. If I hit right click, and click on inspect this is going to bring up the inspector toolbar. I'm going to bring it up even more. So we can go and explore it because when it comes to exploring assets and the way that Rails works with them, using this tool is one of the best ways of doing it.

We have looked at elements, this shows us all of our HTML code and we can select items on the page which is fantastic but what we want to get into are some of these other tabs. The sources is the next spot that we want to go into.

As you can see right here the index page shows exactly what we saw when we clicked on view page source. This is pretty much just already what we looked at. If we click on assets this shows all of the items the assets that are being referenced.

If I click on this file and when I hover over you can see all the way to the right where it says .css, if I click on this, this is going to show us the full CSS file that we already saw. But the cool thing about this is it has line numbers.

Now if I grab this and scroll all the way down you can see that our CSS file even though we counted it was only a little over 100 lines long, is actually over 11,000 lines long. If you include all of the bootstrap styles that get imported. That's kind of cool to see on everything that our application is actually doing. Even behind the scenes and how our CSS files are managed that way. Also, if you click on any of the JavaScript links. Even though you may not think that we're using a lot of Javascript because we haven't written any Javascript yet there's still a lot of Javascript in our app because bootstrap leverages it. You can click on each one of these to see exactly what is going on with them. One thing I want to show you and this is the difference between local and production. Also if you click on right here you can see this is our application and this is our set of styles. This is in development mode, let's switch to production mode where I'm going to show you what DevCamp looks like if we do the same thing.

DevCamp I can tell you from experience has probably about 20-30 times more code than our current one maybe even more than that. It's a decent sized Rails application and has a ton of styles it has probably about a half dozen or more layouts. You would think that if you went and looked at the CSS code, you would see something that would be, if we were at 11,000 lines you may think that we would be at 50-60-70,000 lines in our CSS code. Well, let's go test out that theory. If I click on sources. One kind of cool thing just has a little side note, if you click on assets you can actually go and find the images that applications use inside of this and this is not just because I manage this site.

You could go to it you could go to any of your favorite sites and go through it exactly like this. Just a little side note. Also, let's click on our CSS for the DevCamp site. If I click on this, you may be a little bit interested to know that the CSS file for the Devcamp site which is a very large Rails application is actually only really one line of code. It may if you add up the comments and everything like that it totals up to be eight lines of code. But in all reality, it's just one. How is that possible. Well, that is where minification comes into play. Now, if I were to scroll to the right you would see it maybe one line of code but it is a line of code that stretches a few miles long. What minification does is it takes code like this. It'll take our CSS file and it removes all of the white space. It removes all of the end of line characters. It removes everything like that. It goes and pulls it down and makes it one very, very, very long piece of code. The reason why it does that is because each one of those extra spaces, lines, tabs all of those items take time to process and they can slow your site down. But what Rails does in order to help with performance not only does it perform caching but it also shrinks the CSS and the Javascript files in order to make this possible and it does all of this for us automatically. If we click on the Javascript file which the DevCamp site is very heavy in terms of Javascript. It has a lot of Javascript, Ajax, Coffeescript type of components and still, we are at eleven lines of total code including every single Javascript function and everything like that.

That is a pretty cool way of being able to very quickly pull in that code. Switching back here, you can do the same thing in Jquery. You can see what we have for actioncable and all of those assets. So, this is a very popular way of being able to go and access those items. There are even some cool debugging things you can do and that is where you can go and select breakpoints inside of here and then have the application stop so that you can essentially ask questions of your app. That's something that can be very helpful when you're building Javascript functions, Jquery functions and those kind of things. That is your sources, let's take a look at the network to see exactly what this does for us. By default it is going to have nothing because we need to refresh the page and if we do that it's going to give you a very cool little timeline on how long it takes to load every piece of the application.

This is going to be everything from the Javascripts to the CSS. From everything like that and that is something that's very helpful when it comes to performing debugging on the asset pipeline. Let's imagine that your site is very slow a great spot to come take a look if you think that your assets may be the problem is to come to the network tab and to simply analyze it. You can see right here you have a full timeline on how long these items take to load. This was for this layout. Let's take a look at our blog layout. If I click this you can see our blog actually takes even longer to load some of these styles. It took longer than our home page, it looks like this took 400 milliseconds. Right here, it actually only took less, looks like about 175 or something very small and it's because we don't have a lot of styles. This is a pretty light page when it comes to styles and I did that on purpose. I picked this one because it was light and you want your home page loading very fast for your portfolio. Your blog can be a little bit slower because it has more items that you need and so that's not quite as intensive, our portfolio we can click on this and see how long this one takes to load and see which items in the asset pipeline are slowing it down. This can be a great way of performing debugging. I've had multiple times where I had some type of Javascript library that I wasn't even using but I just either brought in or as a legacy application and it had been in there for years and the site was loading slow for some reason and it was because of one of the JavaScript libraries was causing an issue and causing some server latency. All I had to do was go pull it out and all of a sudden everything started loading fast. This is a way where you can get very granular to see exactly how everything is loading. So, that is just kind of a breakdown of how the asset pipeline works. Also, in addition to how it works with stylesheets and Javascripts. We also took a look and saw how it works differently in production based applications and it performs things like minification compared to development.

One of the big reasons for that is because imagine when you're looking at the code if you're trying to debug it and you're inside of the console like we were and you were looking at the sources if you had a bug on one line of code that would be incredibly hard to debug inside of production mode because the whole entire file is one line of code. So, for the system to say ok, you have a bug on line 11 but the entire set of styles is on line 11. That's not very helpful but in development mode it is very helpful because the line 11 here will probably be the exact line that it's on. Then I can go make the fix and take it live. That's the reason why it's so important to have this concept of development vs. production. In fact kind of an interesting concept to know when it comes to understanding the history of Rails. One of the biggest reasons why Rails was initially created was because DHH who is the original writer and founder of Rails. He was building applications for his company 37 Signals and he didn't like how the frameworks they were using had a very poor support of different environments. In other words he had to have the same environment and he had to kind of clone his environment for the web and they he had to go and make changes such as caching and minification and things like that for the live site and then had to go and change it locally. That caused just a number of bugs so one of the biggest positives and one of the biggest benefits in the very early versions of Rails and we're talking about a decade ago was that it had this concept of being able to adjust based on the environment it was in and whether it was in development, production, or test mode. That's just kind of a little bit of a history on Rails and why what we just witnessed here in looking at the assets is so important.

Great job going through that. I wanted to give you a little bit of a coding break after having such a long section I know we went through well over 20 different guides in order to build out this entire design and implement it. I wanted to take a step back and look at how these things are possible. I know we looked at how to implement it and we looked at the practical components of it. But I wanted to show, this is actually what's happening with the CSS with the Javascript and also what is going to happen when we push this up to a live server and how it's going to be different. In that case compared to here and how you're going to have to perform debugging differently so all of those things are important to note. Excellent job in going through that section. I know that was a ton of content but we now have a fantastic looking portfolio. In the next section, we're going to have a very exciting time when we start going through how Rails works with Javascript.

Resources

• Rails Asset Pipeline Documentation