00:00:11.759
Hey everybody, thank you for coming today! This is really cool. I actually attended my first tech conference in this very room a couple of years ago, so it's pretty neat to come back here and speak about web packing.
00:00:30.000
My name is Taylor Jones, and this talk is called "Web Packing for the Journey Ahead." Before we start, I want to give you a little introduction about myself. I'm on the internet as 'Hi, I'm Taylor Jones.' I know it seems overly clever, but that’s me trying to establish some hashtag branding.
00:00:45.840
If you want to see what I'm up to, you can probably find me under that handle. Right now, I'm trying to figure out this whole parenting thing because I'm about to have my first child in a few months, and I'm excited about that! We have a spoiled rotten dog and some cats too.
00:01:02.079
My day job, when I'm not surrounded by pets, is at Isaiah in Orlando, Florida, where we're working on some cool projects. We are also hiring, so if you'd like to move to Orlando and write some cool Ruby code, please talk to me or hit me up online.
00:01:14.400
Now, back to the talk. The main focus here is on Webpack, which is often misunderstood. It's trendy these days, but I want to explore Webpack and Rails, and understand why our community is embracing it.
00:01:27.280
For me, part of this talk is understanding the rationale behind using Webpack, not just for the community but personally as a developer. We'll discuss how Webpack works with Rails and why we should bind them together.
00:01:50.000
If you're confused about Webpack or haven’t looked into it recently, let’s do a brief primer before diving into the Rails specifics. Webpack is a tool used for bundling JavaScript modules together and optimizing them based on your preferences. It takes dependency-driven code and generates static assets for better execution by the browser.
00:02:14.800
Rails developers have had this functionality through the asset pipeline for a while, but for the JavaScript community, Webpack is fundamental for optimizing and delivering assets. In short, Webpack makes compiling and optimizing front-end codebases much easier.
00:02:36.400
I’ve created a crudely drawn graph to illustrate how Webpack works: you take a front-end codebase, run it through Webpack, and receive static assets. Think of it like abstracting more complex languages like JSX and Handlebars into JavaScript, HTML, and CSS, which are more browser-compatible.
00:03:02.560
The goal here is to produce code optimized for browser execution. If anyone remembers the days of jQuery—where there were dozens of options from websites to download a specific jQuery flavor—you’ll understand how critical proper packaging and optimization are.
00:03:16.800
What I want to discuss is the history of how we used to optimize code for the web, how Webpack fits into that, and the current state of things. Back then, we had simple libraries, but minifying them was often more art than science. Developers would simply add '.min' to their library names without any standardization.
00:03:39.360
The minification process itself is straightforward: you can remove whitespace, eliminate unused dependencies, and choose only the selectors you need. Tools like jQuery offered options for trimming down and optimizing code. This made jQuery particularly valuable, and those optimizations were essential to improve load times.
00:04:07.200
The problem that persists today is the inconsistency in experiences between different tools. Some tools offer rich features while others lack them entirely. Webpack emerged as a solution to remedy these issues, especially for the JavaScript community, providing a centralized and consistent way to package assets.
00:04:35.360
If there were a billboard for Webpack, it would state: "The one-stop shop for all your optimization needs." While it sounds cheesy, it's a true solution for managing a modular JavaScript application with lots of assets.
00:05:01.440
Regardless, Webpack supports JavaScript primarily, and you may wonder about the multitude of languages that extend beyond JavaScript. Webpack's utility lies in its ecosystem of plugins that allow it to extend beyond just JavaScript.
00:05:26.400
This reminds me a lot of Ruby's gem ecosystem. You can have a tool or framework that is well-supported and has a community of contributors creating awesome plugins and extensions to elevate the framework's capabilities.
00:05:46.240
With Webpack, you create loaders that teach it how to compile more complex languages like Sass or CoffeeScript, much like you would create a Ruby gem to handle different processing needs. The relationship between Ruby gems and Webpack plugins is quite similar.
00:06:05.760
The complexity of Webpack arises from its classification. It can act as a compiler, however, it can also feel like something else entirely. Compilers vary greatly, and each has a different purpose, making it challenging to establish a standard for compilation.
00:06:30.720
What I’ve found is that Webpack not only compiles your code but also optimizes it for delivery. Every tool has its own way of converting languages into interpretable JavaScript, and Webpack automates and optimizes this process.
00:06:54.800
The primary proposition of Webpack lies in its extensibility. You start with JavaScript, but then you build loaders and plugins, enhancing the core functionality to meet community needs. The ultimate goal is to optimize code for efficient browser execution.
00:07:18.640
Now let’s consider why we should integrate Webpack directly into Rails. Whether you use Webpack out of the box or rely on the Webpacker gem, there are significant benefits to embracing this integration.
00:07:44.560
Webpack is an effective tool for managing JavaScript applications on its own, but when combined with Rails, it offers additional advantages. As an accepted tool in the Rails community, it provides a smoother experience for developers.
00:08:09.360
The idea is not just to promote the Webpacker gem, but to highlight how Rails can improve accessibility for developers that want to dive deeper into JavaScript and modern tooling. The Rails asset pipeline has been around since Rails 3.1 and served its purpose well, but it might not cover all modern needs.
00:08:35.520
The asset pipeline was initially introduced to organize scattered JavaScript, CSS, and other front-end languages for a better workflow. It made it easier for developers to embrace new languages through gem interfaces.
00:08:54.240
The asset pipeline revolves around three main concepts: concatenation, minification, and preprocessing. In practical terms, this means that when you write Sass, for example, you can transform it into optimized CSS through the asset pipeline.
00:09:18.240
This parallels with Webpack’s functionality. While Rails has its asset pipeline, Webpack also processes files to create optimized assets for delivery. Both tools essentially achieve similar outcomes, optimizing code to be browser-ready.
00:09:45.360
Despite their different communities, Rails and the JavaScript community are entering a space where they may be able to cooperate more closely, leveraging each other’s strengths.
00:10:05.320
There might be apprehension that integrating Webpack might create overlap rather than cooperation. However, by using Webpacker, Rails can process modern JavaScript more effectively, allowing for a seamless integration.
00:10:31.680
Having a community-supported and consistent option for using Webpack in Rails can reduce configuration challenges for developers. Consistency is what allows Rails to thrive.
00:10:54.880
When you dig deep into various Ruby gems that connect frameworks into Rails, the implementation may differ significantly. A solution backed by community effort—like Webpacker—can bridge the gaps.
00:11:19.760
It's about enhancing support for front-end languages without needing to rely on a separate gem library. The goal is to ensure existing Webpack projects can transition smoothly into Rails.
00:11:46.080
Ultimately, it’s about making Rails more accessible for developers passionate about Webpack. Many developers today primarily code in JavaScript and are keen on incorporating back-end solutions that support their existing skill set.
00:12:02.960
This provides opportunities for back-end frameworks, particularly in a landscape where companies increasingly leverage JavaScript for their front-end solutions.
00:12:21.680
For existing Rails users, having easy access to Webpack is crucial. There’s a learning curve, but providing access to these modern tools is essential for addressing the frustration with configuration and setup.
00:12:39.520
Our goal as developers should be to integrate these new ideas without the heavy burden of configuration. For many, the complications associated with Webpack make them reluctant to take advantage of its benefits.
00:12:58.400
We want to make coding with frameworks like React easier, avoiding the complex setup that can often lead to frustration. The emergence of new ideas often requires a paradigm shift.
00:13:17.840
Now, let’s discuss TurboLinks briefly. I’m not here to trash TurboLinks; rather, I want to emphasize how introducing new concepts also means convincing the community of their value.
00:13:35.520
TurboLinks has had both its advocates and detractors, depending on user experiences. The challenge is introducing an idea and rallying support for it. Some concepts succeed, while others might not take off.
00:13:54.960
With the introduction of something like TurboLinks, you need to demonstrate its efficacy to gain traction. This applies to various initiatives in Rails and outside of it.
00:14:15.760
Webpack integration via Webpacker is significant. It binds a successful, existing solution to Rails, resulting in less need to sell the concept or its benefits.
00:14:30.560
Because you’re here, you probably have some interest in using Webpack, whether for tutorials or deeper exploration. Webpacker simplifies the transition process.
00:14:49.440
I appreciate discussing architecture, especially around how Rails is evolving and combining microservices and monolithic structures.
00:15:03.520
My proposition is to consider the merits of a microservice ecosystem alongside Rails. Each piece functions more modularly, handling individual tasks without overcomplicating the system.
00:15:28.960
With Rails, we can manage a multitude of front-end and back-end technologies cohesively, avoiding the chaos associated with managing numerous separate microservices.
00:15:47.680
So, if you were to work with Rails and Webpacker, you'd have a more integrated approach to managing JavaScript assets without needing separate configurations.
00:16:07.200
While not every framework is Webpack-friendly, Rails can still support various existing solutions. For instance, my workplace uses Ember.js, showcasing how Webpack projects can tie into Rails.
00:16:27.440
As developers, we should be willing to embrace Webpack and other modern tools. There's immense potential for the Rails community to synergize with popular JavaScript frameworks.
00:16:42.400
We should continue to explore why projects like Webpacker are beneficial to Rails and create pathways for languages and frameworks that interface well with our codebases.
00:17:00.240
Ultimately, our goal is to ease the integration process rather than overcomplicate it with numerous dependencies and unnecessary configuration. The spirit of Rails and Webpack should harmonize.
00:17:19.840
I've shared a lot of ideas, and if you have any questions, please come talk to me afterward. I have a flight to catch soon, but I'd love to connect with you.
