 All right, so I have 15 minutes gone in the salami in between, so I have this time. So So today I'll be speaking a bit about Rails front-end a bit about the aspects in on the front-end side of Rails and how they are made by changes which speed up your Rails front-end of it and also speak a bit about sprockets and the changes that have come in, the newest versions of sprockets. I am Ripple, I am Ripple and so on on GitHub Twitter. I usually try to spend most of my time this year trying to contribute to Rails, but I'm not doing that. I work at this company called Springfinity, where I end up working on Rails again and a bit on Node as well. And during Rails, when I'm working over this, I have to get to more round because we are a one-first company. So I try to experience time zones, like for the last month, I've been in Mumbai, which is 520 UTC plus. I was in Taiwan, which is 8. Specific time of San Francisco for a while in the past month and then today we are back on 8. It feels like time zones are stupid, but that's what it is. And not just for programming, but if you experience that it's pretty huge because you face really bad jet lag. And that's what I'm facing right now. So that's the reason why I'm getting this great. This thing, I usually don't do that. And why I'm wearing this is so that when I go to sleep, nobody will be saying anything to me. Today I'll be speaking about, so everyone has spoken a lot about the stack behind the scenes, which is back end. I'll be speaking a bit about front and back end, like back end a bit towards the end as well as front end. I don't know what this emoji was, how to represent back end, so I just flipped it. I tried to search for it, emoji for front, because there was a back, so there should be an emoji. I spent some hours, actually a day trying to find this, but I couldn't. So I thought that, hey, I should actually try to submit my emoji proposal and I ended up here, but I didn't have time. So yeah, we are. This is the front end emoji. So today I'll be speaking many progressions that have happened in the latest version of Rails, Rails 5. One of the things is it has gotten a nice logo and this homepage. So yeah, for the designer who did that, which was after 10 years using the same one. Most of my references that I'll be speaking today are based on the block that we run on my company, which you can find here. We have around 60 plus block entries right now for all the various changes which have come in the latest Rails version. So let's begin. First thing that I want to touch upon is sprockets. So sprockets is that part of Rails which is used for actually serving your resources, your JS and CSS resources. There's a wonderful talk on how sprockets actually works if you want to go deeper into that, which was given at this year's Rails Conf by Rafael. So you should check that out. I want to focus on some of the main things which help you out, which are the new additions right now in sprockets. The sprockets consist of all of these things, which is sprockets, sprockets Rails, SAS Rails, exit JS, coffee Rails, which are peripheral gems which actually comprise of the asset pipeline. So one useful addition which sprocket has seen is that of manifest.js. So previously in your older versions of Rails, if you would like to have, you know, use a different kind of asset, like let's say I have my payments page and on my payments page I want to have different styling and not embed that completely in my application CSS, I needed to do this kind of thing wherein my pre-compile needed to have payment CSS, advertising CSS, etc. And then on my page where I actually need to use that, I would use this kind of tag. Rails 5 comes now with manifest along with support from sprockets, wherein you can just define this kind of file, it is by default generated on Rails 5 apps. And then here you can define which file you actually want to pre-compile as well. So instead of defining that list, which is not kind of handy, like you always need to define that and make sure that it's actually in the pre-compilation so that it actually finds it in production in your apps, you can instead do something like link. And you can actually use this manifest file to define dependencies on all of these multiple different assets. So we will say like link tree and link all my images. So instead of specifying them, I will say that hey, I need to access these images and when pre-compilation happens, they should also go along like from this in the process of assets pipeline. I can do link directory and link and so on and so forth. So here you can see that I am doing link advertising CSS and instead of specifying that in my pre-compile and specifying it over here in using link. After I do that, I can then go ahead and start using that in my ERB or also in some other directory, in some other asset as well. So if I do this, Rails will automatically pick that up and it will send it through the pre-compilation path. Next useful addition which Sprockets has got is that as folders as modules. So if you notice over here, I have this foo slash index.js. So this is kind of a technique which is pretty popular in node-based apps wherein you have this directory and you specify index.js and instead of having including this asset like asset path foo slash index.js instead of this, you can directly just use foo.js and it will go and import the index file. So this is pretty useful if you want to define something like this. So previously if you wanted to, you know, import all of your different assets in your directory, what you would do is you would do something like require tree. Require tree in that particular directory and what will end up happening is it will import all of those in an alphabetical way. Problem with this is if you have such kind of a file, jquery ui.js and minj.js problem with this is it will import alphabetically and then this file will be imported before its dependency and you don't want to have this kind of scenario. So instead of this, now you can just import index.js and there you can specify the order in which you actually want to import a particular file. So this is pretty useful. The next thing which is pretty useful again for debugging purposes is source maps. So in the previous versions of Rails on Rails 4.2, if you try to do this, you would see that on a request on your development side, you have all of these resources being loaded. So individual files, every single resource that you have, it will send a new request for fetching that particular resource. So like jquery, button, etc. On the latest version, Rails now actually maps that similar to how you have in production. So in production, you actually have just a single file which is compressed and minified. So now in the Rails 5 apps, you'll start seeing something like this, which is application debug. And what this means is it is trying to map the same behavior that you actually see in production, which is something that you would like to see so that you don't have any surprises when it actually is how it is actually working in production. So since you have this compressed thing that is also being served in your development version, whenever you want to debug something, it's pretty hard to actually find a particular line. Something goes wrong, another is thrown from a JavaScript. You don't know where that particular line is because it's now compressed. So to actually find the location of that particular error or something like that, we can now start using source maps. So source maps are actually defined by this mapping, this directive that you see over here. So let's say I have this file application.js. Sprockets will create this mapping file that you see over here, which ends by just map. And this mapping file will then be provided by these directives in the original file. For JS, it is this way. And for CSS, it will again provide a different kind of mapping file. And this is pretty useful. So like in your request now, you'll see these two files being served. But on the browser end, browser will detect these mapping files. And then you will actually be able to find the mapping of these particular... So if you want to actually trace back to some log or some error being thrown, you can map that back to the actual sources again. The next useful thing, which at least for me, which is pretty exciting, is Babel support for sprockets. How many of you use or know ES6 ES15? A lot. Nice. So ES16 has a lot of these amazing things, which I'm pretty excited about to use, have started using. Like the arrow functions, lexical, binding, classes, and has object or literals, and a bunch of different things. So by default now in the latest version, sprockets ships with Babel support. So now you can actually start using ES6 by .es6 extension. So this is pretty exciting. Again, I wanted to show this by this. And I tried to search for this, but it was like, hey, there are so many different things that you can actually show this for like rainbow unicorn poop as well, or something like this. So internet is pretty awesome if you try to search for it. The other thing that I want to speak about is this 12x improvement that sprocket has seen in the pre-compilation process of asset pipeline. So there's this nice blog which Richard Schneem, which he goes by Schneem's, has written on Heroku. So you should check that out, which actually provides the whole listing of whole process of how this speedup has occurred. So here's the actual flow of things that go into the pre-compilation process. Like you have your raw asset, you try to actually process that based on which kind of SaaS or coffee script. And then you try to get this bundle together, like all of your different files are bundled, they are compressed, then they are given a fingerprint, like a digest that you see after a particular asset, which is for cash bursting, and then they are minified and so on and so forth. In the previous version, it actually had a bug. If you see over here, this is the function which is used for actually finding the digest. So when you pre-compile, it tries to store that particular asset in your TMP, asset cash, if you have heard of that. So for actually finding, so ideally you would not like to go through a whole compilation process because it's pretty slow to actually getting that asset. So instead of that, we have these fingerprints and then you use that to find that if that resource is already being processed and is it, if it's either already in the, exists in the cash or not, and if it does, then just return that. Problem over here, if you see the path is being provided over here. In the previous versions, it used to pick the absolute path. The issue with this is if you have, if you use something like Heroku or if you're using like Capistrano, in case of Capistrano, every deployment will actually create a new directory. So if you're using this, your cash is always going to find a new path. So it's not going to refer to the original resource. So you are actually missing the whole point of having, accessing the cash versions. So this was fixed by, this fixed again by Richard and he added this unload asset which actually tries to find the actual paths properly when it does the whole compilation for this digest and finding it actually in the cash. The next thing I want to speak about is SRI, which is Sub-Resource Integrity. So it has been added as an experimental feature right now. It has been present for a while. So what this allows us to do is we can append Integrity True as an option to our application, whichever resource that we want. And that will create an Integrity Hash. So now why this hash is useful is, so let's assume we have a page which has multiple different resources. Like I'm not always going to access a resource which is in my project. Like I would like to access the jQuery or bootstrap which is being accessed from some third party CDN or so on and so forth. In that case I need to make sure that whatever the resource which is being provided to me it actually matches the one that I wanted to access and something has not been injected into that particular resource. So in that case we have this use of Sub-Resource Integrity which makes sure that whatever resource we are actually providing actually matches the digest of the original resource which you meant to actually access from a particular domain. So you can start using that right now. Alright, that's all about sprockets. Hope everyone is following me. The next thing I want to speak about is all about headers in your page. So this is a typical header or the response that you see when you send a request to a page. This is coming from the Chrome browser. It shows what are the response headers. Like you have your e-tags, date, content type, etc. So what I want to speak about a bit about is how you can use them how you can use or manipulate these headers so that your resources are actually cached on your browser. So one of the good uses of these headers is e-tag. So if you see over here there's a header which says e-tag and it has some digest. And then we also have this last modified over here. So using these two headers, the browser can negotiate with the server that hey, whether I have the latest resource in my cache or not. In the previous versions you could use, like right now you could use it with FreshWin or Stale. And what essentially this will do is it will first of all find out all the items and then it will generate an e-tag for those items. And when you send this as a request, so if you see over here, I'm sending a request to fetch these items. On the first request, it will return 200 as a response. On the subsequent request, if I pass this e-tag which was generated over here, this e-tag, if I pass this to this request again, it knows that hey, this was my e-tag, I'm passing this in this header if none match. It sees that there is some e-tag object which is being passed to me and it tries to find that on the server and if it does match then it returns with 304 modified, not modified and just use the existing resource that you already have in your browser. So this is useful so that you don't actually go to your database and try to fetch your resources and slow down your request. So this speeds up that part of the thing. So Rails now has support, Jeremy added support for strong and weak e-tags. What this means is, so these are two kinds of e-tags that you can actually have in your requests. What this means is if you have a strong e-tag, your request, when you send a request, it will try to do byte by byte matching. So this is useful when you have some kind of a PNG or you're streaming a video wherein you want to see hey, this resource which was previously sent to me, does it actually match to the resource that I currently have? This is not so true in case of pages you have generated, like all the default pages that are generated in Rails app which are dynamic and in which case they are not always going to change. It's useful to have this kind of weak e-tag. So in this case it is just going to create a digest of the resource and it is going to match with the previous digest instead of doing byte by byte matching of the whole response. So this is pretty useful to not go through that render process to find out if the resource has changed or not. Another useful helper which has been added is HTTP cache forever. So let's assume we had this home controller over here which just serves this welcome tag. Previously, like if you always try to access this page, what will end up happening is it goes through processing, render, and all that multiple different things, the whole cycle of a particular serving of a resource like HTML page. This happens for every single request. Instead, now you can say cache forever, it comes with a risk, but now you can do something like this, HTTP cache forever, public true, and render the response that you want to actually send. And if you do this, for the first request, it will serve it in this way like processing so and so forth. In the next request, it will just reply with 304. What is actually happening over here is when you do public caching, it will set the cache control over the resource. So your page will actually be setting this cache control max age 100 years or so. So use this with caution what this is useful is, let's say you have a page which is really static and it doesn't change a lot and it's never like, you know that it's not going to change, but you can use this to notify the browser that, hey, don't always try to compute this resource, just use the one that you already have. Use this with caution because the only way to undo this or get a fresh resource is doing a hard reset on your browser cache. The next important thing that I found or that I found pretty useful was having support for custom asset headers. So let's assume we have this request. This is a typical Rails request, wherein you have all these headers. These are not visible thus, but just take my word that there are lots of headers over here. If you see over here, if I want to specify a custom header in my request, in my response, usually you can easily do that by saying response.headers, some header, and then try to set some value over here. And then this value will be served from the request. Problem with this is you cannot do that easily or previously you could not do that easily in case of your assets. Your assets only had, or your dynamic assets only had this one header, which is static cache control, and the only thing that you could actually manipulate in this case was this header, which will only set the cache control over here. This is useful again for caching purposes. You will say that, hey, to the browser, whether you want to cache it publicly or not, and for how much time you want to cache your resource before actually getting the new one. Problem with this is sometimes, like in case for me, what it does is some of the browsers do not actually just depend on the cache control. You would like to have other headers, like this is something that I got from PageSpeed, which is a Google tool for analyzing how your pages are doing. So if you see over here, PageSpeed was warning me that, hey, expiration was not set for a resource. So you actually want it. It was saying that for some of the browsers, expiration header is also useful along with the cache control. So I should be setting that. But I could not do that easily since we can only specify cache control as I said. So this is a new thing that you can now start using on Rails 5 when you can specify public file server, and then it actually uses all of these custom headers, like cache control, you can specify for cache control, you can specify for expires, or you can specify other different, you know, for controlling it so and so forth for your surrogate cache or CDN, so and so forth. So this is useful if you are actually using something like Fastly or if you're on Heroku. In case of if you have your own server, this will already be taken care of by on the engine excite. And now, after I've added this expires header in my config, like the result is that you'll stop seeing that warnings and then you'll actually start seeing that header which is being set over here. This was actually done by Yuki, so thanks to him for that. The next thing I want to speak about is caching. So apart from these things which you can use, like headers or e-tags for specifying not to compute the resource, you can also use a bunch of different things on the caching end of action pack or action view. There are a bunch of different ways you can actually perform caching in Rails, page caching, action caching, et cetera. You can find them all on the Rails guide. Today I just want to speak about the new additions which have come into the latest Rails release. So one important change which has come in is that of partial rendering from cache. So if you see over here, I have this to-do collection and what I'm doing is I'm rendering that as a partial and here I have this cache which is using this to-do. So when it wants to actually render this, it will render it for that many number of times and then for every single cache, it will try to actually fetch your cache entry for this to-do that you see over here, which is expensive if I have 100 of these, it is actually going to send hundreds of requests to fetch this cached version of to-do. So instead of this, now you can start specifying this cached true when you're trying to render the partial. This was basically influenced a lot from multi-fetch fragments gem. Now you can start doing this and Rails will identify that hey, I want to actually render a collection and then not do these multiple requests to the cache and just use read-multi to actually fetch all of these entries together in one single request, which gives you a lot of boost so you don't have to do that back and forth to the cache. And this is something that you'll see in the end result in the logs that hey, it just fetched it in one single go. The author of this library, like the original library, which actually, which was influenced by this, in his usage, it actually improves the performance for these kind of scenarios by at least 72%, which is pretty good. The next thing, which is kind of on the peripheral, is that of action-mailer fragment caching. So now you can also use, like, make use of caching in your mailers. You can enable this by perform caching through again for action mailers. And then in your mail fragments, in your mailers, what you can do is you can start doing this cache do. And then it can also, if whatever part you have of mail, which is actually dynamic, you don't need to do that, pre-compute all those values. This is pretty useful because in your mailers, you don't have to end up spending so much amount of time to actually compute all of these things, which you know are going to just be this part of the particular mail is actually going to be dynamic. Everything else is going to be seen. So you can start using this now to use cache in your mail. You can see over here how it is, after you run this request, it says that, hey, it's going to fetch the cache digest for that particular part of your mail. One other addition, which is kind of useful, which goes hand in hand with the fragment caching or collection caching, is that of support for collection caching on result sets. So Active Record Relation now has support for cache key. So previously, when we were saying cache do, you have to actually provide, so we'll see an example for that. So if you notice over here, I'm trying to find this result set where I'm saying I need to find all the users who stay in city Miami. The thing with this is if I'm not changing this particular query, if no records were added or if no records were deleted, this result is always going to be the same. If nothing was changed, this result is actually going to be the same. So I can cache this particular result. Now there are multiple different ways. Previously, you had to do that manually for yourself, like for a result set how you're going to specify this cache key. Rails now has the support for cache key on these collections. So what it does is behind the scenes, it tries to find that based on the updated timestamp and it has some restrictions but based on that, by itself it tries to find this cache key and then you can start using this cache key to actually, you know, cache users and it will automatically start using that cache key instead of you specifying or you trying to generate a cache key for that which is again pretty useful so that it gives you again this use of caching over whole resource, a collection of resource. Finally I want to speak about layouts and tags which is coming towards the end of how your pages should be structured. So I want to get to first or I want to first get to refer to this async and defer which is kind of attributes that you can specify over your tags. So here is just a legend of that, I have picked it up from an example which is here somewhere. So here the green part is actually parsing, halted, downloading of a script and a script execution. So generally when you just have the script tag, script tag with application import, your usual import, what will happen is it will, your page is parsing, parsing, parsing. It comes to your JavaScript include tag, then it will halt for a while, it will stop rendering your page. It will try to go and fetch this since it is a different file, it will send another request and for this time it is halting which is not pretty good because for that time of download nothing is happening on your web page. After it is downloaded it will then go and actually execute that JS which was imported and then it will again start rendering or processing the HTML parsing. So this is not pretty good because this affects your page speed, if your resource is slow, your file is huge, this is going to affect how your page is actually rendering. Other way is that of specifying async. If you specify async what will happen is this resource will download, so when it sees that this tag was async, it comes over here, instead of stopping the parsing it will continue parsing, it will try to find this parallely and then it will stop again the HTML parsing and execute that particular JavaScript or CSS resource. The third thing that we have is defer. Here what happens is the normal execution will go as it is. Whenever it finds this JavaScript tag, it will go and download it but it will not stop normal HTML parsing, it will do that towards the end. So based on your usage, how you are actually importing your JavaScript or CSS this is pretty useful for speeding up your page actual page paints. This is useful for your page speed again. So there is an ongoing pull request right now to have this by default in Rails. You can follow that over here. So this will actually be pretty helpful by default if it's enabled in your Rails apps. Towards the end, I just want to speak a bit about page speed. So you can use page speed, this tool we just provided by Google for finding out different things that you can improve. And this lets you know about how your placement of JS and CSS imports are, how you should have your analytics tags and so on and so forth. So in a typical application.html file you will have a bunch of different things. So I just want to end with this that how you should actually place all of these tags. Based on your execution it will actually slow down or speed up your painting of a page. If you see over here I have my style sheet tag by default style sheet and these tags will be in the head in your new apps. You should usually try to move the JS towards the end so that the execution is not stopped. You can also specify async and defer again so that execution is not stopped for your HTML passing. You might also have something like this which is for your loading of external fonts which is something I don't like but you will need to have in your apps. So you should actually try to move that towards the end and usually try to use open fonts and just embed them in your asset pipeline. Google actually says that you should have this style sheet towards the end so that it is not blocking again for fetching that file. But usually this is pretty useful again because you don't want to have the page like all black page and suddenly you have that whole style coming. So this is useful so that it appears that your page is actually pretty fast. So this style sheet is basically above. So based on your usage you should have your scripts execute towards the end of your page on page load and so on and so forth. And yeah you can combine all of these different things that we have discussed today to actually speed up your page which is something I like in the latest release of Rails. That's all I have for today. Thank you.