 Thank you for coming today, this is really, really cool. I actually attended my first tech conference in this very room a couple years ago, so it's pretty cool to come back here and actually speak about stuff. So anyway, so let's get going here. My name is Taylor Jones, and this is a talk called Webpacking for the Journey Ahead. So before we start real quick, I wanna give you a quick introduction of me and who I am. I'm on the internet, under hi, I'm Taylor Jones. Often constantly misrecognized as him, Taylor Jones. Hi, I'm Taylor Jones. It's me trying to be smart and try to work on some hashtag branding for the world, but if you wanna see what I'm up to, odds are I'm probably somewhere under that handle. I'm trying to figure this whole baby thing out. I'm about to have my first kid in a few months. I'm excited about that. I've got, thank you, I got, we got a dog that is spoiled rotten and I had no idea I was gonna handle it. Got some cats too, but my day job when I'm not hanging out with pets and stuff is to work at IZEA. And we're in Orlando, Florida and we're making cool stuff. We're also hiring, so if you wanna meet Orlando and write some cool Ruby code, please come talk to me or hit me up in the internet. All right, so back to talk here. This whole thing, right, is based largely around a web pack and web pack is pretty misunderstood because it's kind of a trendy thing that everybody's into these days. But more specifically, I wanna talk about web pack and Rails and the justification for why us as a community is even embracing it. And so for me, part of this talk was like just figuring out what the kind of rationale for the rest of the community was, right? But it was also for understanding why I'd wanna pursue it personally as a developer. So we'll ask how well do they work together and why would we actually wanna bind them together? Because that's the purpose of the web pack, and I encourage you on this, to kind of bind web pack and Rails together. So if you're confused about web pack or you don't know about it or you haven't looked at the past couple of minutes, let's do a quick primer before we dive into the actual Rails stuff of it. So web pack is used as a means for bundling together modules of JavaScript code. And it takes those bundles and optimizes them based on your preferences and it takes the dependency-driven code and turns it into static assets so it can be better executed by the browser. Rails developers had this kind of stuff for a while with Asset Pipeline, which we're gonna talk about later. But for the JavaScript community, this is the bread and butter by which they actually optimize and deliver their assets. So the TLDR of web pack is that it makes compiling, automating, front-end code bases as a whole much easier. So I have a crudely key-noted graph together here about maybe how a flow of web pack might work. Where we take a front-end code base, you run it through web pack and we get static assets. Another way to maybe look at this would be to say you have your abstract languages and you're passing them through web pack to get something that's more browser-oriented. So all these languages that are more abstract, I mean JS is not an abstract language per se, but stuff like JSX and handlebars, it's an abstraction on top of those languages. And web pack takes that and actually compiles it to JS, HTML, CSS, whatever might be needed. So the goal of this whole thing is generating code that's optimized or executed by the browser as I mentioned before and I'll probably mention it a few other times because it's a huge point of web pack. So if anybody remembers back in the day when we had jQuery and the jQuery.min.js, if you go to the website today, you can probably, there's like 50 options that you can do to download any kind of flavor or idea of jQuery. And it was also implemented in stuff like Bootstrap, we have that in bootstrapmin.js or CSS or anything like that. So what I want to talk about is kind of the history of how we used to optimize code for the web, how web packers come into that and what exactly is going on, right? So we're making a library minified or putting .min to it. We could totally just put .min to the end of the library, right? Like I can just do nothing. There's no standard of minification. But a lot of times it's how developers would consider their libraries more optimized. So I want to kind of walk through what the minification process would look like. You can maybe remove spaces, right? You could say, hey, I've got this JavaScript and I want to just remove all the spaces and have it be a giant one-liner. And so that way a browser or anything executes it doesn't have to look through those spaces. So it saves you a little bit of time, right? We could drop dependencies we don't use. So this is an example, I was talking about with jQuery. It's like, all right, you got an option to choose which version you want. But then you have all these check boxes that you can say, oh, well, I only really want these selectors or these options or I'm not to make myself feel old as a developer because I'm really not that old when it comes to that. But do I want jQuery UI? Do I want whatever library, right? And I think that's what made jQuery really useful. You could preload external network dependencies or downloads if you've ever worked with CDNs and optimizing your delivery and not necessarily having a point of failure and like, hey, does this library CDN work or not or how fast is it? That's a way that we could optimize it if we had those assets or those things ready for us. So the problem is, and it still persists today, is that the difference in experience between these tools is way and totally different. Meaning that some tools have these things and others didn't. And Webpack is from popularity because it helps remedy that issue. That's especially for the JavaScript community because as we look at stuff like MPM and Yarn, you have these insane amounts of dependencies and just these really deep graphs that really need to kind of maybe be optimized further past just a tool. So if there was a pitch, I think that people would put on Billboard's Webpack, it would be that it's the one-stop-shop for all your optimization needs. And it sounds kind of cheesy and this is like literally the cheesiest photo I could find on the internet. But what it does have a point of is that it's pretty much just like a, hey, I have a JavaScript app that does module-based code or has like a lot of code that needs to be optimized. Like, let me just use this and it's really just taken off as a solution. So Webpack has support for JavaScript out of the box. But what about the thousands and thousands of ever-growing languages that we are using with JavaScript these days? Like, what do we actually do with that? So Webpack's utility is rooted within its ecosystem and a community of plugins that extends its reach just beyond JavaScript. What this really reminds me of and really is kind of getting to the meat of the talk is it reminds me a lot of really this gem ecosystem. You have this idea of a really well-supported, well-adopted tool or framework and you have lots of people who are really great and bought into it, making some really awesome, either plugins, gems, extensions to help take that framework to the next level or to process maybe your use case of tooling. Like you say you use SAS, right? You're gonna write a SAS gem. If you write SAS CSS in your JavaScript developer, you're gonna say, hey, I wanna write a SAS Webpack plugin. So I'm talking about the difference between RubyGems and Webpack plugins and how they're actually really, really similar. So, again, another crudely drawn graph for your viewing pleasure, but you have the idea of Rails and then the gem is just an extension that you append to it and then interpret as that SAS. And this is obviously a very open simplification of how a gem might work, but essentially you're just taking that base set of code and you're adding something that helps interpret, compile, and deliver SAS. For Webpack, we have the same thing. Webpack's obviously not as big as a framework or tool as Rails because Rails offers a lot more, but for Webpack's purpose, you're taking that SAS again and you're building extension that allows Webpack to understand interpret, compile, deliver SAS. So what this has said, like Webpack's super hard to classify. It might seem like it's a compiler. And in many cases it is, but if you also look at it, it kinda feels like something else entirely because compilers are somewhat definitive in nature, right? If you have a bunch of compilers that are totally different, I mean totally different things or totally different makeup, you really don't have a standard of compilation. You just have a bunch of different compilers that do different stuff. So I think what I've found is that Webpack not only compiles your code in some way, but also optimizes it. And that's the whole pitch of it, right? Like every tool like a JSX or something like that might have some kind of hand-built thing that will compile it and give it into interpretable JS, but what Webpack does is it takes all that code and it compiles and optimizes it for again for browser delivery. So I would say the pitches of Webpack is that it's the extendable compiler. So what you're able to deal with extendable Webpack that I think is super interesting is that you're, again we have that baseline of Webpack only really understanding JavaScript. We create loaders to help teach Webpack how to compile more complex languages configurations. These plugins help compress, minify, and manipulate existing bundles. So again, we're taking that base functionality and we're extending it beyond to what actually the community's needs are. So the end goal of this code is optimized for browser execution. So that's the kind of run on the Webpacker primer. So we're gonna just pretend for a second that maybe we're sold, we're all sold. You thought like that was the greatest sales pitch ever and you're totally convinced that Webpack is gonna be the usage for all your apps ever forever and always. Why directly integrate in the Rails? And this is what the whole kind of talk LeanZone is that Webpack is an effective tool right now outside of Rails. It's just another thing that you're running. So if you wanna use Webpacker with your JavaScript or maybe a gem might have an implementation where it brings Webpack support into Rails, like why would you embrace something like Webpacker? And so I think part of this comes off as a pitch for using the Webpacker gem and there's some great people building it. I've only really written documentation to help understand and communicate that message folks. But what I think that I see with it is this from the overall Rails as a full story point of view is that we're starting to really embrace these tools and kind of have a means for people of the JavaScript community to kind of come in and get to know Rails better. So we're gonna kind of run over that kind of stuff and see what's good there. So this all boils down to the asset pipeline. Odds are most people use asset pipeline. I use it pretty much in most of the things that I've done. I'm sure if you don't use it I would love to hear your implementation. I'm sure it's super interesting. But the asset pipeline from what I know because I started at Rails 4.0 was that we kind of introduced the idea in Rails Comp 2011 around Rails 3.1. And it was really a solution to saying, all right, I have all this scattered JavaScript CSS front end type languages and I want a better way to support that. I want a better way to organize that and I want a better way for that to become better into that Rails workflow. And really, again, the reasoning behind it is organizing JavaScript but also supporting new languages by a gem interfaces which I thought was super interesting but I kind of forgot it out because again, I took it for granted. I was like, oh, there's just a SAS Rails VM or there's a, you know, your eight and your Hamel or any other kind of extension you might use. And so it was really a way to easily embrace whatever new language idea thing that you want to implement in your app. And also integrate those into the Rails workflow. So it set us up as a community for this ability to really support whatever else was new without having to say, all right, well, you know, the wizards at the top of the mountain of Rails have decided that you can only use these three languages or things. And so that was really exciting, I think, for the community. So if you go kind of do some research and digging on the asset pipeline, it's really based around three ideas. Concatenation, minification and preprocessing, all that stuff you dump into it. And from just a practical point of view, and this is pretty simple, if you've understood kind of how compilation works and breaking that down, right, is that we're taking a SAS, for example, we're breaking that down to CSS and then maybe we're gonna run it through the asset pipeline or anything else that we might do, any kind of compressors and we're getting our, quote unquote, optimized CSS. This allows for us to write that abstract code in SAS, but it have it also directly compile to CSS and automatically be in certain asset pipeline for optimization. Again, a very huge oversimplification of the great work that people have done with Gems over the years, but I think that it's about, I wanna talk about the heart behind everything here. So this all sounds really, really, really familiar. It's a webpack. And that's because it kinda is, we take a thing like rake assets pre-compile where we're taking all our JavaScript, our CSS, all our stuff, and we're compiling it with stuff that is optimized for delivery and for consumption. And we a lot of times maybe do that in our production settings. If you're learning Rails, you've probably done what I've done where I just hammer rake assets pre-compile a bunch with a production flag and it eventually works on my servers. That's kinda how I learned to deploy because I went to school and I ignored everything that was cool to me. So anyways, these ideas are really, really similar to webpack. And I see webpacker or webpack, an asset pipeline are two similar tools which is like completely different communities, right? Like Rails has always had the asset pipeline for a while, not always, but since Rails, we have one, they've had the asset pipeline to kinda help us deal with that. With the JavaScript community, they've had various solutions but webpack is the most, by most one of the most popular ones right now. So, and it's also interesting because in recent years, if you noticed, Rails JavaScript and non-Rails JavaScript have started to look pretty similar. You have some companies that are maybe doing what people might consider more Rails flavored JavaScript. You know, a lot of the community embrace Kafka script, a lot of those ideas, and still do and they're great in making some awesome stuff with that. But there's a really, there's a need again because there's a need to kind of incorporate those workflows because more people are starting to use stuff like React or Angular or any sort of other kind of framework in their apps. So again, here's another crudely drawn graphic viewing pleasure, but you have a, with webpack, right? You have a bunch of JS code or CSS or anything else so that you pass it through webpack and you get static assets. With asset pipeline, you have a very similar thing. You're taking your files, you're passing it through pipeline and you're getting easily a JS manifest and a CSS manifest. You break down the browser, which I wish I'd insert image to that, but you know, you just see your application.css and your JavaScript.css that will digest. So, if we just think about it from the perspective of input and output, right? We're really doing the same thing. We're taking our code that we want to have compiled and shoved into the browser, make optimized for browser and we're having it run through our tool choice. So it might seem weird that we're kind of wanting to integrate them together or have them work together because they have kind of similar approaches and there might be a worry, right? That they're overlapping each other or that they're really fighting against each other in some ways they are, but the heart and the approach of saying, okay, I have this stuff and I want to process it. I think what webpacker allows to do is for Rails to process more modern JavaScript Quikram in a way that that community processes it, right? The Rails community may approach JavaScript one way, but JavaScript as a whole, like what their community might have another approach to it. So again, why do we need a webpacker or a gem for Rails? Why not just use webpack by itself? And I want to give a few reasons here. One of the biggest things I see is for the sake of having an assistant option for those who use webpack. We talk a lot about making Rails more accessible. I think GHH kind of mentioned a little bit this morning, right? It's like, we still want to have those same ideas. We want to be able to bring people, kind of have people, give people an easy way to worry about the stuff that actually matters and not necessarily be overburdened by like, well, I use webpack, but it's really a pain in the butt to configure for Rails or to embrace that, right? I think the Rails thrives on consistency. And having a community-supported option for webpack helps out smooth out any differences in implementations we might find. If you really dig beneath a lot of your gems that are maybe taking your frameworks and maybe importing it into Rails, oftentimes you might find that you have some wonderful implementations by some really, really smart people, but sometimes it comes down to a game of numbers. When I have 15 people working together on a solution, they're not going to see things that maybe 200 people working on a solution might see. So I think what I see out of all this is if you have a better, faster, and stronger support for front-end languages that don't require a gem library to be supported. And there's little to, ideally, there should be little in no translation required for existing webpack projects to live in Rails or web. And so the heart behind that, right, is that we want to make that transition easy. And that's ever gonna be the bane of any gem, right? Is that, well, we've designed it for these ways for you to import, but I've got this super special way that you haven't designed for yet. But the goal is to kind of increase that canopy of kind of accessibility across the whole community. It finally is about making Rails more accessible to those who love webpack. I think what we find, and this is what I found, at least, with my small bit of experience, is that you have a lot, a lot of people programming JavaScript these days and only JavaScript. If we could show surveys or whatever we want to do to prove that. But the point is a lot of people are just programming only JavaScript these days. Whereas that JavaScript seemed like, for a while, is definitely my experience, but it's like, oh, I guess I'll do this. It's kind of annoying. Like I kind of just wish I could do this with the backend language. And so a lot of times there are JavaScript developers who are looking for a backend, especially with services like your Firebase or anything else like that that provides you a means to have a backend API and just pay for it. There eventually becomes a point where there's actually just companies out there that are running completely off-front in JavaScript and maybe a serverless backend solution. So the question is what kind of framework are they gonna choose, what kind of developers are they gonna hire when they decide, hey, we've got a couple million dollars in the bank, we wanna hire a backend team. So, and I think the other part of it is encouraging existing real users to have easy access getting started with that pack. If I'm being honest, I don't feel like an old man yelling on the cloud, but there are times where I've felt or seen stuff in the JavaScript community that's kind of a part, like I thought React was super dumb for a really long time, I'll admit that. I should probably buy a shirt, right? But I was like, I don't understand why you need this, like this is ridiculous and this is programming stupid, I quit, right? But the thing is, is that we eventually, if the idea is good enough, it usually tends to stick around and usually there comes a point where as developers we have to confront that idea. And I think that giving people older and newer to programming a means to easily access those new ideas and not necessarily worry about the configuration, excuse me, because that was such the day in for so long, right? If you ask any JavaScript developer, they'll be like, oh man, I just hate configuring webpack, it's so ridiculous, it's like a waste of my time, it's all I do. And so when I hear that, I'm like, I don't wanna code front-end framework, I don't wanna like do what you're doing, man, because I use Rails and I don't have to worry about that as much and like why would I do that? So I think the hope and the heart behind the whole thing is saying, you know, what if we had the means for us to come and just jump into coding react as opposed to configuring something to start coding react because then we get frustrated, we throw up our arms and say, I'm not gonna do this anymore, right? And there's a lot of emphasis and interest in webpack is based around buy into those new ideas, right? So for those who are bought into a webpack, they want to use your way for them to buy in the Rails. For those who are bought into Rails, we want to use your way for them to buy into webpack. So we want to kind of have things go both ways. And so now here's my favorite slide because it makes people kind of knee-jerk react real quick is we're gonna talk about turbo-links for a second and it's actually not gonna be about trashing turbo-links. So sorry if you're looking for a good old like turbo-links roast, it's not happening today. But turbo-links has been a project that's been really, really well for some folks and it hasn't really been cared for by others. It's been kind of the one thing that people are really salty about strangely and that's fine, right? Like if you use turbo-links, you're probably making cool stuff in turbo-links and that's maybe good, right? It's better than just having something and be like, I don't know why I have this in my product but it's here, right? So I think it's totally okay that some ideas don't necessarily stick. But the problem with introducing an idea like turbo-links, right? Is that you have to introduce new ideas and say, hey, I've been making this, which is usually how a lot of the stuff in Rails comes, right? It's like, hey, our awesome company has been doing this cool thing. This is the extraction that we're taking out or calling it whatever. But the other half of it is you have to also sell it to others, right? You have to convince people, hey, this is a good idea and this is why you should use it. The problem is both these things are incredibly hard and they don't always stick. And today we've got stimulus. If you've heard about it, it's kind of a new front-end framework thing by Basecamp guys and girls and it's pretty cool. But it's probably the same stuff. Again, you have to introduce a new idea like, hey, we're jumping into the front-end framework game. Here's where our solution is working for us and making cool stuff or we're making cool stuff with it. But also, you know, you have to sell it and that's totally normal because again, like it's cool to have solutions that work for some people and maybe just don't work for others but at least you have the option to opt-in opt-out. So, webpacker integration via webpacker is special because it's taking something that's already been successful in a community and giving it a means to bind with Rails. And what I think is really exciting about that is that a lot less selling is required with this whole pitch, right? You're probably here because you've heard about webpack and you're looking for like a what is a webpack or maybe looking for a tutorial or a deep dive or whatever, there's a workshop later in the week if you're interested that's kind of dealing with a really like let's just go and just get down to the core of webpacker. But the point being from my perspective is a lot less selling is required for that. But this does bring up some architectural concerns and I do like to talk about architecture because that's what it did last year and it was a lot of fun. Instead of being separate things that are more microservice like you're moving to monolithic territory. And this is not a bad thing, right? In Rails we talk about the majestic monolith. A lot of people are bought into that. Maybe people write their blog post about it and they get really excited and they get so much collapse on medium, right? That's cool. And again, that works for some people. But I kind of proposed this idea last year and I'm kind of going to keep running with it until either fails miserably so please tell me it was an awful idea. But it's the idea of the mighty microservice ecosystem. And what I mean by this is that when we see the development of how Rails is going, it oftentimes feels like an ecosystem of microservices that are all being orchestrated together, right? You have your active record, you have maybe a view layer, you have some middleware, but they're all kind of becoming increasingly as you refine each piece of Rails more and more. We're seeing that sections of Rails are becoming more, they almost function like smaller microservices. You can take it, they're more modular. You can replace them with something else if you want at certain points, right? And so, the whole value that I see of this is that we're able to really come through and have this means of, I don't know if you've ever worked with microservices before. Actually, quick poll, who here works in microservices? Like, you got more than five microservices running around, right? Cool, so it's like sizable amount of people. Everybody else is on a model if I assume, is that kind of a divide, maybe? Yeah, no code, maybe, no, yeah. So yeah, so a lot of times we're using one of the T, right? But the cool part about it is that the trouble I have with microservices is that they're just really annoying to have like five code windows open if you're trying to make a change, right? Like, and you definitely have more smaller, more refined code, something, an idea that is maybe hopefully clean and hopefully makes sense and concise and you understand how it interacts with other services. But the kind of beauty of Rails and the whole proposition, this whole thing, it says like what if you could not have to run a webpack server and configure something separately and it hope it passes it to the Rails system, which hopes Rails catches it, interprets it and delivers the way you want, like maybe you have another front-end service that you're actually delivering the view layer through, you know, it can get crazy. And I think what Rails is kind of navigating towards with the thing that's really exciting for me as a developer and I'm kind of hoping that there's more and more options like this for me and the teams that I work with, but also for maybe you and your teams, is that we're able to have this just kind of one home for all those codes. You know, we're kind of swinging back into more monolithic territory for microservices and I think that's kind of funny, but at the same time, I think it's the proposition that Webpacker is making. And so this actually brings me to one of the more interesting parts of the talk and it's kind of the end of it, but it's, we're talking about for me with non-Webpack citizens, right? Because not everybody in this whole wide beautiful world supports Webpack, right? It all makes sense if you use something that uses Webpack, or if you're just wanting to get started in a smaller, more module-based partnership, right? Like it's not like you have to say like, oh, I'm only gonna use Webpacker for this, right? It'll take anything that you, you can configure it to interpret whatever you want. But there are existing framework solutions out there that aren't Webpack-friendly. So what about those people? Does it mean that Rails is only supporting for in a first-class manner, Webpack-friendly frameworks? They might seem like that's the case. But the big twist of all this whole thing is that IZ actually uses EmberJS and so that's actually my day job, is dealing this stuff. So it might seem completely silly and stupid that I did a little talk on Webpack and maybe that's the great risk in my career is that I do really stupid things for no reason because it's snowing and I live in Orlando, so this is not really cool right now for me. But the point that I see about all this, and I'm actually encouraged by the development of Webpacker and it's why it led me to be really interested and spent a lot of time really wrestling with why. Why are people choosing this? Why does this matter? Why is this actually beneficial to Rails? And the reason for that is that, I would love a solution that would be something similar. Ember uses Broccoli, but let's say that another great framework community comes up tomorrow and they say hey, we're using whatever ridiculous compiler or thing or whatever makes sense to them, right? Because as we've learned, right? You look at Rails Comp 2011, people are like oh man, we're using jQuery now. We're like totally modern. We have got it figured out, we're gonna stay with jQuery forever, we're just, it's never gonna end. And then now everybody's dropping jQuery in their frameworks and that's totally fine. But again, even the best or most popular supported community things have a life cycle. Webpacker ultimately has a life cycle whether we want to admit it or not. But the thought of it to me is the fact that, okay, we're taking something that's really, it has really big community support that has a lot of love out there and we're giving it the ability to really, come into the Rails community in a way that makes sense. And so for me, it's hoping that if Webpacker has more and more success, and it already has had a considerable amount of success, right, because lots of people are coding React or Angular, those are two really big frameworks that a lot of people have been using with it. My hope is that maybe we can start to start thinking about options for other supported platforms because personally I'm a bit tired of having to manage my own custom shotgun solution to making a thing work. And I think that's one of the things that, I kind of glazed at it earlier that I do want to come back and talk about real quick is the idea, right, and the whole utility of having a Webpacker gem or using Webpack is saying that if you've ever looked into how you sometimes bind your favorite framework or idea to Rails, oftentimes it can feel kind of limiting or depending on how refined that solution is, right, you may not have the best experience, you may find yourself like running a bunch of servers and not really knowing about it, right, or having to really dive deep into a bug that you don't quite understand. And I think so Webpacker kind of exposes that configuration aspect for us and said that we're not trusting just a kind of hard-coded set of defaults by another person, but that's the whole talk I've got. Thank you for coming out and thank you for listening to me kind of try to share what I have kind of been just diving through and trying to wrestle with the Webpack. If you got any questions, please come talk to me afterwards. I've actually got to catch a flight out of here pretty soon because of personal and work reasons, but if not, I'd love to keep in contact with you somehow. So thank you guys very, very much.