Webpacking for the Journey Ahead
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Serientitel | ||
| Anzahl der Teile | 88 | |
| Autor | ||
| Lizenz | CC-Namensnennung - Weitergabe unter gleichen Bedingungen 3.0 Unported: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen und nicht-kommerziellen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen und das Werk bzw. diesen Inhalt auch in veränderter Form nur unter den Bedingungen dieser Lizenz weitergeben. | |
| Identifikatoren | 10.5446/37355 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache | ||
| Produzent | ||
| Produktionsjahr | 2018 | |
| Produktionsort | Pittsburgh |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
|
RailsConf 20185 / 88
9
14
16
19
20
22
23
26
27
28
34
35
36
37
38
39
41
42
46
47
53
57
60
62
63
64
69
72
80
85
87
00:00
InternetworkingBenutzerbeteiligungInternetworkingBrennen <Datenverarbeitung>DiagrammXMLComputeranimation
00:54
PRINCE2Computerunterstützte ÜbersetzungBestimmtheitsmaßInternetworkingComputeranimationXMLUML
01:23
BenutzerbeteiligungMereologieSoftwareentwicklerComputeranimation
01:57
FaserbündelCodeModul <Datentyp>ClientBenutzerbeteiligungSchnelltasteFaserbündelArithmetisches MittelBrowserCodeSoftwareentwicklerBimodulHyperbelverfahrenComputeranimationXML
02:48
Cloud ComputingBrowserFront-End <Software>CodeStützpunkt <Mathematik>BenutzerbeteiligungAbstraktionsebeneFormale SpracheDatenflussGraphComputeranimation
03:35
RFIDAbfrageGlobale OptimierungProgrammbibliothekProgrammbibliothekMultiplikationsoperatorProzess <Informatik>Konfiguration <Informatik>BenutzerbeteiligungCodeBootstrap-AggregationPunktSoftwareentwicklerStandardabweichungXMLComputeranimation
04:42
RechenwerkBitMinkowski-MetrikVersionsverwaltungKonfiguration <Informatik>QuaderSoftwareentwicklerComputeranimationXML
05:25
SpezialrechnerFramework <Informatik>RechnernetzMultigraphProgrammbibliothekSoftwareDifferenteCDN-NetzwerkPunktArithmetisches MittelXMLUMLComputeranimation
06:20
Globale OptimierungDigitale PhotographieApp <Programm>PunktCodeGlobale OptimierungComputeranimation
06:46
Framework <Informatik>SystemprogrammMaßerweiterungPaarvergleichFramework <Informatik>Plug inFormale SpracheCloud ComputingSystemprogrammCASE <Informatik>MAPMaßerweiterungComputeranimation
07:52
Cloud ComputingInterface <Schaltung>Plug inDifferenteGraphCloud ComputingCodeSchnittmengeMaßerweiterungComputeranimation
08:20
CompilerCodeVerband <Mathematik>BootenFaserbündelMaßerweiterungCloud ComputingFramework <Informatik>CodeFunktionalStandardabweichungCompilerVererbungshierarchieDifferenteSampler <Musikinstrument>BrowserFaserbündelPlug inFormale SpracheBootenCASE <Informatik>Computeranimation
10:03
Installation <Informatik>Formale SpracheDesintegration <Mathematik>Elektronische PublikationVarietät <Mathematik>CodeFunktion <Mathematik>Interface <Schaltung>Wrapper <Programmierung>BrowserMessage-PassingCodeMereologieImplementierungApp <Programm>Brennen <Datenverarbeitung>Formale SpracheSiedepunktArithmetisches MittelTypentheoriePunktFront-End <Software>StreuungVererbungshierarchieMaßerweiterungSaaS <Software>XMLComputeranimation
12:51
PräprozessorCloud ComputingCodeAbstraktionsebeneGlobale OptimierungCross-site scriptingProzess <Informatik>CodeSampler <Musikinstrument>PunktAbstraktionsebeneGlobale OptimierungComputeranimation
13:54
Funktion <Mathematik>SpeicherabzugMaß <Mathematik>FreewareKartesisches ProduktServerProdukt <Mathematik>MultiplikationsoperatorComputeranimation
14:27
ÄhnlichkeitsgeometrieEinsDifferenteComputeranimation
15:26
ÄhnlichkeitsgeometrieSoftwaretestFunktion <Mathematik>IterationÄhnlichkeitsgeometrieBildgebendes VerfahrenFramework <Informatik>CodeKartesische KoordinatenEinfügungsdämpfungGraphAuswahlaxiomGlobale OptimierungEin-AusgabePerspektiveApp <Programm>Quick-SortProzess <Informatik>Computeranimation
17:06
Konfiguration <Informatik>WiderspruchsfreiheitProgrammbibliothekTranslation <Mathematik>VerschlingungTurbo-CodeZweiKonfiguration <Informatik>Front-End <Software>Arithmetisches MittelDienst <Informatik>GruppenoperationARM <Computerarchitektur>Projektive EbeneBenutzerbeteiligungCodeFormale SpracheKonfigurationsraumSoftwareentwicklerFramework <Informatik>PunktReelle ZahlSondierungRechenschieberZahlenbereichBitGüte der AnpassungImplementierungTranslation <Mathematik>ProgrammbibliothekDifferenteMultiplikationsoperatorEuler-WinkelMetropolitan area networkMereologieXMLComputeranimation
22:52
Desintegration <Mathematik>Architektur <Informatik>Framework <Informatik>MereologieAussage <Mathematik>Web logSchnelltastePunktArithmetisches MittelKonfiguration <Informatik>Front-End <Software>CodierungSoftwareentwicklerFramework <Informatik>SichtenkonzeptDienst <Informatik>IntegralBildschirmfensterKonfigurationsraumServerOffene MengeCodeGarbentheorieKlasse <Mathematik>SpeicherabzugComputerarchitekturMultiplikationsoperatorXMLComputeranimation
28:31
ÄhnlichkeitsgeometrieKonfiguration <Informatik>Framework <Informatik>CompilerProzess <Informatik>KonfigurationsraumProgrammfehlerServerLesezeichen <Internet>SchnelltasteDreiecksfreier GraphComputerspielFramework <Informatik>SystemprogrammMultiplikationsoperatorDefaultPunktSchnittmengeÄhnlichkeitsgeometrieSoftwareentwicklerSystemplattformComputeranimation
32:07
COMp-BlockDatentypJSONXMLComputeranimation
Transkript: Englisch(automatisch erzeugt)
00:14
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,
00:21
so it's pretty cool to come back here and actually speak about stuff. So anyways, let's get going here. My name is Taylor Jones, and this is a talk called Web Packing for the Journey Ahead. So before we start, real quick, I'm gonna give you a quick introduction of me and who I am. I'm on the internet under Hi, I'm Taylor Jones,
00:41
often constantly misrecognized as him, Taylor Jones. It's 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, we got a dog that is spoiled rotten,
01:04
and I had no idea how he was gonna handle it. Got some cats too, but my day job, and 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 move to Orlando and write some cool Ruby code,
01:21
please come talk to me or hit me up in the internet. All right, so back to the talk here. This whole thing, right, is based largely around Web Pack, and Web Pack is pretty misunderstood because it's kind of the trendy thing that everybody's into these days. But more specifically, I wanna talk about Web Pack and Rails, and the justification
01:42
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 they worked together,
02:01
and why would we actually wanna bind them together? Because that's the purpose of the Web Packer gem is 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 in the past couple minutes, let's do a quick primer before we dive into the actual Rails stuff of it.
02:21
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,
02:41
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 and optimizing front-end code bases as a whole much easier. So I have a crudely keynoted graph together here
03:02
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,
03:20
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, where it might be needed. So the goal of this whole thing is generating code that's optimized for execution by the browser, as I mentioned before,
03:42
and I'll probably mention it a few other times because it's a huge point of Web Pack. So if anyone remembers back in the day when we had jQuery and then 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.
04:03
We have that in Bootstrap.min.js or CSS or anything like that. So what I wanna talk about is kind of the history of how we used to optimize Go for the web, how Web Packers come into that, and what exactly is going on, right? So we're taking, when we're making a library minified
04:21
or putting .min to it, we could totally just put .min to the end of the library, right? 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 wanna kind of walk through what the minification process would look like.
04:40
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, everything that 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.
05:01
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 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?
05:21
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 kind of 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?
05:40
That's a way that we could optimize it if we kind of had those assets or those things ready for us. So the problem is, and it still kind of persists today, is that the difference in experience from these tools is way and totally different, meaning that some tools have these things and others didn't. And Webpack is found popularity
06:01
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.
06:20
So if there was a pitch, I think, that people would put on billboards for 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
06:42
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?
07:01
Like what do we actually do with that? So Webpack's true utility is rooted within its ecosystem and 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 Ruby's gem ecosystem.
07:21
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,
07:42
like say you use Sass, right? You're gonna write a Sass gem. If you write Sass CSS and you're a JavaScript developer, you're gonna say, hey, I'm gonna write a Sass Webpack plugin. So I'm talking about the difference between Ruby gems and Webpack plugins and how they're actually really, really similar. So again, another crudely drawn graph
08:01
for your viewing pleasure, but you have the idea, right, of Rails and then the gem is just an extension that you append to it and it interprets that Sass 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 Sass.
08:21
For Webpack, we have the same thing. Webpack's obviously not as big as a framework as our tool is Rails because, you know, Rails offers a lot more, but for Webpack's purpose, you're taking that Sass again and you're building extension that allows Webpack to understand, interpret, compile, deliver Sass.
08:42
So with this said, Webpack's super hard to classify. It might seem like it's a compiler. In many cases it is, but if you also look at it, it kind of feels like something else entirely because compilers are somewhat definitive in nature, right? If you have a bunch of compilers
09:00
that are totally different and 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 you, every tool like a JSX or something like that might have some kind of hand built thing
09:23
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 do with extendable Webpack
09:42
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
10:01
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 all sold. You thought that was the greatest sales pitch ever and you're totally convinced that Webpack
10:21
is gonna be the usage for all your apps ever, forever, and always. Why directly integrate in the Rails? This is what the whole kind of talk leans on 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 Webpack with your JavaScript or maybe a gem might have an implementation
10:41
where it brings Webpack support into Rails, like why would you embrace something like Webpacker? 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 for folks. But what I think that I see with it
11:03
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 in the JavaScript community to 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.
11:21
So this all boils down to the asset pipeline. Odds are most people use asset pipeline. I've used 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,
11:40
was that we kind of introduced the idea in RailsConf 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
12:00
become better into that Rails workflow. And really, again, the reasoning behind it is organizing JavaScript, but also supporting new languages via gem interfaces, which I thought was super interesting, but I kind of forgot about because, again, I took it for granted. I was like, oh, there's a SaaS Rails gem, or there's a, you know, your HML, or any other kind of extension you might use.
12:21
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,
12:42
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 asset pipelines, it's really based around three ideas, concatenation, minification, and pre-processing,
13:02
all that stuff you dump into it. And from just a practical point of view, and this is pretty simple if you understood kind of how compilation works and breaking that down, right, is that we're taking a SaaS, 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,
13:21
any kind of compressors, and we're getting our, quote unquote, optimized CSS. This allows for us to write that abstract code in SaaS, but have it also directly compile to CSS and automatically be inserted into the asset pipeline for optimization. Again, a very huge oversimplification of the great work that people have done
13:41
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 to Webpack. And that's because it kinda is. We take, you know, a thing like Rake Assets Free Compile,
14:02
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 Free Compile a bunch with a production flag, and it eventually works on my servers. That's kinda how I learned to deploy
14:21
because I went to school and ignored everything that was told to me. So anyways, these ideas are really, really similar to Webpack. And I see Webpack and Asset Pipeline are two similar tools used by completely different communities, right?
14:41
Like Rails has always had the asset pipeline for a while, not always, but since, you know, Rails 3.1, 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
15:03
because in recent years, if you noticed, Rails JavaScript and non-Rail 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 CoffeeScript,
15:21
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 kinda 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.
15:40
So again, here's another crudely drawn graph reviewing pleasure, but you have a, with Webpack, right, you have a bunch of JS code, or CSS, or anything else like that, you're passing 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 the pipeline, and you're getting easily a JS manifest and a CSS manifest.
16:01
You break down the browser, which I wish I'd insert an image to that, but, you know, you just see your application.css and your JavaScript.css that we'll 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 a make optimizer browser,
16:23
and we're having it run through our tool of choice. So it might seem weird that we're kinda wanting to integrate them together or have them work together because they have kinda 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,
16:41
but the heart and the approach of saying, okay, I have this stuff and I wanna process it, I think what Webpacker allows to do is for Rails to process more modern JavaScript quicker in a way that that community processes it, right? The Rails community may approach JavaScript one way,
17:01
but JavaScript as a whole, with their community, might have another approach to it. So, again, why do we need a Webpacker, gem for Rails? Why not just use Webpack by itself? And I wanna give a few reasons here. One of the biggest things that I see is for the sake of having a consistent option
17:21
for those who use Webpack, we talk a lot about making Rails more accessible. I think DHH kinda mentioned a little bit this morning, right, is like we still want to have those same attitudes. We wanna be able to bring people, kind of give people an easy way to worry about the stuff that actually matters and not necessarily be overburdened by like,
17:40
well, I use Webpack, but it's really a pain in the butt to configure for Rails or to embrace that, right? I think that 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
18:00
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 gonna see things that maybe 200 people working on a solution might see.
18:21
So I think what I see out of all this is you have a better, faster, and stronger support for front-end languages that don't require a gem library to be supported. And ideally, there should be little and no translation required for existing Webpack projects to live in Rails or Web.
18:40
And so the heart behind that, right, is that we want to make that transition easy. And that's never 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 increase that canopy
19:03
of accessibility across the whole community. And finally, it's about making Rails more accessible to those who love Webpack. I think what we find, and this is what I've found at least with my small bit of experience, is that you have a lot, a lot of people
19:21
programming JavaScript these days, and only JavaScript. If we could show surveys or whatever we wanna do to prove that, but the point is, a lot of people are just programming only JavaScript these days. Whereas at JavaScript, it seemed like for a while, it was definitely my experience, was like a, oh, I guess I'll do this, it's kind of annoying, I kinda just wish
19:41
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
20:01
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
20:20
is encouraging existing Rails users to have easy access getting started with Webpack. If I'm being honest, I don't feel like a old man yelling at a cloud, but there are times where I felt, or seen stuff in the JavaScript community that's come apart, like I thought React was super dumb for a really long time. I'll admit that, I should probably actually buy a shirt.
20:42
But I was like, I don't understand why you need this. This is ridiculous and this is programming stupid. I quit, right? But the thing is, is that we eventually, if the idea's good enough, it usually tends to stick around. And it usually, there comes a point where as developers we have to confront that idea.
21:02
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 bane for so long, right? If you ask any JavaScript developer, they'd be like, oh man, I just hate configuring Webpack, it's so ridiculous, it's like a waste of my time,
21:21
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 do what you're doing, man, because I use Rails and I don't have to worry about that as much and why would I do that? So I think the hope and the heart behind the whole thing is saying, why don't we have the means for us to come and just jump into coding React
21:42
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. It's based around buy into those new ideas, right? So for those who are bought into Webpack,
22:01
we want an easier way for them to buy into Rails. For those who are bought into Rails, we want an easier way for them to buy into Webpack. So we wanna kind of have things go both ways. And so now here's my favorite slide because it makes people kinda knee-jerk React real quick, is we're gonna talk about Turbolinks for a second. And it's actually not gonna be about trashing Turbolinks,
22:22
so sorry if you're looking for a good old like Turbolinks roast, it's not happening today. But Turbolinks has been a project that's been 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?
22:41
Like if you use Turbolinks, you're probably making cool stuff in Turbolinks, and that's maybe good, right? It's better than just having something and being like, I don't know why I have this in my project, 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 Turbolinks, right, is that you have to introduce a new idea, say, hey, I've been making this,
23:01
which is usually how a lot of 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.
23:21
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 base camp guys and girls, and it's pretty cool. But it's probably the same stuff. Again, you have to introduce that new idea, like, hey, we're jumping into the front-end framework game,
23:42
here's what our solution is working for us and making cool stuff, or we're making cool stuff with it. But also, you know, they have to sell it, and that's totally normal, because again, 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 and opt out.
24:04
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
24:21
and you're looking for, like, 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.
24:40
But this does bring up some architectural concerns, and I do like to talk about architecture because that's what I did last year and it was a lot of fun. Instead of being separate things that are more micro-service, like you're moving to monolithic territory. And this is not a bad thing, right? In Rails, we talked about the majestic monolith. A lot of people are bought into that. Maybe people write their blog posts about it
25:02
and they get really excited and they get so much class and 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 gonna keep running with it until it either fails miserably, so please tell me if it's an awful idea, but it's the idea of the mighty micro-service ecosystem.
25:21
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 micro-services 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 we refine each piece of Rails more and more,
25:43
we're seeing that sections of Rails are becoming more, they almost function like smaller micro-services. 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
26:04
and have this means of, I don't know if you've ever worked with micro-services before. Actually, quick poll. Who here works in micro-services? Like, you got more than five micro-services running around, right? Cool, so there's like a sizable amount of people. Everybody else is in a monolith, I assume.
26:20
Is that kind of the vibe, maybe? Yeah, no code, maybe? No, yeah. So yeah, a lot of times we're using one of the T, right? But the cool part about it is that the trouble I've found with micro-services is that they're just really annoying to have five code windows open if you're trying to make a change, right?
26:40
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 of this whole thing, it says like, what if you could not have to run a Webpack server and configure something separately
27:00
and then hope it passes it to the Rails system, which hopes Rails catches it and 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, which I think is really exciting for me as a developer and I'm kind of hoping that there's more and more
27:20
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 micro-services and I think that's kind of funny, but at the same time, I think it's the proposition that Webpacker is making.
27:41
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 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.
28:01
Or if you're just wanting to get started in a smaller, more module-based scholarship, right? Like it's not like you have to say like, oh, I'm only gonna use Webpack 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?
28:20
Does it mean that Rails is only supporting in a first-class manner Webpack-friendly frameworks? It might seem like that's the case, but the big twist of all this whole thing is that Isaiah actually uses Ember.js and so that's actually my day job is dealing with stuff. So it might seem completely silly and stupid that I did a talk with Webpack.
28:41
And maybe that's the great risk of my career is that I do really stupid things for like no reason because it's snowing and I live in Orlando, so like 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
29:01
and spend 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.
29:21
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 RailsConf 2011, people are like,
29:40
oh man, we're using jQuery now. We're like totally modern. We have got it figured out, we're gonna stay with jQuery for 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.
30:02
But the thought of it to me is the fact that, okay, we're taking something that has a 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.
30:23
And so for me, it's hoping that if Webpacker has more and more success, and it hasn't had a considerable amount of success, right, because lots of people are coding React or Angular, those are two really big frameworks 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
30:43
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 over earlier that I do want to come back and talk about real quick is the idea, right, and the whole utility of this, of having a Webpacker gem or using Webpacker
31:02
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 running a bunch of servers
31:22
and not really knowing about it, right, or having to really dive deep into a bug that you don't quite understand. I think so Webpacker kind of exposes that configuration aspect for us instead of 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.
31:41
Thank you for coming out. 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've 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
32:02
so thank you guys very, very much.