Code and the Coding Coders who Code it
We talk about Ruby, Rails, JavaScript, and everything in between. From tiny tips to bigger challenges we take on 3 questions a show; What are you working on? What's blocking you? What's something cool you want to share?
Code and the Coding Coders who Code it
Episode 53 - Joel Hawksley
When does a framework reach maturity? For Joel Hawksley, lead maintainer of GitHub's ViewComponent framework, the answer comes with the upcoming fourth major release – a milestone that marks not just new features, but a transition to long-term support mode.
Joel takes us behind the scenes of his seven-year journey at GitHub, where an idea sketched on an airplane has evolved into a critical part of how the platform renders its interfaces. With candid insights, he explains why ViewComponent is now considered feature-complete, and the philosophical challenges that remain unresolved around CSS and JavaScript integration within component-based Rails applications.
The conversation delves into fascinating territory around GitHub's technical architecture decisions. Joel articulates the clear dividing line between interfaces better suited for React versus Rails, based on his experience building complex UIs like GitHub's merge box. "The ability for a new engineer to come in and modify that code in React is an order of magnitude better," he explains, revealing how pragmatism rather than dogma drives technology choices at scale.
Perhaps most compelling are Joel's reflections on accessibility – work he led for years at GitHub. He reveals how accessibility requirements fundamentally reshape engineering approaches, forcing consistency and systematic thinking that might otherwise be overlooked. With 80% of top e-commerce sites facing accessibility lawsuits in recent years, these considerations are becoming unavoidable for developers at companies of all sizes.
As a new member of GitHub's Ruby architecture team, Joel also shares fascinating perspectives on Ruby's evolution. He articulates the tension between adding safety guardrails to the language while preserving the flexibility and joy that attracted developers in the first place. "Is it better to take something that is elegant and beautiful and flexible and put it in handcuffs, or is it better to go use a tool that was built with that in mind?" he asks, in a moment of philosophical clarity that will resonate with Ruby developers everywhere.
Whether you're using ViewComponent, building accessible interfaces, or thinking about Ruby's future, this episode offers rare insights from someone who has spent years navigating these waters at one of the world's most prominent software platforms. Check out ViewComponent 4.0 RC1 today and share your feedback before the final release!
Honeybadger is an application health monitoring tool built by developers for developers.
Judoscale
Autoscaling that actually works. Take control of your cloud hosting.
Disclaimer: This post contains affiliate links. If you make a purchase, I may receive a commission at no extra cost to you.
Hello everyone and welcome to another episode of Code and the Coding Coders who Code it. I'm your host, drew Bragg, and I'm joined today by Joel Hawksley. Joel, I'm sure that many listeners don't need an introduction to you, but for those who do, could you please briefly introduce?
Joel Hawksley:yourself. Sure Thanks for having me on the show. My name is Joel. I'm an engineer at GitHub. I've been here for over seven years now. I've worked on a bunch of different things at the company, most notably creating the Vue component framework, of which I've remained the lead maintainer since gosh late 2018. I've also done a lot of work on accessibility, spent a couple years working on that and most recently, a couple months ago, I joined the Ruby architecture team. Really cool opportunity to work on Ruby and Rails on behalf of GitHub.
Drew Bragg:Yeah, that is awesome. The way this is going to work is I'm going to ask Joel three questions, and they're going to be awesome based on his little intro there. I'm going to ask him what he's working on, what kind of blockers he has. If he doesn't have a current blocker, he can talk about a recent blocker he had, how he got around solving it, things like that. And then the last question what is something cool, new or interesting that he's learned or discovered? It could be related to being on the new Ruby architecture team at GitHub, but it sounds like we have a lot to get into, so I don't want to yammer on for too long. Joel, what?
Joel Hawksley:are you working on? So the big news of what I'm working on is the next major release of Vue component, which will be the fourth major. The previous major was V3, which was a couple years ago Ironically similar timing in my life. I was expecting my first child when we were working on the third major, and my wife and I are now expecting a second child, which has kind of forced my hand to work on the fourth major.
Drew Bragg:Congratulations. Sounds like you'll be having your third child when we get the fifth major of View Components, so an early congratulations there, Thanks. So as of today's recording, June 30th I don't quite know when this episode is going to go out yet, but as of June 30th, Release Candidate 1's out and there's a pretty long list of various changes, bug fixes, breaking changes, etc. But the one thing that caught me a little bit, first thing that jumped out at me is sort of the phrasing of the release sort of makes it sound like you're done not with maintaining Vue components, but it's feature complete, it's a mature gem and you don't have a ton of future plans for it. Can you talk a little bit about where you are with Vue components?
Joel Hawksley:I think you described it well. It's wild to see something you created that you had an idea for on an airplane years ago go through all the stages of maturity, including long-term support. And that's where we're at, which is me and Cameron and Blake and Simon and Hans the core maintainers of the framework have kind of all reached this general agreement that the project has been feature complete. Actually, for a little while we kind of took a step back as I was starting to talk about going on paternity leave to talk about what the next steps were for the project and realized that we hadn't seen a lot of major changes. We hadn't seen a lot of proposed breaking changes, and I think that's a great sign.
Joel Hawksley:There were a ton of changes early on in the project. We had some significant changes, say, to the slots API in v3 that were not hugely fun to make, let alone migrate in the GitHub code basin and other people's code bases. But I think it's time. I think that it's good for projects to reach this kind of level of long-term support. You see it in other projects as well and I think that we are certainly there.
Drew Bragg:What's something that could change, whether it be with Vue components underlying architecture, or if it's something a change in Rails? Is there anything that you have in your head like we're feature complete, we're mature. However, if this thing happens, or this idea, or we're feature complete, we're mature. However, if this thing happens, or this idea or this concept comes around, we would need to start working on V5.
Joel Hawksley:As part of going through this V4 cycle, I was fortunate enough to have the last three months full time, with almost no meetings, to work on this project. This release isn't just about doing a major breaking change. Actually, for me, it's about putting the whole project in a long-term support mode, and that involved reviewing and resolving every single discussion issue and pull request on the project, which was a massive amount of work. Apologies to everyone out there that I neglected. Apparently, discussions weren't notifying me, so I didn't see a lot of them. Anyways, they weren't on my radar, especially when I wasn't able to focus on the project as much.
Drew Bragg:If only there was someone you knew who worked at.
Joel Hawksley:GitHub that could fix that.
Joel Hawksley:Well, and what I think it is is that I think that when we first introduced discussions, the notification setup maybe was more opt-in, and I think that we changed it, maybe a couple of years ago, to be opt-out, so there were a lot of older discussions that I hadn't participated in. I also know that I was at reduced capacity for other reasons for a couple of years. Anyways, in going through that process, it was pretty clear to me that there were a couple of key themes that have yet to be addressed by the framework, and the biggest one is CSS and JavaScript architecture, and in fact, we had documentation on the framework website for different ways of doing CSS and JavaScript, and as part of the v4 release, we're removing all of it because no one could agree on it. It went out of date super fast, so it just wasn't really serving to have this part of our documentation.
Joel Hawksley:But I think that speaks to an opportunity in the future, as you asked about, because, as I'm sure you've seen in your career, there has been so little consensus on how things are done in that space and people come asking to the project like, oh, how should I do my CSS, how should I do my JavaScript? We don't even have one answer. In the GitHub code base. We're making great progress on it, getting towards something that we feel is like more durable in the long term sense, but even then I don't think our approach is applicable to a small Rails app, and that's kind of a philosophical corner you end up painting yourself into when you are building something that is so Rails adjacent, like ViewComponent. That's just meant to be like a plugin that you pull in and just feels like another layer you put on top of Rails. It just should have been there all along. It's really hard to have an opinion about something that is changing so much when you are in that spot.
Drew Bragg:Rails itself essentially went through that like it was Webpacker. This is how we're going to do JavaScript and CSS going forward. This is the way. And then it was like, okay, actually the people in the JavaScript space just change this shit every other month. We can't keep up and we don't want to keep up, so instead we're just going to kind of let you do your own thing and give you the access to you, do whatever you need to do, whatever works best for you and your team, and we'll just adapt for that.
Joel Hawksley:so I think rails went through that a little bit, so it makes sense that view components would kind of take the same approach right, and I think that what is especially difficult is that view component is as much a mental model as it is a framework, which is to say that we're trying to help you think like you would think as a React developer, and I think that what people crave in the CSS and JavaScript side of things is the ability to think like they are in React when they are not and from like a rendering markup standpoint.
Joel Hawksley:That was not hugely difficult to pull off, like there's a lot of gotchas inside the framework that we navigate around, but it's a whole different ball game to say, try and implement things like style encapsulation and dead code elimination those kinds of things that people really crave coming from the React world. It's just a whole different set of disciplines that I don't think that, quite frankly, we're totally, even technically, equipped to solve in the current stack we have. I think that's actually why you see GitHub ultimately writing a lot more React code is that we have the need for those things, and even having web component experts at GitHub hasn't been enough to get us over the hump of scaling out a non-React stack that solves those problems personally, I hope that that's a yet thing.
Drew Bragg:Totally haven't gotten the web components yet. But yeah, react, ate the web for a while there. It's nice to see that we have options outside of react, but I understand, especially at github scale, potentially not being able to just be like yeah, we're done with React.
Joel Hawksley:One example of that is styled components. So we use styled components for years. We've recently I wouldn't say we've eliminated it, but we've moved away from it in our design system and are working to move away from it almost entirely in all of our applications, and that's a technology that I don't want to say it was strictly necessary, but certainly it made a lot of things easier that were not as possible in the platform. We are now using CSS modules which are closer to the platform, and that's an example of the more status quo improving and allowing us to move away from bespoke React or what I would call like SPA framework specific solutions, and in fact, that's allowed us to do a lot more style reuse across both our React and non-React interfaces.
Drew Bragg:In my last episode I had Vova from Evil Martians on and he was talking a lot about putting Rails in the browser and I think a lot of what he was envisioning its use for was tutorials instead of hey, go to your computer outside of the browser and go try this, just an interactive thing there. But do you and your team have any kind of well? Maybe when Rails in the browser or Ruby Wasm improves to X point, then there's more. That opens up for what view components can do, because we're limited by we're completely server side now we don't have enough access to the client, or is it kind of like that is so far out in the future that it's not even on the radar yet?
Joel Hawksley:I think that to a certain extent and maybe this actually speaks to how I think about the framework in general at this point we've kind of drawn a line in the sand when it comes to the complexity we are willing to implement outside of react and we put a ceiling in that. I think that is very realistic because what we were finding is that as you get into incredibly complex, dynamic uis with a lot of just for example, like our merge box, the bottom of a pull request when it shows all your check statuses, what your permissions are, what the state of the branch is, what your merge target is incredible amount of complexity, state, dynamic loading all this asynchronous stuff. That was really really hard to maintain in a non-react architecture, despite the work of many very smart people over many years doing what they could. It took a ground-up rewrite. Now, to be fair, a ground-up rewrite in the full rail stack might have also gone pretty well, but the ability for a new engineer to come in and modify that code in react is an order of magnitude better. So what I'm starting to get a feel for is even with changes to the platform, I still have a gut feeling that there's a certain level of complexity that is going to be a long time before. Certainly, practically, we can build it without something like React. And what we're finding is, conversely, what is expected in the industry is increasingly falling on the other side of that line. Falling on the other side of that line as we make GitHub more modern and more app-like, the experiences we want to build are disproportionately falling in that land where React becomes a clearer and clearer, optimal architecture for what we're trying to deliver to our customers. So I struggle to think about what it would take to get that far.
Joel Hawksley:Now I see applications that are powered by Hotwire. Hay is one example, really great application and I really appreciate the velocity that developers get, especially on small teams. I mean, that's what Rails is built for. But what we're finding is that, especially over the long term, is you have to maintain those things, make them accessible, avoid visual regressions. We have state machines that test that merge box and visually regress it and all this cool stuff, and that's very hard to do. We've tried to do some of that with view component, with lookbook, but I mean it really comes down ultimately to functional purity. Like a React component is a function of the state you give it, versus when you're working in a lot of these Rails paradigms whether it's exclusively your Ruby code that can have access to any of the global state on the server, versus React code has none of that on the client. Or, if you think about it, similar concept with styles. If you are working in the traditional big blob of CSS setup, you can have as good a discipline as you want, but you're still going to ultimately especially at our scale run into these really gnarly kind of just isolation kind of problems.
Joel Hawksley:I don't see the story of that meaningfully changing anytime soon. I know we have things like scoped styles with web components and whatnot coming up, but those things would still have to become popular for us to then have people who are willing to work on them. Because the other inertia we see with all this is that there's just so much energy going into making the React developer experience great. It is mind-boggling to see how productive people are, and this is getting amplified by AI because TypeScript is strongly typed. So I have a hunch that these LLMs are really able to provide higher quality experiences to developers writing React code in TypeScript. There's also just like a much larger corpus of TypeScript to look at Now, whether it's a good training set or not, we can debate, but I see all these factors kind of sociotechnical, like a sociotechnical landscape that makes it really hard for me to imagine a place where the web platform is delivering for what GitHub is building today, even like three years from now.
Drew Bragg:Doesn't mean it doesn't, but it's hard to say. I mean, there was a period of time where I'm sure even the idea of web components as we have it now was kind of like oh, I don't see that being a thing for years and years. And now here we are and it's like web components still have a ways to go, but they are so much more powerful and so much more useful, I guess, Practical, practical.
Joel Hawksley:That I guess practical practical, that's the word I'm looking for. They're so much more practical now than they were a few years ago. So, and what we're going to find is, I think, that these platform changes, they raise the bar of how long you can use the platform, and that's kind of what I'm getting at. Is that like okay, will we eventually raise the bar to the point where, like all of github falls below that bar and then we get into like hybrid application problems where it's like okay, do we really want to have two stories for front end of the company when we have hundreds, if not a thousand, engineers working on our product? Do we really want to have to teach them two very different ways? Because the other tricky part about this is that, like it'd be one thing if it was these technologies layered on each other, but they're so philosophically different and this is like another core thing with the viewue component framework that's been so tricky is that we are both trying to take the best parts of React and bring them back to Rails, while also not breaking mental models in a way that's confusing. We don't want to try and do things that fundamentally don't map to Ruby.
Joel Hawksley:What I found is that we went through this thread for a while where we were trying to keep a common core including potentially with web components in between our react and view component implementations of our design system and what ended up happening is that you just had the worst of both worlds because you have the common denominator. It's like if you only had to cook with ingredients from two different cuisines, the overlap of two different cuisines, but you still had to cook in both cuisines, but only with that intersection of the Venn diagram, you'd make really bad food of both cuisines and someone would come and like look at cuisine A or cuisine B and be like, oh, this is an insult to like the spirit of this food. So I think that's what you see it's like. Okay, if we're going to use React, let's use it to its fullest potential. And I think that as soon as you start looking at these compatibility layers, you have to be really careful of what you're taking off the table.
Joel Hawksley:And that goes also from the Rails direction back to React. We were even looking at how do we architect components, say, we had like a complex view component. Well, we tried to like architect it the same way in React and then we had some compromises there, and the problem is that those differences started to affect even how we did styling in JavaScript, and that got really messy. Then it's like okay, as soon as they diverge enough, you then have to audit them for accessibility in a completely separate manner, because you can't guarantee that they're having even the same APIs, whether under the hood or in the way a user interacts with them.
Drew Bragg:Yeah, there's quite a bit that goes in there and I'm sure, at GitHub scale it's like to a degree that I can't even fathom. Like I've pretty much predominantly worked on small or smaller teams like GitHub scale. It's kind of like seeing the Grand Canyon for the first time. You're like I knew what it looked like, but it didn't quite click until I saw it in person.
Joel Hawksley:I think there's an interesting phenomenon, though, because I think that there's a certain amount that's trickling down, and maybe not in a good way, because some of the reasons we make these decisions don't depend on the scale of the application. Accessibility is the thing I've worked on for years at the company and did a lot of very interesting work, worked with a lot of great people, very passionate people. It is amazing to me the implications of that work on the technical side of things. It's a very real and pressing constraint that required us to do a lot of things that, quite frankly, were hard to justify before. Accessibility in terms of around like, say, consistency, like how many times as a programmer have you be like, oh, I wish these 100 buttons in our application were all like the exact same code, path, the exact same thing. Well, with the accessibility requirements, you kind of don't have a choice, because you got to guarantee that your whole application can be used and is consistent and whatnot. So it forces those factors.
Joel Hawksley:What I'm seeing in my non-lawyer professional opinion is that that pressure is going to come to more and more companies than is the case right now, and I think that we all see is that the way that we solve problems at a GitHub becomes more along the lines of what needs to be done at smaller companies because of that pressure. So, for example, in the last five years, 80% of the top 500 e-commerce websites in the world have been sued for an accessibility violation. They've faced actual legal action. That's a lot of lawsuits. So I know y'all are at Podia, are in e-commerce.
Joel Hawksley:I think this was more like shopping A little bit different, but sure Digital e-commerce, and I think that what we're going to find is that you're going to be pressured to do more accessibility work, as I think is a good thing for the world. If you have to say let's just think about this conceptually. As a software engineer, if you're going to need to, through your architecture, guarantee that certain key failure states do not exist, that requires something like a design system with constrained options. I'll just give you a classic example. It's like okay, how do you guarantee that all of your images have alt text as long as they aren't decorative in your application? If you were to have like a static guarantee, you'd probably lend maybe some sort of tests that would render every view.
Drew Bragg:Yeah, something along those lines would be like the first thing that comes to mind. But I'm cheating a little here, cause I've seen your accessibility talk a few times and there are tools that help with this.
Joel Hawksley:Right.
Joel Hawksley:But that requires you to be able to, in a test, render every single view state which a more functionally oriented paradigm like React, which is literally state machines for UI, is set up to help you solve, because you can enumerate the state permutations of your application.
Joel Hawksley:You look at our design system and we do this on the real side too to a certain extent. We have what are called sticker sheets, which is literally a matrix of two options on a component. So you might have size on the Y-axis and color on the X-axis, and that shows you the permutation of all those combinations for that component. And you can do this across a bunch of different options for a bunch of different components and you can start to see the actual surface area of all the potential states your design system can be in. Now imagine if you don't have a design system. You would have to do that for literally every path through every user interface, every menu, to make sure, say, for example, that when you focus on any single thing with your keyboard it has sufficient focus outline. That's a key, key thing we've been doing in our product, and getting to that level of confidence is very hard without a lot of browser-based system tests in the Rails side of things Okay.
Drew Bragg:Yeah, that makes sense. You brought it up in your intro. You just brought it up a few times, so it feels like a good time to ask about the accessibility work that you've done at GitHub. Is the accessibility work that you've done at GitHub an ongoing thing still, or is your move to the Ruby architecture team kind of maybe moving it into someone else's playground a little bit?
Joel Hawksley:Right. Like any huge initiative, it has different phases and different milestones, and part of the reason I moved elsewhere in the company is that we had reached a point of operational maturity not maturity in the outcomes, but we had the tools and processes to execute well. I can't share any specific metrics or anything like that, but I can say that the program continues to meet significant further milestones after I left my time on the team, and it's really impressive to see that GitHub is continuing to invest in those things. It does become an evergreen thing because new UI is being built, so like, for example, we started the project before Copilot was a thing, so now there's a whole new world of AI accessibility, and I haven't really been a part of that but making sure that, as we're building especially new experiences that are unfamiliar and novel, that people who are using assistive technology can still get the same value out of them interesting.
Drew Bragg:I hadn't even thought about co-pilot as something that would need the accessibility. That is very interesting that you'd have this accessibility initiative and then a new product like Copilot gets added and like a whole new world opens up for that initiative that you probably couldn't have even foreseen when the initiative first started. Exactly.
Joel Hawksley:Anytime there's a novel UI, like the example I like to give people, is that part of the reason we use design systems is to make it so that our resources are available for when something comes up. That isn't typical. If we were having to have our accessibility designers and engineers work on every new page, even if that page wasn't that different from another one, we wouldn't have the resources to, say, go work on a new novel AI thing, because what we found is that for these new novel UIs, you have to think about accessibility from day one, because otherwise you're going to go in a direction that you might not be able to retrofit a good assistive technology experience on top of it.
Drew Bragg:Interesting. Hadn't thought about that. So tell me a little bit about the work that you said. You've been on for a few months, so I don't know if it's work that you've done or if it's work that you're going to do with being on the Ruby architecture team at GitHub.
Joel Hawksley:Sure. So the team has a couple responsibilities. One of them is keeping Ruby and Rails at GitHub up to date to head to head, so we literally have a dashboard that says the number of commits we are behind Ruby and Rails head in production. And that is a key thing, because we're such a big code base that we effectively serve as a extension or an annex of the Ruby and Rails test suites. And I think that that's actually something that everyone can do at their companies is they can run and you can pin the commit. Obviously, you don't have to take every new commit as it lands, although I do that in some places. It's a wild ride.
Joel Hawksley:But yeah, we serve as a feedback mechanism because you could imagine the kind of pickle you could end up in as a big code base if something lands upstream that is going to be very expensive or difficult to accommodate in your code base. You want to know about it right away because your ability to influence a potential change upstream is significantly different as time goes on. If we were waiting for an actual gem push from rails and the thing we want is a breaking change, that gets weird, but we could get in and make that change before it gets out to rubGems and that allows us to have that kind of impact. So it's basically the team of people that are Ruby and Rails experts at the company and we kind of follow that pattern. We also do things that are investments in the language. So, for example, we look at performance related things. We're working on ZJIT with our friends at Shopify, but also on the Rails side there's this kind of broader evergreen initiative as well to make our Rails app boring, because it's not in our interest to maintain custom logic on top of things that are of Rails concern.
Joel Hawksley:So this is a story that's been told publicly for many years. Eileen Bouchetel has told it well around. There are just so many things, for example, didn't exist in the community when they were first built. At GitHub, we did some things around background jobs, for example. We've done some things around databases that were not in Rails, but we're not in the business of those things. So we need to be best as possible moving them upstream, and it's good for all the other usual good open source reasons too, like it's great for us to be able to share our experience of things that can run it. They can serve 10 billion requests a day or whatever we serve, if it can work for us, it should work for everyone.
Drew Bragg:If it's a technical thing, that is super cool and so you brought up your friends at Shopify. How much overlap is there or how much coordination and cooperation between the teams? I'm sure there's a lot of overlap and we want to work on X, they want to work on X. Is there a lot of communication between you guys saying we're going to work on MySQL sequel? You guys can take postgres. When it came to like I don't know, I was using those as an example, potentially a bad one. I think you get the point.
Joel Hawksley:Yeah, there's some projects we collaborate on and we do it across a different bunch of different venues. I'm still getting a feel for it. But, for example, we have, like the trilogy database adapter that's now open source, so like that's not strictly done privately. But I know that the thing is I lose track of which Slack channels are where, but there are some Slack channels that I have that are just with Shopify people that are between GitHub and Shopify and this is common, I know just generally in the big rails community is that we're all on Slack. So there's some Slack connect things that go on. Have you ever used Slack connect? Yeah, a little bit, it's where you have an outside.
Joel Hawksley:Yeah, but it's where you can like link workspaces. You can say, okay, this channel exists both in. Maybe Gusto and Shopify might have one. It's just like Gusto, shopify and it's like a little pair we hear a lot about the work that Shopify does.
Drew Bragg:They're very vocal about it. I feel like maybe to a degree, github's a little less vocal about the work they do, but certainly you guys, being as big of a Rails app as you are, there's a lot of work that goes on and I know that when I've met folks at GitHub they talk about some of the work that they do. It's just not as public facing, I feel like. Is that something that's intentional or is it just kind of like not what we do? I know ufuk is one of the head managers on the ruby and rails infrastructure team at shopify and he's fairly vocal. I didn't know if that was just an artifact of him being there or if github just takes the stance of like, yeah, we're less public about the work that we do, or it could just be me not seeing it, not having the right people in my timeline.
Joel Hawksley:I think that what you're seeing with Shopify's investment in the Ruby and Rails community is extraordinary and is something to be recognized, and I think that I'm impressed at the amount of resources they're able to dedicate it to.
Joel Hawksley:It's really incredible. My understanding is that they're a much bigger company than us and I can tell you some of my mental model things, because I can't really speak too much to the company priorities because I don't think there's anything that's like hugely intentional either way in what you're observing. But one of the ways I think about it is that our products are somewhat different in their traffic patterns. I would guess that Shopify sees an even greater pressure for, say, per core request efficiency than we do, because they're serving e-commerce traffic on Black Friday. Our traffic is a much simpler, very predictable level and it's mostly logged in and there's a whole dynamic to that. Versus like, I think that you just might see just a lot of different engineering dynamics going on. I would still say that we push Ruby and Rails to the limit in our own way, but it's just different yeah, it was just something I had noticed.
Drew Bragg:I didn't know if there was something you knew insider knowledge that you might have. So this is a loaded question because you've got so many things. You've got view components and the accessibility work of the past and the Ruby architecture stuff coming up and a kid, which I don't want to call your child a blocker, but certainly could fall into like what kind of blockers do you have as far as like hey, I'm getting ready for paternity leave and that requires me to do the V4 release leave and that requires me to do the v4 release. What are the kinds of blockers that you're dealing with, or what's one recently that you want?
Joel Hawksley:to kind of get into. I think that talk about the major release is a really interesting one, because what I found fascinating is that it's put me in like a semper mindset. It's made me really internalize the true philosophical implications of following Semver, which is that your practices as a software engineer feed into that dynamic. And what I mean by that is that one of the things I've really noticed working on the project for so long is that Semver and Agile, to a certain extent those mindsets encourage certain types of outcomes. So, for example, I don't know about you, but I fear major releases. They are both a great thing and a terrible thing, like there's a lot of pressure to get them right. If you truly follow Semver, which we try on Vue Component, it's your chance to do something breaking, to give people work. And what it's made me realize, as I've had time to reflect on these kinds of changes that are possible, is how our day-to-day leads to what I call like Semver pressure or like angst. And one example of that is that, well, agile and Semver encourage you not to break things and Agile encourages you to just go to the next logical step. Well, after seven years of doing that, wouldn't you hope that you learned how to do something better. The next time around you end up in a bit of a hole, and some of these holes you obviously can't dig yourself out of, like we have thousands of components of GitHub we're not going to make any hugely massive changes, but like even something simple like configuration options. Try not to have a ton of them.
Joel Hawksley:We got rid of some of them in V4, but even we had started adding configuration options, and it only in this release, when I took a step back to look at all of them did I realize which ones were misleading, unnecessary or just poorly named or organized. So we basically ended up with like two categories of configuration. One is for generators, which I've never used a Rails generator in my life, which I respect that people do, but I've never used one. I like to write it myself and then the second was for previews. I think we ended up with like eight or nine configuration options. Only one of them was top level. The other ones were not production related. But if you were reading the list that had come out of our like agile, iterative way, you would have no clue of knowing whether those configuration options were of consequence or not. Those configuration options were of consequence or not.
Joel Hawksley:So Semver creates a fear of what I would call fully refactoring something to be correct, and I think this is a big difference between library and framework development and application development. Imagine if you Semvered GitHub's internal code Every single release would be breaking right. So it's a huge mindset shift to go from that to like I'm going to make a breaking release once every two years. In part it's because you're breaking other people's apps. I view it as an immense responsibility to not do something undue, but it makes you realize how much we like lean on our ability to change things and are breaking away as an application developer when you can't do it that makes sense.
Drew Bragg:I've run into a handful of gem updates where it's oh, it's a minor version, this should be safe, and it breaks something. And I'm just like you words I don't want to say because I don't want to put the explicit content warning on my show. This is not a major change. You should not have broken anything Meanwhile, like in my app development stuff. I'm just like ah, whatever, we'll just change it everywhere. It's fine, we'll do a maintenance window.
Drew Bragg:Yeah, Like no one no one needs to worry about this. If it's not our API, it's fine.
Joel Hawksley:What it's really opened my eyes to is like how do you guarantee it? I think that, as we're seeing more LLM generated code, where does your confidence come from on this? Like I have run into the trap of your writing little scripts and whatnot that had bugs in them, but because I didn't write it, I think I was way less likely to see it, and I've started to envy the folks in the statically typed side of things, the compiled side of things, a little bit more. Started to envy the folks who write Elm a little bit more. I believe they guarantee no runtime errors.
Drew Bragg:Joel Quinville loves Elm. I've heard him talk a lot about it. I have not played with but I'm familiar with, just because of listening to the bike shed.
Joel Hawksley:Right. Those are the kinds of things that in this moment of reflection of taking on a major release, that I start to wonder about. And we're starting to see this kind of generally with even writing Ruby at GitHub. I think that a lot of the code we write goes a long time without being changed, so we don't learn the lessons of changing code. And I think this is especially true in the Rails field, because Rails is the one person framework. Lots of prototyping happens in Rails and whatnot.
Joel Hawksley:I think that as you get into that realm of having to go back and make big changes like we have safer accessibility or just like sweeping product changes, you start to see where your confidence comes from. As a software engineer and especially writing like a framework in Ruby, it's wild to be like oh my gosh, I'm changing this thing and I know we have a very thorough test suite. We've had 100% code coverage from day one, even branch coverage. But I still am worried. We've made some fairly significant changes under the hood in this release. We haven't really had to change any test cases. It's not like they've been breaking changes in the tests. It still makes you wonder Because we don't have those guarantees in our world, in our Ruby ecosystem in our world, in our ruby ecosystem.
Drew Bragg:I mean, even if you do have those quote-unquote guarantees and like typescript or whatever, it being statically typed so you still got any, that's a type that I'm sure that gets abused like. I don't mean to say like, oh, ruby's better than typescript or the same. Because of that. It just comes down to a little bit of craftsmanship but you can say no, any right.
Joel Hawksley:We use linters to a certain extent to file down the sharp edges and ruby and rails. I would guess if you look even at rubicop, you'll see some signs of that sprinkled throughout, even just like rubicop performance. Like there are things that like they might not explicitly be dangerous but they might be, and we lint against those.
Drew Bragg:AST of Ruby code like it's unlocking some really awesome things, that it's going to make the whole experience of writing Ruby that much better and hopefully get some of that danger, you're doing something potentially bad.
Joel Hawksley:What I wonder, though, is if to kind of go back to something I said earlier about, like the common denominator of ingredients between two different cuisines I do wonder whether we are, at the same time as we make Ruby quote unquote better, in those ways, making it worse for what it actually should be, because, on the flip side, we've done a lot of that work at GitHub, and I would say that I generally feel mixed about it. I see why we have to do it, but it certainly makes it feel less like the language I fell in love with. I see why we have to do it, but it certainly makes it feel less like the language I fell in love with, and that is a reality of the scale, but I can see how there is some hesitation in the Ruby community to add a lot of these things that ostensibly make it safer and more predictable, because I've seen some Ruby code that is very safe and predictable that makes you want to learn Go, because I'm like well, if we're going to go this direction, is it better to take something that is elegant and beautiful and flexible and put it in handcuffs, or is it better to go use a tool that was built with that in mind? And this is a kind of an existential debate I think that I'm having with colleagues around the company how far do we want to push the language and the framework to do things that take it further away from what it might generally be good at, or what it should be good at in a very like philosophical sense, because these things are all technically possible.
Joel Hawksley:Like we're engineers, we can build just about anything. We could slowly over many years turn Ruby literally into Go. You could just one breaking change at a, one christmas release at a time. We could converge into go. It would take time, could we not?
Joel Hawksley:that'd be great but yeah, I see what you're saying. Yeah, we're on that path. So it's like how far do you want to take it?
Drew Bragg:I think, for me at least, the thing I like is that most of these guardrails, most of these improvements that make it a little bit safer, a little bit nicer to work in, they're like add-ons. The Ruby LSP is not Ruby right, it is a completely separate tool. The Prism parser is in Ruby but it doesn't actually do anything. It just gives you the ability to do more safety-esque things with Ruby. It improves how RuboCop can work. It improves how the LSP looks at and can find errors in our code and whatnot. But if you want the pure joy of writing Ruby like you had before any of these things, you just turn them off and then you're back to just.
Drew Bragg:I can write my 10,000 line Ruby script of chaos because I can and I want to, and it's a personal project and no one else will ever see it and I like that. I like the fact that I can still do my weird Ruby stuff. But when I'm working at work and I need some more safety and I'm dealing with thousands of files and stuff I've never touched or hasn't been touched in years and the person who wrote it left five years ago. As it is Now, we have tools that help us. It's not the same as a statically typed language per se would be where we can like click on something and find every iteration of it. But even some of the new stuff in the LSP where it can guess receivers and, as long as your naming conventions are good, like it does a really good job. The guest receivers.
Joel Hawksley:It's quite good, and I think you're having me see it more as like separate dialects of the same language, where it's like you have this safe Ruby dialect or sorbade Ruby dialect is like I sometimes see it and those things can coexist. I think that what I see happening kind of maybe even beyond the language, is that people then start to compare it, to be like okay, we're doing this in Ruby, is this the Ruby? Is this still the language we want? In this situation, I feel ultimately torn about it. I think that it is kind of interesting because it probably extends the runway pretty significantly for the language and I think that it's very pragmatic. I think that, while we do see a lot of benefits, we occasionally will take a service at work and rewrite it and go, because it's just way better suited for the language.
Drew Bragg:To that point, though, I would argue that getting it built in Ruby first was the right call, because you're just going to move faster.
Joel Hawksley:And even if you rewrote it, it'd probably see a lot of the performance benefits too. What I try to avoid in these kinds of debates is making them technical, because these things are not technical decisions. There's people and systems involved, and we found that certain types of services and languages and whatnot are easier to deploy in our infrastructure and whatnot it's easier to hire for, and I think that that's where just seeing the different forms ruby can take is pretty wild, because it can kind of shape shift now into these different modes yeah, it is very cool.
Drew Bragg:It's exciting. You are going to lose a little bit of what made ruby so wonderful, like just the ability to do whatever no, guard rail, sharp knives kind of thing. But it's a maturity thing, right. When we were teenagers we also did a lot of dumb stuff that like, yeah, we miss it, but also like it hurts now to do some of those things in the next morning, so maybe we don't do those. We've matured. We could talk about this for a whole nother episode.
Joel Hawksley:I think it's funny you say that because the GitHub monolith is what?
Joel Hawksley:17, 18 years old or whatever at this point, so you're like your analogy tracks well that to a certain extent, these things.
Joel Hawksley:I mean it's a real testament that the github monolith has remained ruby on rails for as long as it has.
Joel Hawksley:It's taken countless hours of work by so many smart people to do that, but we're still here and it's going to be around for a long time, and I think that that's where you really learn the implications of your decisions as an engineer is when your stuff sticks around, and I think that that's kind of the thing that I feel super privileged about, ultimately in my position, is that, like I have gotten to see ViewComponent exist for six years, I've learned so much about the consequences of my decisions versus if I had job hopped every two years, I would have never seen even the two-year consequences, let alone the four or the six-year ones. To a certain extent, if I stick around long enough, I might be the person who removes it as a dependency from GitHub. I don't know, I don't think that'll ever happen, but it's the kind of thing where I think the longer you are around, the better lessons you learn as an engineer and it helps you make way better decisions day to day.
Drew Bragg:Yeah, I can agree with that because, again, we could talk about all of this stuff forever. We're going to use my guardrails and we're going to move to the next question, which I'm sure will also yield lots of discussion. But what is something cool, new or interesting that you've recently learned, discovered, read whatever. It doesn't have to be coding related. I've had people talk about endangered hobbies and cloud whitening, and book series I'm currently addicted to was one of them, which I don't know how I feel about it yet because I've spent so much time reading the series, but it can be. We've also had people talk about Ruby Wasm and things that are coming out in Ruby or that they're building with Ruby that are super exciting, or that they just found so for you and all the various things that you're involved with. What is something cool, new or interesting that you want?
Joel Hawksley:to share. As part of my onboarding under the Ruby architecture team, one of the key things I was told was to go read Ruby under a microscope, with the disclaimer that Ruby under a microscope is out of date. It's still a great read, though. It's 1.8, 1.9. I'm only maybe 10% of the way through, but I think that if you've been in Ruby, I feel like you should be automatically mailed that book when you enter like the fourth year of working in Ruby, because you just should know like I'm reading this stuff and I'm like I've seen these terms. It helps me understand at a fundamental level what some of the error messages I've gotten really meant over the years and I I mostly understood. Now I can deeply understand how Ruby actually takes a text file and turns it into tokens and then takes those tokens and turns it into machine code and like the kind of like fundamental process that if you watched every single Aaron Patterson keynote you'd probably get the same education.
Joel Hawksley:He did write the foreword for the book, so it makes sense. But yeah, that definitely would be my recommendation. It's a really solid read. I can only handle so much recommendation. It's a really solid read. I can only handle so much. I read like three pages right before bed and it's like, okay, well, I'm definitely going to sleep well tonight.
Drew Bragg:It's a very technical, technical book and I feel like I agree the same way with my technical reading. I can read like a chapter of a technical book and then I'm like that's enough for now With my readings. For fun I can read like, oh, it's been three hours, I'm still not done reading yet. But yeah, with technical it's just like I only have so much capacity. But yes, ruby under a microscope is a great recommendation, good call.
Joel Hawksley:It makes me wonder if there's a Rails under a microscope. Having worked on view component, I could probably write the one on ActionView under a microscope, written in black. Oh my gosh, the lessons I've learned about ActionView. But I think that writing one for all of Rails would be deeply fascinating. I think there's a couple of people on the current or former core team members I think could write a really interesting read there. I would read that book too.
Drew Bragg:It is interesting, especially like there was a point in my career where I noticed myself going into the Rails source code to debug something in my own application. And just starting to go down those layers was such an interesting journey and seeing what was actually happening for the stuff that I had just been using, I didn't actually know what was going on. Once I started, getting into the source code completely changed a lot of what I thought about with rails and like the mental models I had. So reading a book like that, where it's a little more structured and organized, instead of just me spelunking, would be awesome.
Joel Hawksley:Totally yeah, cause these lessons are hard to learn when you're debugging, when you're bundle opening, when you put your first binding dot pry in a gem, yeah, yeah we don't use pry at podia anymore, we're using just binding irb, as I do too.
Drew Bragg:Yeah, but copilot does not fucking understand that. Well, I guess I'm putting the explicit content on now. Oh well, copilot does not understand this. And if I type binding and it is like, oh, you mean dot pry and I'm like no, stop it. How many times do I have to type, how many times do I have to type bindingirb before it will learn? I want bindingirb time, do you know? Because you work at the place.
Joel Hawksley:Time to put it in a system prompt or something like that.
Drew Bragg:Yeah, I hear you. All the AI stuff is fascinating the way that it looks at code and analyzes code, the way that it writes code. I don't think I've gotten to the same level of trust as a lot of people have with it, but it is really interesting yeah.
Joel Hawksley:I would say I'm in a similar spot. I've been spending more time doing it as I start to wind down ahead of paternity leave. I'm having a little more time to play around with it. I think it's really cool. I think, especially if you're building an application, I see it really good for kind of building something that's already been built or writing scripts. It's a great one. Like I had a script to write the other day and I just prompted it. I was not looking forward to writing that script and it got it. It did it.
Drew Bragg:The landscape's changing. I don't think our jobs are as in jeopardy as some of the AI folks would have us feel like our jobs are in jeopardy, but yeah, the landscape is changing for sure. Yeah, agreed, cool. So I want to respect your time. Is there anything else that you want to talk about with the release? Coming up With anything that we've touched on, anything else that we didn't go deep enough into?
Drew Bragg:I'll be on here with you for three and more hours if you want to do, but you are a busy man, so you tell me Any and all feedback on the Vue component release would be super helpful.
Joel Hawksley:We've been doing alpha releases for a while that I know some people have been integrating, but getting it integrated as soon as possible, even just on a branch, to run against your CI. Like I said earlier, the way we treat Rails upstream. The sooner you report a bug, the more likely it is to be able to get the best fix in. So if you wait, I might be on paternity leave when you run into that bug and there are there's other people who are going to be working on the project. I'm not worried, but this is a great time to be involved and test out the release and let us know how it goes.
Drew Bragg:And so where can people find you and whatever projects you want them to find on the internet?
Joel Hawksley:My website is hoxleyorg. I don't do any social media or anything, and viewcomponentsorg.
Drew Bragg:I don't do any social media or anything, and. Viewcomponentsorg. Viewcomponentsorg. Yep, version 4 RC1 is out. What is the goal timeline?
Joel Hawksley:So today's the 30th Monday. We'll probably have RC2 later this week. I would guess there's a thing or two we want to toss in. I'm taking a week off to go on vacation and if I come back to no open issues, I will ship V4, which I think would be the Monday. It'd be two weeks from today, so 14th, something like that.
Drew Bragg:Right after the old RailsConf in Philadelphia. Very cool. Speaking of conferences, will you be at Rocky Mountain Ruby later in October?
Joel Hawksley:I will be Love that we now have a great conference in town. It's like I could almost bike there from my house.
Drew Bragg:Boulder is such a cool city to have a conference in so walkable, so much cool stuff going on around it. Spike and team have a great venue and awesome conference Looking forward to it. Cool man, thank you so much for coming on talking a little bit about Vue components and all the work that you're doing at GitHub. It is well overdue having you on the show, so I really appreciate you coming on. Thanks for having me and listeners. I'll see you in the next one. Bye.
