Search
JavaScript
Keynote: The Asset Pipeline and Our Postmodern Hybrid JavaScript Future
Edit
#asset-pipeline
#javascript
#ruby-on-rails
#frontend
#dependency-management
#css
#coffeescript
Summarized using AI

Keynote: The Asset Pipeline and Our Postmodern Hybrid JavaScript Future

David Heinemeier Hansson • May 16, 2011 • Baltimore, MD

In this keynote presentation, titled "The Asset Pipeline and Our Postmodern Hybrid JavaScript Future," delivered by David Heinemeier Hansson at RailsConf 2011, the focus is primarily on the new features introduced in Rails 3.1, particularly the Asset Pipeline. This feature is designed to enhance how developers manage assets like JavaScript, CSS, and images within their Rails applications, addressing long-standing frustrations with asset organization.

Key points discussed in the presentation include:
- The Motivation for the Asset Pipeline: Hansson emphasizes that the motivation for improvements in Rails often stems from identifying pain points in development. He highlights the clutter that arises from unsystematic organization of JavaScript files, comparing it to a messy junk drawer that becomes hard to work with over time.
- Grouping and Organization: The presentation emphasizes the importance of organizing files in logical groupings rather than clustering them chaotically. Hansson proposes the idea of a rule where directories should ideally house no more than 13 files, reinforcing a tidy organizational structure.
- Improvements over Previous Methods: With Rails 3.1, the Asset Pipeline replaces the earlier approach that involved a single large JavaScript file with a more structured method of organizing assets into three main categories: application-specific assets, library assets, and vendor assets, which significantly reduces clutter.
- Centralized Dependency Management: The presentation illustrates how the Asset Pipeline allows for better dependency management using tools like Bundler, enabling smooth handling of JavaScript and stylesheets without manual intervention.
- Introduction of CoffeeScript: Hansson concludes by discussing CoffeeScript, a more user-friendly syntax for JavaScript that allows for cleaner and more maintainable code, ultimately enhancing the developer experience.

In conclusion, Hansson asserts that the Asset Pipeline not only provides a much-needed solution to asset organization challenges but also encourages developers to create cleaner and more enjoyable coding experiences. The separation and management of assets along with the introduction of CoffeeScript signal a significant step towards a more cohesive and efficient Rails development environment.

Keynote: The Asset Pipeline and Our Postmodern Hybrid JavaScript Future
David Heinemeier Hansson • May 16, 2011 • Baltimore, MD

RailsConf 2011, David Heinemeier Hansson

RailsConf 2011

00:00:08.000 Alright, so Rails 3.1 is just around the corner, and it includes a lot of wonderful features.
00:00:15.080 I am going to talk mainly about one of those wonderful features today, but I'm sure we'll have plenty of information about the rest.
00:00:22.000 This talk is entitled "The Asset Pipeline and Our Postmodern Hybrid JavaScript Future."
00:00:28.080 Let's start with the first part, the Asset Pipeline, which is by far my favorite new element in Rails 3.1.
00:00:34.000 I think it's going to have a huge impact on how we all create Rails applications moving forward.
00:00:39.600 But before we go into the mechanics of how it works, I want to focus a little bit on the origins of how this came about.
00:00:45.559 All of the things that I try to work on in Rails start out as problems; something that's just a nagging sense that this stuff could be better.
00:00:50.879 There's a direct pain, something that jumps out at me when I'm looking at a Rails code base and thinking, 'This is really not good enough.' We have to do better here.
00:01:03.440 A lot of the time, that pain is actually visual—I'll be looking at a piece of code and it just offends me.
00:01:11.159 There's something here that's supposed to be simpler and cleaner; why is this a mess?
00:01:19.799 We've been going through this cycle over and over again with Rails, and that's how we usually release new versions.
00:01:27.240 We reduce pain by taking it out and leaving it with something more pleasurable. I think that's a good cycle to be in when you're trying to design a framework.
00:01:40.439 It's essential to focus on the problems and the pain points, because then you know when you're done.
00:01:49.399 It’s easy to get carried away while programming as a framework builder, and before you know it, you have much more than that original pain.
00:02:01.600 We try really hard not to have too much clutter. The features that go into a new version of Rails arise from someone being personally annoyed about the old way.
00:02:09.360 One of the things that I've been annoyed about for a long time is this mess. This is a directory in Basecamp containing all the JavaScript files in one big lump named 'JavaScript'.
00:02:16.959 Seeing this image, I thought, 'This is terrible! Why are all these files in one big lump?'
00:02:28.080 When you dive into it, it offends you even more; look at these files, for example, calendar date.js, calendar date format, calendar date select.
00:02:35.720 This is a unit of work that should be grouped together, but the only way we're grouping it is by underscores.
00:02:40.840 That's a pretty poor form of grouping.
00:02:46.159 Not only that, but it is at a completely different level of abstraction than, say, fancy Zoom, which is another library just dumped into the same directory.
00:02:55.040 I have code that I wrote right next to code that somebody else wrote. That doesn't feel right.
00:03:00.239 These elements might both be library code, but they feel like they should be separate.
00:03:10.440 It gets worse when you look at other elements, for example, milestones.js. This is JavaScript that belongs to a single controller.
00:03:17.560 We're mixing levels of abstraction that have nothing to do with each other; it's just a big cluster.
00:03:23.920 It's a junk drawer; it's not that junk drawers aren’t useful, they sometimes have useful tools.
00:03:29.400 If you have to go into a junk drawer to get something, that's not a great way to start the day.
00:03:35.080 You want the measuring tape to be together with other things that have to do with measuring and cutting, not mixed with rubber bands or pencils.
00:03:45.080 I've found a general rule: if you have more than 13 things together, it's not good.
00:03:51.920 When looking at files, methods, or directories, as soon as we get above that, it feels messy. When it feels messy, you need to push back.
00:04:04.480 Folders have this problem of the boiling frog—you slowly get boiled.
00:04:10.079 No folders start out with 20 files. They start out with two files; you add one more, and then you have three.
00:04:15.959 Then you add a few more, and suddenly you have 15. You think, 'How did I get here?'.
00:04:22.240 I felt this project was nice and clean at the start, and then something happened. It wasn't clean anymore.
00:04:28.080 So how do we combat this? How can we enforce this metric?
00:04:35.080 What if we just had folders that could only hold 13 files? You couldn't add another file to it.
00:04:40.560 It sounds arbitrary, which is often how laws come to be—arbitrary restrictions that don’t explain their reasoning.
00:04:48.800 You want a rule in place to ensure you develop a clean application, but also want justification for why the rule exists.
00:04:55.840 We had a similar problem with REST, applied to controllers. Controllers had a tendency to accumulate over 13 methods.
00:05:01.960 Just adding one more method doesn’t feel bad, but before you know it, you have too many.
00:05:08.199 So we put a natural restriction of six.
00:05:14.080 If you go over six methods, it feels wrong because you’re somehow breaking the conventions established.
00:05:20.800 We should think about ways to apply this to the JavaScript junk drawer problem. At least it's better than the previous method.
00:05:28.319 What we used to have was a single megabyte file where everything got dumped into. I much prefer junk drawer development to trash bin development.
00:05:39.880 The reason we got there was because we had the JavaScript include tag, which included everything.
00:05:44.000 This made it easy to have all those files in one big directory since it would concatenate everything and cache it nicely.
00:05:50.759 We solved the concatenation and speed problem, but we also made it very easy to create the mess you see now.
00:05:56.639 This is a powerful insight: people will do what's easy.
00:06:03.080 Right now, it's easy to write the script include tag and include everything.
00:06:08.800 If we could somehow flip that around so that something else becomes easy, then we're on the right path.
00:06:15.000 In any case, the conclusion is that treating JavaScript and stylesheets as second-class citizens is not a winning strategy.
00:06:22.800 Web applications and web developers need to acknowledge that we can't ignore these assets.
00:06:28.760 These divisions between front-end and back-end development shouldn't remain; they should blend.
00:06:34.480 What’s the solution? It takes inspiration from what I believe is one of the greatest innovations of Ruby on Rails.
00:06:41.760 Two pivotal innovations in Rails that encourage us to write clean applications are empty folders and empty files.
00:06:48.000 When you have a place for everything, and it all has its place, everything feels nice.
00:06:54.000 When everything is a big mess, you dread working with it, especially with that JavaScript folder.
00:07:02.000 The 'Broken Window' theory applies when everything is piled together. No one cares for individual files when there’s mess.
00:07:11.280 When everything is clean and organized, people care; no one wants to trash a pristine codebase.
00:07:19.080 With the Asset Pipeline, we're introducing a collection of innovations: empty folders across different areas.
00:07:29.280 The Asset Pipeline will deal efficiently with images, stylesheets, and JavaScripts, ensuring everything has a home.
00:07:38.240 For instance, app/assets would house JavaScript that relates strictly to the application.
00:07:43.080 Libraries that are not application-specific would reside in lib/assets, keeping things tidy.
00:07:50.960 Finally, vendor assets would house third-party libraries.
00:07:56.960 Just having three different places for these assets is a huge improvement.
00:08:03.680 I went from having 40 files in one folder to about 15 in each. Below 13 still feels messy but is much better.
00:08:10.320 The Asset Pipeline is highly extendable. You can set a new configuration in application.rb or in an initializer.
00:08:17.760 You can easily add paths to your asset pipeline, making them accessible from anywhere.
00:08:25.400 For example, if you take Disneyland as a source with a Goofy image, you can access that via the asset pipeline.
00:08:31.840 Here’s an example of how I applied this while converting apps to Rails 3.1.
00:08:41.400 I worked with a gem, signal ID, that manages all the login logic for our applications.
00:08:47.160 The gem has an app/assets directory containing a JavaScript subdirectory with namespaced assets.
00:08:54.600 This means we can hide JavaScript files that the app should not need to know about.
00:09:02.800 Previously, you'd have to manually dump these files into the same junk drawer you've seen.
00:09:08.600 Now, you just go to your application, find the app/assets/javascript folder, and require signal ID.
00:09:14.000 By doing so, you ensure that the app gets only the necessary dependencies.
00:09:20.560 This centralized management of dependencies through Bundler enables smoother operation for both JavaScript and stylesheets.
00:09:31.600 Also, there's no need to manually copy assets into the public directory anymore.
00:09:39.440 With Rails 3.1, the new jQuery Rails gem takes care of this and allows for easy integration.
00:09:47.240 By keeping essential libraries organized, we can manage updates and dependencies much easier.
00:09:54.880 This brings us to CoffeeScript, which is the new JavaScript framework default in Rails.
00:10:02.640 There’s been a lot of discussion around making JavaScript development more user-friendly and enjoyable.
00:10:10.640 CoffeeScript is a response to all of that, allowing for cleaner syntax and less boilerplate.
00:10:17.440 Its substantial reductions in line noise create a friendlier development experience.
00:10:26.080 For example, its use of significant whitespace creates clarity.
00:10:34.040 This isn't to say that Ruby is abandoning its roots or its elements.
00:10:41.200 Instead, it's expanding what developers can do and how they can do it.
00:10:48.800 CoffeeScript allows us to move towards a more expressive JavaScript, enhancing its usability.
00:10:52.440 As developers, we now have the capability to write cleaner, more maintainable code.
00:10:59.119 This is not merely about writing JavaScript; it's about crafting a better experience overall.
00:11:03.720 Let’s move forward with the Asset Pipeline, a solution bringing order to JavaScript and CSS.
00:11:09.960 Thank you!
David Heinemeier Hansson
@dhh
Explore all talks recorded at RailsConf 2011
+8