July 2, 2025 • 54 mins
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.
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Drew Bragg (00:01):
Hello everyone and welcome to another episode of
Code and the Coding Coders whoCode it.
I'm your host, drew Bragg, andI'm joined today by Joel
Hawksley.
Joel, I'm sure that manylisteners don't need an
introduction to you, but forthose who do, could you please
briefly introduce?
Joel Hawksley (00:14):
yourself.
Sure Thanks for having me onthe show.
My name is Joel.
I'm an engineer at GitHub.
I've been here for over sevenyears now.
I've worked on a bunch ofdifferent things at the company,
most notably creating the Vuecomponent framework, of which
I've remained the leadmaintainer since gosh late 2018.
I've also done a lot of work onaccessibility, spent a couple
years working on that and mostrecently, a couple months ago, I
(00:36):
joined the Ruby architectureteam.
Really cool opportunity to workon Ruby and Rails on behalf of
GitHub.
Drew Bragg (00:44):
Yeah, that is awesome.
The way this is going to workis I'm going to ask Joel three
questions, and they're going tobe awesome based on his little
intro there.
I'm going to ask him what he'sworking on, what kind of
blockers he has.
If he doesn't have a currentblocker, he can talk about a
recent blocker he had, how hegot around solving it, things
like that.
And then the last question whatis something cool, new or
(01:11):
interesting that he's learned ordiscovered?
It could be related to being onthe new Ruby architecture team
at GitHub, but it sounds like wehave a lot to get into, so I
don't want to yammer on for toolong.
Joel, what?
Joel Hawksley (01:17):
are you working on?
So the big news of what I'mworking on is the next major
release of Vue component, whichwill be the fourth major.
The previous major was V3,which was a couple years ago
Ironically similar timing in mylife.
I was expecting my first childwhen we were working on the
(01:37):
third major, and my wife and Iare now expecting a second child
, which has kind of forced myhand to work on the fourth major
.
Drew Bragg (01:45):
Congratulations.
Sounds like you'll be havingyour 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 goout yet, but as of June 30th,
Release Candidate 1's out andthere's a pretty long list of
(02:06):
various changes, bug fixes,breaking changes, etc.
But the one thing that caughtme a little bit, first thing
that jumped out at me is sort ofthe phrasing of the release
sort of makes it sound likeyou're done not with maintaining
Vue components, but it'sfeature complete, it's a mature
gem and you don't have a ton offuture plans for it.
(02:29):
Can you talk a little bit aboutwhere you are with Vue
components?
Joel Hawksley (02:33):
I think you described it well.
It's wild to see something youcreated that you had an idea for
on an airplane years ago gothrough all the stages of
maturity, including long-termsupport.
And that's where we're at,which is me and Cameron and
Blake and Simon and Hans thecore maintainers of the
(02:57):
framework have kind of allreached this general agreement
that the project has beenfeature complete.
Actually, for a little while wekind of took a step back as I
was starting to talk about goingon paternity leave to talk
about what the next steps werefor the project and realized
that we hadn't seen a lot ofmajor changes.
We hadn't seen a lot ofproposed breaking changes, and I
(03:21):
think that's a great sign.
There were a ton of changesearly 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 otherpeople's code bases.
But I think it's time.
I think that it's good forprojects to reach this kind of
(03:43):
level of long-term support.
You see it in other projects aswell and I think that we are
certainly there.
Drew Bragg (03:49):
What's something that could change, whether it be
with Vue components underlyingarchitecture, or if it's
something a change in Rails?
Is there anything that you havein 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 tostart working on V5.
Joel Hawksley (04:12):
As part of going through this V4 cycle, I was
fortunate enough to have thelast three months full time,
with almost no meetings, to workon this project.
This release isn't just aboutdoing a major breaking change.
Actually, for me, it's aboutputting the whole project in a
long-term support mode, and thatinvolved reviewing and
(04:33):
resolving every singlediscussion issue and pull
request on the project, whichwas a massive amount of work.
Apologies to everyone out therethat I neglected.
Apparently, discussions weren'tnotifying me, so I didn't see a
lot of them.
Anyways, they weren't on myradar, especially when I wasn't
able to focus on the project asmuch.
Drew Bragg (04:49):
If only there was someone you knew who worked at.
Joel Hawksley (04:52):
GitHub that could fix that.
Well, and what I think it is isthat I think that when we first
introduced discussions, thenotification setup maybe was
more opt-in, and I think that wechanged it, maybe a couple of
years ago, to be opt-out, sothere were a lot of older
discussions that I hadn'tparticipated in.
I also know that I was atreduced capacity for other
reasons for a couple of years.
Anyways, in going through thatprocess, it was pretty clear to
(05:17):
me that there were a couple ofkey themes that have yet to be
addressed by the framework, andthe biggest one is CSS and
JavaScript architecture, and infact, we had documentation on
the framework website fordifferent ways of doing CSS and
JavaScript, and as part of thev4 release, we're removing all
(05:38):
of it because no one could agreeon it.
It went out of date super fast,so it just wasn't really
serving to have this part of ourdocumentation.
But I think that speaks to anopportunity in the future, as
you asked about, because, as I'msure you've seen in your career
, there has been so littleconsensus on how things are done
(06:01):
in that space and people comeasking to the project like, oh,
how should I do my CSS, howshould I do my JavaScript?
We don't even have one answer.
In the GitHub code base.
We're making great progress onit, getting towards something
that we feel is like moredurable in the long term sense,
but even then I don't think ourapproach is applicable to a
(06:21):
small Rails app, and that's kindof a philosophical corner you
end up painting yourself intowhen you are building something
that is so Rails adjacent, likeViewComponent.
That's just meant to be like aplugin that you pull in and just
feels like another layer youput on top of Rails.
It just should have been thereall along.
It's really hard to have anopinion about something that is
changing so much when you are inthat spot.
Drew Bragg (06:41):
Rails itself essentially went through that
like it was Webpacker.
This is how we're going to doJavaScript and CSS going forward
.
This is the way.
And then it was like, okay,actually the people in the
JavaScript space just changethis shit every other month.
We can't keep up and we don'twant to keep up, so instead
we're just going to kind of letyou do your own thing and give
(07:02):
you the access to you, dowhatever you need to do,
whatever works best for you andyour team, and we'll just adapt
for that.
Joel Hawksley (07:10):
so I think rails went through that a little bit,
so it makes sense that viewcomponents would kind of take
the same approach right, and Ithink that what is especially
difficult is that view componentis as much a mental model as it
is a framework, which is to saythat we're trying to help you
think like you would think as aReact developer, and I think
that what people crave in theCSS and JavaScript side of
(07:33):
things is the ability to thinklike they are in React when they
are not and from like arendering markup standpoint.
That was not hugely difficult topull off, like there's a lot of
gotchas inside the frameworkthat we navigate around, but
it's a whole different ball gameto say, try and implement
things like style encapsulationand dead code elimination those
(07:56):
kinds of things that peoplereally crave coming from the
React world.
It's just a whole different setof disciplines that I don't
think that, quite frankly, we'retotally, even technically,
equipped to solve in the currentstack we have.
I think that's actually why yousee GitHub ultimately writing a
lot more React code is that wehave the need for those things,
and even having web componentexperts at GitHub hasn't been
(08:18):
enough to get us over the humpof scaling out a non-React stack
that solves those problemspersonally, I hope that that's a
yet thing.
Drew Bragg (08:29):
Totally haven't gotten the web components yet.
But yeah, react, ate the webfor a while there.
It's nice to see that we haveoptions outside of react, but I
understand, especially at githubscale, potentially not being
able to just be like yeah, we'redone with React.
Joel Hawksley (08:46):
One example of that is styled components.
So we use styled components foryears.
We've recently I wouldn't saywe've eliminated it, but we've
moved away from it in our designsystem and are working to move
away from it almost entirely inall of our applications, and
that's a technology that I don'twant to say it was strictly
necessary, but certainly it madea lot of things easier that
(09:07):
were not as possible in theplatform.
We are now using CSS moduleswhich are closer to the platform
, and that's an example of themore status quo improving and
allowing us to move away frombespoke React or what I would
call like SPA framework specificsolutions, and in fact, that's
allowed us to do a lot morestyle reuse across both our
(09:30):
React and non-React interfaces.
Drew Bragg (09:32):
In my last episode I had Vova from Evil Martians on
and he was talking a lot aboutputting Rails in the browser and
I think a lot of what he wasenvisioning its use for was
tutorials instead of hey, go toyour computer outside of the
browser and go try this, just aninteractive thing there.
But do you and your team haveany kind of well?
(09:54):
Maybe when Rails in the browseror Ruby Wasm improves to X
point, then there's more.
That opens up for what viewcomponents can do, because we're
limited by we're completelyserver side now we don't have
enough access to the client, oris it kind of like that is so
far out in the future that it'snot even on the radar yet?
Joel Hawksley (10:18):
I think that to a certain extent and maybe this
actually speaks to how I thinkabout the framework in general
at this point we've kind ofdrawn a line in the sand when it
comes to the complexity we arewilling to implement outside of
react and we put a ceiling inthat.
I think that is very realisticbecause what we were finding is
(10:38):
that as you get into incrediblycomplex, dynamic uis with a lot
of just for example, like ourmerge box, the bottom of a pull
request when it shows all yourcheck statuses, what your
permissions are, what the stateof the branch is, what your
merge target is incredibleamount of complexity, state,
(10:59):
dynamic loading all thisasynchronous stuff.
That was really really hard tomaintain in a non-react
architecture, despite the workof many very smart people over
many years doing what they could.
It took a ground-up rewrite.
Now, to be fair, a ground-uprewrite in the full rail stack
(11:22):
might have also gone pretty well, but the ability for a new
engineer to come in and modifythat code in react is an order
of magnitude better.
So what I'm starting to get afeel for is even with changes to
the platform, I still have agut feeling that there's a
(11:43):
certain level of complexity thatis going to be a long time
before.
Certainly, practically, we canbuild it without something like
React.
And what we're finding is,conversely, what is expected in
the industry is increasinglyfalling on the other side of
that line.
Falling on the other side ofthat line as we make GitHub more
(12:04):
modern and more app-like, theexperiences we want to build are
disproportionately falling inthat land where React becomes a
clearer and clearer, optimalarchitecture for what we're
trying to deliver to ourcustomers.
So I struggle to think aboutwhat it would take to get that
far.
Now I see applications that arepowered by Hotwire.
(12:26):
Hay is one example, reallygreat application and I really
appreciate the velocity thatdevelopers get, especially on
small teams.
I mean, that's what Rails isbuilt for.
But what we're finding is that,especially over the long term,
is you have to maintain thosethings, make them accessible,
avoid visual regressions.
We have state machines thattest that merge box and visually
(12:48):
regress it and all this coolstuff, and that's very hard to
do.
We've tried to do some of thatwith view component, with
lookbook, but I mean it reallycomes down ultimately to
functional purity.
Like a React component is afunction of the state you give
it, versus when you're workingin a lot of these Rails
paradigms whether it'sexclusively your Ruby code that
can have access to any of theglobal state on the server,
(13:08):
versus React code has none ofthat on the client.
Or, if you think about it,similar concept with styles.
If you are working in thetraditional big blob of CSS
setup, you can have as good adiscipline as you want, but
you're still going to ultimatelyespecially at our scale run
into these really gnarly kind ofjust isolation kind of problems
(13:31):
.
I don't see the story of thatmeaningfully changing anytime
soon.
I know we have things likescoped styles with web
components and whatnot coming up, but those things would still
have to become popular for us tothen have people who are
willing to work on them.
Because the other inertia wesee with all this is that
(13:53):
there's just so much energygoing into making the React
developer experience great.
It is mind-boggling to see howproductive people are, and this
is getting amplified by AIbecause TypeScript is strongly
typed.
So I have a hunch that theseLLMs are really able to provide
higher quality experiences todevelopers writing React code in
(14:16):
TypeScript.
There's also just like a muchlarger corpus of TypeScript to
look at Now, whether it's a goodtraining set or not, we can
debate, but I see all thesefactors kind of sociotechnical,
like a sociotechnical landscapethat makes it really hard for me
to imagine a place where theweb platform is delivering for
(14:36):
what GitHub is building today,even like three years from now.
Drew Bragg (14:41):
Doesn't mean it doesn't, but it's hard to say.
I mean, there was a period oftime where I'm sure even the
idea of web components as wehave it now was kind of like oh,
I don't see that being a thingfor years and years.
And now here we are and it'slike web components still have a
ways to go, but they are somuch more powerful and so much
more useful, I guess, Practical,practical.
Joel Hawksley (15:08):
That I guess practical practical, that's the
word I'm looking for.
They're so much more practicalnow than they were a few years
ago.
So, and what we're going tofind is, I think, that these
platform changes, they raise thebar of how long you can use the
platform, and that's kind ofwhat I'm getting at.
Is that like okay, will weeventually raise the bar to the
point where, like all of githubfalls below that bar and then we
get into like hybridapplication problems where it's
like okay, do we really want tohave two stories for front end
of the company when we havehundreds, if not a thousand,
(15:29):
engineers working on our product?
Do we really want to have toteach them two very different
ways?
Because the other tricky partabout this is that, like it'd be
one thing if it was thesetechnologies layered on each
other, but they're sophilosophically different and
this is like another core thingwith the viewue component
framework that's been so trickyis that we are both trying to
take the best parts of React andbring them back to Rails, while
(15:50):
also not breaking mental modelsin a way that's confusing.
We don't want to try and dothings that fundamentally don't
map to Ruby.
What I found is that we wentthrough this thread for a while
where we were trying to keep acommon core including
potentially with web componentsin between our react and view
component implementations of ourdesign system and what ended up
(16:13):
happening is that you just hadthe worst of both worlds because
you have the common denominator.
It's like if you only had tocook with ingredients from two
different cuisines, the overlapof two different cuisines, but
you still had to cook in bothcuisines, but only with that
intersection of the Venn diagram, you'd make really bad food of
both cuisines and someone wouldcome and like look at cuisine A
or cuisine B and be like, oh,this is an insult to like the
(16:35):
spirit of this food.
So I think that's what you seeit's like.
Okay, if we're going to useReact, let's use it to its
fullest potential.
And I think that as soon as youstart looking at these
compatibility layers, you haveto be really careful of what
you're taking off the table.
And that goes also from theRails direction back to React.
We were even looking at how dowe architect components, say, we
(16:56):
had like a complex viewcomponent.
Well, we tried to likearchitect it the same way in
React and then we had somecompromises there, and the
problem is that thosedifferences started to affect
even how we did styling inJavaScript, and that got really
messy.
Then it's like okay, as soon asthey diverge enough, you then
have to audit them foraccessibility in a completely
(17:16):
separate manner, because youcan'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 (17:24):
Yeah, there's quite a bit that goes in there and I'm
sure, at GitHub scale it's liketo a degree that I can't even
fathom.
Like I've pretty muchpredominantly worked on small or
smaller teams like GitHub scale.
It's kind of like seeing theGrand Canyon for the first time.
You're like I knew what itlooked like, but it didn't quite
click until I saw it in person.
Joel Hawksley (17:47):
I think there's an interesting phenomenon,
though, because I think thatthere's a certain amount that's
trickling down, and maybe not ina good way, because some of the
reasons we make these decisionsdon't depend on the scale of
the application.
Accessibility is the thing I'veworked on for years at the
company and did a lot of veryinteresting work, worked with a
(18:09):
lot of great people, verypassionate people.
It is amazing to me theimplications of that work on the
technical side of things.
It's a very real and pressingconstraint that required us to
do a lot of things that, quitefrankly, were hard to justify
before.
Accessibility in terms ofaround like, say, consistency,
like how many times as aprogrammer have you be like, oh,
(18:30):
I wish these 100 buttons in ourapplication were all like the
exact same code, path, the exactsame thing.
Well, with the accessibilityrequirements, you kind of don't
have a choice, because you gotto guarantee that your whole
application can be used and isconsistent and whatnot.
So it forces those factors.
What I'm seeing in my non-lawyerprofessional opinion is that
(18:53):
that pressure is going to cometo more and more companies than
is the case right now, and Ithink that we all see is that
the way that we solve problemsat a GitHub becomes more along
the lines of what needs to bedone at smaller companies
because of that pressure.
So, for example, in the lastfive years, 80% of the top 500
(19:16):
e-commerce websites in the worldhave been sued for an
accessibility violation.
They've faced actual legalaction.
That's a lot of lawsuits.
So I know y'all are at Podia,are in e-commerce.
I think this was more likeshopping A little bit different,
but sure Digital e-commerce,and I think that what we're
(19:36):
going to find is that you'regoing to be pressured to do more
accessibility work, as I thinkis a good thing for the world.
If you have to say let's justthink about this conceptually.
As a software engineer, ifyou're going to need to, through
your architecture, guaranteethat certain key failure states
do not exist, that requiressomething like a design system
(20:00):
with constrained options.
I'll just give you a classicexample.
It's like okay, how do youguarantee that all of your
images have alt text as long asthey aren't decorative in your
application?
If you were to have like astatic guarantee, you'd probably
lend maybe some sort of teststhat would render every view.
Drew Bragg (20:16):
Yeah, something along those lines would be like
the first thing that comes tomind.
But I'm cheating a little here,cause I've seen your
accessibility talk a few timesand there are tools that help
with this.
Joel Hawksley (20:31):
Right.
But that requires you to be ableto, in a test, render every
single view state which a morefunctionally oriented paradigm
like React, which is literallystate machines for UI, is set up
to help you solve, because youcan enumerate the state
permutations of your application.
(20:52):
You look at our design systemand we do this on the real side
too to a certain extent.
We have what are called stickersheets, which is literally a
matrix of two options on acomponent.
So you might have size on theY-axis and color on the X-axis,
and that shows you thepermutation of all those
combinations for that component.
And you can do this across abunch of different options for a
(21:14):
bunch of different componentsand you can start to see the
actual surface area of all thepotential states your design
system can be in.
Now imagine if you don't have adesign system.
You would have to do that forliterally every path through
every user interface, every menu, to make sure, say, for example
, that when you focus on anysingle thing with your keyboard
(21:34):
it has sufficient focus outline.
That's a key, key thing we'vebeen doing in our product, and
getting to that level ofconfidence is very hard without
a lot of browser-based systemtests in the Rails side of
things Okay.
Drew Bragg (21:48):
Yeah, that makes sense.
You brought it up in your intro.
You just brought it up a fewtimes, so it feels like a good
time to ask about theaccessibility work that you've
done at GitHub.
Is the accessibility work thatyou've done at GitHub an ongoing
thing still, or is your move tothe Ruby architecture team kind
of maybe moving it into someoneelse's playground a little bit?
Joel Hawksley (22:09):
Right.
Like any huge initiative, ithas different phases and
different milestones, and partof the reason I moved elsewhere
in the company is that we hadreached a point of operational
maturity not maturity in theoutcomes, but we had the tools
and processes to execute well.
I can't share any specificmetrics or anything like that,
but I can say that the programcontinues to meet significant
(22:32):
further milestones after I leftmy time on the team, and it's
really impressive to see thatGitHub is continuing to invest
in those things.
It does become an evergreenthing because new UI is being
built, so like, for example, westarted the project before
Copilot was a thing, so nowthere's a whole new world of AI
(22:57):
accessibility, and I haven'treally been a part of that but
making sure that, as we'rebuilding especially new
experiences that are unfamiliarand novel, that people who are
using assistive technology canstill get the same value out of
them interesting.
Drew Bragg (23:12):
I hadn't even thought about co-pilot as
something that would need theaccessibility.
That is very interesting thatyou'd have this accessibility
initiative and then a newproduct like Copilot gets added
and like a whole new world opensup for that initiative that you
probably couldn't have evenforeseen when the initiative
(23:34):
first started.
Exactly.
Joel Hawksley (23:36):
Anytime there's a novel UI, like the example I
like to give people, is thatpart of the reason we use design
systems is to make it so thatour resources are available for
when something comes up.
That isn't typical.
If we were having to have ouraccessibility designers and
engineers work on every new page, even if that page wasn't that
different from another one, wewouldn't have the resources to,
(23:57):
say, go work on a new novel AIthing, 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 youmight not be able to retrofit a
good assistive technologyexperience on top of it.
Drew Bragg (24:13):
Interesting.
Hadn't thought about that.
So tell me a little bit aboutthe 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 workthat you're going to do with
being on the Ruby architectureteam at GitHub.
Joel Hawksley (24:29):
Sure.
So the team has a coupleresponsibilities.
One of them is keeping Ruby andRails at GitHub up to date to
head to head, so we literallyhave a dashboard that says the
number of commits we are behindRuby and Rails head in
(24:50):
production.
And that is a key thing,because we're such a big code
base that we effectively serveas a extension or an annex of
the Ruby and Rails test suites.
And I think that that'sactually something that everyone
can do at their companies isthey can run and you can pin the
(25:11):
commit.
Obviously, you don't have totake every new commit as it
lands, although I do that insome places.
It's a wild ride.
But yeah, we serve as a feedbackmechanism because you could
imagine the kind of pickle youcould end up in as a big code
base if something lands upstreamthat is going to be very
expensive or difficult toaccommodate in your code base.
(25:34):
You want to know about it rightaway because your ability to
influence a potential changeupstream is significantly
different as time goes on.
If we were waiting for anactual gem push from rails and
the thing we want is a breakingchange, that gets weird, but we
(25:57):
could get in and make thatchange before it gets out to
rubGems and that allows us tohave that kind of impact.
So it's basically the team ofpeople that are Ruby and Rails
experts at the company and wekind of follow that pattern.
We also do things that areinvestments in the language.
So, for example, we look atperformance related things.
(26:18):
We're working on ZJIT with ourfriends at Shopify, but also on
the Rails side there's this kindof broader evergreen initiative
as well to make our Rails appboring, because it's not in our
interest to maintain customlogic on top of things that are
(26:39):
of Rails concern.
So this is a story that's beentold publicly for many years.
Eileen Bouchetel has told itwell around.
There are just so many things,for example, didn't exist in the
community when they were firstbuilt.
At GitHub, we did some thingsaround background jobs, for
example.
We've done some things arounddatabases that were not in Rails
(27:01):
, but we're not in the businessof those things.
So we need to be best aspossible moving them upstream,
and it's good for all the otherusual good open source reasons
too, like it's great for us tobe able to share our experience
of things that can run it.
They can serve 10 billionrequests a day or whatever we
serve, if it can work for us, itshould work for everyone.
Drew Bragg (27:21):
If it's a technical thing, that is super cool and so
you brought up your friends atShopify.
How much overlap is there orhow much coordination and
cooperation between the teams?
I'm sure there's a lot ofoverlap and we want to work on X
, they want to work on X.
Is there a lot of communicationbetween you guys saying we're
going to work on MySQL sequel?
(27:42):
You guys can take postgres.
When it came to like I don'tknow, I was using those as an
example, potentially a bad one.
I think you get the point.
Joel Hawksley (27:50):
Yeah, there's some projects we collaborate on
and we do it across a differentbunch of different venues.
I'm still getting a feel for it.
But, for example, we have, likethe trilogy database adapter
that's now open source, so likethat's not strictly done
privately.
But I know that the thing is Ilose track of which Slack
channels are where, but thereare some Slack channels that I
have that are just with Shopifypeople that are between GitHub
(28:11):
and Shopify and this is common,I know just generally in the big
rails community is that we'reall on Slack.
So there's some Slack connectthings that go on.
Have you ever used Slackconnect?
Yeah, a little bit, it's whereyou have an outside.
Yeah, but it's where you canlike link workspaces.
You can say, okay, this channelexists both in.
Maybe Gusto and Shopify mighthave one.
(28:33):
It's just like Gusto, shopifyand it's like a little pair we
hear a lot about the work thatShopify does.
Drew Bragg (28:38):
They're very vocal about it.
I feel like maybe to a degree,github's a little less vocal
about the work they do, butcertainly 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 metfolks 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'sintentional or is it just kind
(29:01):
of like not what we do?
I know ufuk is one of the headmanagers on the ruby and rails
infrastructure team at shopifyand he's fairly vocal.
I didn't know if that was justan artifact of him being there
or if github just takes thestance of like, yeah, we're less
public about the work that wedo, or it could just be me not
(29:23):
seeing it, not having the rightpeople in my timeline.
Joel Hawksley (29:27):
I think that what you're seeing with Shopify's
investment in the Ruby and Railscommunity is extraordinary and
is something to be recognized,and I think that I'm impressed
at the amount of resourcesthey're able to dedicate it to.
It's really incredible.
My understanding is thatthey're a much bigger company
than us and I can tell you someof my mental model things,
because I can't really speak toomuch to the company priorities
(29:48):
because I don't think there'sanything that's like hugely
intentional either way in whatyou're observing.
But one of the ways I thinkabout it is that our products
are somewhat different in theirtraffic patterns.
I would guess that Shopify seesan even greater pressure for,
say, per core request efficiencythan we do, because they're
serving e-commerce traffic onBlack Friday.
(30:11):
Our traffic is a much simpler,very predictable level and it's
mostly logged in and there's awhole dynamic to that.
Versus like, I think that youjust might see just a lot of
different engineering dynamicsgoing on.
I would still say that we pushRuby and Rails to the limit in
our own way, but it's justdifferent yeah, it was just
(30:32):
something I had noticed.
Drew Bragg (30:33):
I didn't know if there was something you knew
insider knowledge that you mighthave.
So this is a loaded questionbecause you've got so many
things.
You've got view components andthe accessibility work of the
past and the Ruby architecturestuff coming up and a kid, which
I don't want to call your childa blocker, but certainly could
(30:54):
fall into like what kind ofblockers do you have as far as
like hey, I'm getting ready forpaternity leave and that
requires me to do the V4 releaseleave and that requires me to
do the v4 release.
What are the kinds of blockersthat you're dealing with, or
what's one recently that youwant?
Joel Hawksley (31:11):
to kind of get into.
I think that talk about themajor release is a really
interesting one, because what Ifound fascinating is that it's
put me in like a semper mindset.
It's made me really internalizethe true philosophical
implications of following Semver, which is that your practices
(31:31):
as a software engineer feed intothat dynamic.
And what I mean by that is thatone of the things I've really
noticed working on the projectfor so long is that Semver and
Agile, to a certain extent thosemindsets encourage certain
types of outcomes.
So, for example, I don't knowabout you, but I fear major
(31:56):
releases.
They are both a great thing anda terrible thing, like there's
a lot of pressure to get themright.
If you truly follow Semver,which we try on Vue Component,
it's your chance to do somethingbreaking, to give people work.
And what it's made me realize,as I've had time to reflect on
(32:16):
these kinds of changes that arepossible, is how our day-to-day
leads to what I call like Semverpressure or like angst.
And one example of that is that, well, agile and Semver
encourage you not to breakthings and Agile encourages you
(32:40):
to just go to the next logicalstep.
Well, after seven years ofdoing that, wouldn't you hope
that you learned how to dosomething better.
The next time around you end upin a bit of a hole, and some of
these holes you obviously can'tdig yourself out of, like we
have thousands of components ofGitHub we're not going to make
(33:00):
any hugely massive changes, butlike even something simple like
configuration options.
Try not to have a ton of them.
We got rid of some of them in V4, but even we had started adding
configuration options, and itonly in this release, when I
took a step back to look at allof them did I realize which ones
were misleading, unnecessary orjust poorly named or organized.
(33:23):
So we basically ended up withlike two categories of
configuration.
One is for generators, whichI've never used a Rails
generator in my life, which Irespect that people do, but I've
never used one.
I like to write it myself andthen the second was for previews
.
I think we ended up with likeeight or nine configuration
options.
Only one of them was top level.
The other ones were notproduction related.
But if you were reading thelist that had come out of our
(33:45):
like agile, iterative way, youwould have no clue of knowing
whether those configurationoptions were of consequence or
not.
Those configuration optionswere of consequence or not.
So Semver creates a fear of whatI would call fully refactoring
something to be correct, and Ithink this is a big difference
between library and frameworkdevelopment and application
development.
(34:06):
Imagine if you SemveredGitHub's internal code Every
single release would be breakingright.
So it's a huge mindset shift togo from that to like I'm going
to make a breaking release onceevery two years.
In part it's because you'rebreaking other people's apps.
I view it as an immenseresponsibility to not do
(34:27):
something undue, but it makesyou realize how much we like
lean on our ability to changethings and are breaking away as
an application developer whenyou can't do it that makes sense
.
Drew Bragg (34:39):
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 Idon't want to say because I
don't want to put the explicitcontent warning on my show.
This is not a major change.
(35:01):
You should not have brokenanything 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 amaintenance window.
Yeah, Like no one no one needsto worry about this.
If it's not our API, it's fine.
Joel Hawksley (35:12):
What it's really opened my eyes to is like how do
you guarantee it?
I think that, as we're seeingmore LLM generated code, where
does your confidence come fromon this?
Like I have run into the trapof your writing little scripts
and whatnot that had bugs inthem, but because I didn't write
it, I think I was way lesslikely to see it, and I've
(35:34):
started to envy the folks in thestatically typed side of things
, the compiled side of things, alittle bit more.
Started to envy the folks whowrite Elm a little bit more.
I believe they guarantee noruntime errors.
Drew Bragg (35:50):
Joel Quinville loves Elm.
I've heard him talk a lot aboutit.
I have not played with but I'mfamiliar with, just because of
listening to the bike shed.
Joel Hawksley (35:58):
Right.
Those are the kinds of thingsthat in this moment of
reflection of taking on a majorrelease, that I start to wonder
about.
And we're starting to see thiskind of generally with even
writing Ruby at GitHub.
I think that a lot of the codewe write goes a long time
without being changed, so wedon't learn the lessons of
(36:18):
changing code.
And I think this is especiallytrue in the Rails field, because
Rails is the one personframework.
Lots of prototyping happens inRails and whatnot.
I think that as you get intothat realm of having to go back
and make big changes like wehave safer accessibility or just
like sweeping product changes,you start to see where your
confidence comes from.
(36:39):
As a software engineer andespecially writing like a
framework in Ruby, it's wild tobe like oh my gosh, I'm changing
this thing and I know we have avery thorough test suite.
We've had 100% code coveragefrom day one, even branch
coverage.
But I still am worried.
We've made some fairlysignificant changes under the
(37:00):
hood in this release.
We haven't really had to changeany test cases.
It's not like they've beenbreaking changes in the tests.
It still makes you wonderBecause we don't have those
guarantees in our world, in ourRuby ecosystem in our world, in
our ruby ecosystem.
Drew Bragg (37:18):
I mean, even if you do have those quote-unquote
guarantees and like typescriptor 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 littlebit of craftsmanship but you can
say no, any right.
Joel Hawksley (37:39):
We use linters to a certain extent to file down
the sharp edges and ruby andrails.
I would guess if you look evenat rubicop, you'll see some
signs of that sprinkledthroughout, even just like
rubicop performance.
Like there are things that likethey might not explicitly be
dangerous but they might be, andwe lint against those.
Drew Bragg (38:39):
AST of Ruby code like it's unlocking some really
awesome things, that it's goingto make the whole experience of
writing Ruby that much betterand hopefully get some of that
danger, you're doing somethingpotentially bad.
Joel Hawksley (38:45):
What I wonder, though, is if to kind of go back
to something I said earlierabout, like the common
denominator of ingredientsbetween two different cuisines I
do wonder whether we are, atthe same time as we make Ruby
quote unquote better, in thoseways, making it worse for what
it actually should be, because,on the flip side, we've done a
(39:07):
lot of that work at GitHub, andI would say that I generally
feel mixed about it.
I see why we have to do it, butit certainly makes it feel less
like the language I fell inlove with.
I see why we have to do it, butit certainly makes it feel less
like the language I fell inlove with, and that is a reality
of the scale, but I can see howthere is some hesitation in the
Ruby community to add a lot ofthese things that ostensibly
make it safer and morepredictable, because I've seen
(39:29):
some Ruby code that is very safeand predictable that makes you
want to learn Go, because I'mlike well, if we're going to go
this direction, is it better totake something that is elegant
and beautiful and flexible andput it in handcuffs, or is it
better to go use a tool that wasbuilt with that in mind?
(39:50):
And this is a kind of anexistential debate I think that
I'm having with colleaguesaround the company how far do we
want to push the language andthe framework to do things that
take it further away from whatit might generally be good at,
or what it should be good at ina very like philosophical sense,
because these things are alltechnically possible.
Like we're engineers, we canbuild just about anything.
We could slowly over many yearsturn Ruby literally into Go.
(40:13):
You could just one breakingchange at a, one christmas
release at a time.
We could converge into go.
It would take time, could wenot?
that'd be great but yeah, I seewhat you're saying.
Yeah, we're on that path.
So it's like how far do youwant to take it?
Drew Bragg (40:27):
I think, for me at least, the thing I like is that
most of these guardrails, mostof these improvements that make
it a little bit safer, a littlebit 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 butit doesn't actually do anything
(40:48):
.
It just gives you the abilityto do more safety-esque things
with Ruby.
It improves how RuboCop canwork.
It improves how the LSP looksat and can find errors in our
code and whatnot.
But if you want the pure joy ofwriting Ruby like you had
(41:10):
before any of these things, youjust turn them off and then
you're back to just.
I can write my 10,000 line Rubyscript of chaos because I can
and I want to, and it's apersonal project and no one else
will ever see it and I likethat.
I like the fact that I canstill do my weird Ruby stuff.
But when I'm working at workand I need some more safety and
(41:31):
I'm dealing with thousands offiles and stuff I've never
touched or hasn't been touchedin years and the person who
wrote it left five years ago.
As it is Now, we have toolsthat help us.
It's not the same as astatically typed language per se
would be where we can likeclick on something and find
(41:51):
every iteration of it.
But even some of the new stuffin the LSP where it can guess
receivers and, as long as yournaming conventions are good,
like it does a really good job.
The guest receivers.
Joel Hawksley (42:03):
It's quite good, and I think you're having me see
it more as like separatedialects of the same language,
where it's like you have thissafe Ruby dialect or sorbade
Ruby dialect is like I sometimessee it and those things can
coexist.
I think that what I seehappening kind of maybe even
beyond the language, is thatpeople then start to compare it,
to be like okay, we're doingthis in Ruby, is this the Ruby?
(42:25):
Is this still the language wewant?
In this situation, I feelultimately torn about it.
I think that it is kind ofinteresting because it probably
extends the runway prettysignificantly for the language
and I think that it's verypragmatic.
I think that, while we do see alot of benefits, we
occasionally will take a serviceat work and rewrite it and go,
because it's just way bettersuited for the language.
Drew Bragg (42:46):
To that point, though, I would argue that
getting it built in Ruby firstwas the right call, because
you're just going to move faster.
Joel Hawksley (42:54):
And even if you rewrote it, it'd probably see a
lot of the performance benefitstoo.
What I try to avoid in thesekinds of debates is making them
technical, because these thingsare not technical decisions.
There's people and systemsinvolved, and we found that
certain types of services andlanguages and whatnot are easier
to deploy in our infrastructureand whatnot it's easier to hire
for, and I think that that'swhere just seeing the different
(43:15):
forms ruby can take is prettywild, because it can kind of
shape shift now into thesedifferent modes yeah, it is very
cool.
Drew Bragg (43:22):
It's exciting.
You are going to lose a littlebit of what made ruby so
wonderful, like just the abilityto do whatever no, guard rail,
sharp knives kind of thing.
But it's a maturity thing,right.
When we were teenagers we alsodid a lot of dumb stuff that
like, yeah, we miss it, but alsolike it hurts now to do some of
(43:44):
those things in the nextmorning, so maybe we don't do
those.
We've matured.
We could talk about this for awhole nother episode.
Joel Hawksley (43:51):
I think it's funny you say that because the
GitHub monolith is what?
17, 18 years old or whatever atthis point, so you're like your
analogy tracks well that to acertain extent, these things.
I mean it's a real testamentthat the github monolith has
remained ruby on rails for aslong as it has.
It's taken countless hours ofwork by so many smart people to
(44:12):
do that, but we're still hereand it's going to be around for
a long time, and I think thatthat's where you really learn
the implications of yourdecisions as an engineer is when
your stuff sticks around, and Ithink that that's kind of the
thing that I feel superprivileged about, ultimately in
my position, is that, like Ihave gotten to see ViewComponent
exist for six years, I'velearned so much about the
(44:35):
consequences of my decisionsversus if I had job hopped every
two years, I would have neverseen even the two-year
consequences, let alone the fouror the six-year ones.
To a certain extent, if I stickaround long enough, I might be
the person who removes it as adependency from GitHub.
I don't know, I don't thinkthat'll ever happen, but it's
the kind of thing where I thinkthe longer you are around, the
(44:57):
better lessons you learn as anengineer and it helps you make
way better decisions day to day.
Drew Bragg (45:03):
Yeah, I can agree with that because, again, we
could talk about all of thisstuff forever.
We're going to use myguardrails and we're going to
move to the next question, whichI'm sure will also yield lots
of discussion.
But what is something cool, newor interesting that you've
recently learned, discovered,read whatever.
It doesn't have to be codingrelated.
(45:24):
I've had people talk aboutendangered hobbies and cloud
whitening, and book series I'mcurrently addicted to was one of
them, which I don't know how Ifeel about it yet because I've
spent so much time reading theseries, but it can be.
We've also had people talkabout Ruby Wasm and things that
are coming out in Ruby or thatthey're building with Ruby that
(45:44):
are super exciting, or that theyjust found so for you and all
the various things that you'reinvolved with.
What is something cool, new orinteresting that you want?
Joel Hawksley (45:53):
to share.
As part of my onboarding underthe Ruby architecture team, one
of the key things I was told wasto go read Ruby under a
microscope, with the disclaimerthat 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 waythrough, but I think that if
you've been in Ruby, I feel likeyou should be automatically
(46:15):
mailed that book when you enterlike the fourth year of working
in Ruby, because you just shouldknow like I'm reading this
stuff and I'm like I've seenthese terms.
It helps me understand at afundamental level what some of
the error messages I've gottenreally meant over the years and
I I mostly understood.
Now I can deeply understand howRuby actually takes a text file
and turns it into tokens andthen takes those tokens and
(46:37):
turns it into machine code andlike the kind of like
fundamental process that if youwatched every single Aaron
Patterson keynote you'd probablyget the same education.
He did write the foreword forthe book, so it makes sense.
But yeah, that definitely wouldbe my recommendation.
It's a really solid read.
I can only handle so muchrecommendation.
It's a really solid read.
I can only handle so much.
I read like three pages rightbefore bed and it's like, okay,
(46:58):
well, I'm definitely going tosleep well tonight.
Drew Bragg (47:00):
It's a very technical, technical book and I
feel like I agree the same waywith my technical reading.
I can read like a chapter of atechnical book and then I'm like
that's enough for now With myreadings.
For fun I can read like, oh,it's been three hours, I'm still
not done reading yet.
But yeah, with technical it'sjust like I only have so much
capacity.
But yes, ruby under amicroscope is a great
(47:23):
recommendation, good call.
Joel Hawksley (47:25):
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 amicroscope, written in black.
Oh my gosh, the lessons I'velearned about ActionView.
But I think that writing onefor all of Rails would be deeply
fascinating.
I think there's a couple ofpeople on the current or former
core team members I think couldwrite a really interesting read
(47:46):
there.
I would read that book too.
Drew Bragg (47:49):
It is interesting, especially like there was a
point in my career where Inoticed myself going into the
Rails source code to debugsomething in my own application.
And just starting to go downthose layers was such an
interesting journey and seeingwhat was actually happening for
the stuff that I had just beenusing, I didn't actually know
(48:11):
what was going on.
Once I started, getting intothe source code completely
changed a lot of what I thoughtabout 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 (48:27):
Totally yeah, cause these lessons are hard to
learn when you're debugging,when you're bundle opening, when
you put your first binding dotpry 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 (48:46):
Yeah, but copilot does not fucking understand that
.
Well, I guess I'm putting theexplicit content on now.
Oh well, copilot does notunderstand this.
And if I type binding and it islike, oh, you mean dot pry and
I'm like no, stop it.
How many times do I have totype, how many times do I have
to type bindingirb before itwill learn?
(49:08):
I want bindingirb time, do youknow?
Because you work at the place.
Joel Hawksley (49:14):
Time to put it in a system prompt or something
like that.
Drew Bragg (49:16):
Yeah, I hear you.
All the AI stuff is fascinatingthe way that it looks at code
and analyzes code, the way thatit writes code.
I don't think I've gotten tothe same level of trust as a lot
of people have with it, but itis really interesting yeah.
Joel Hawksley (49:36):
I would say I'm in a similar spot.
I've been spending more timedoing it as I start to wind down
ahead of paternity leave.
I'm having a little more timeto play around with it.
I think it's really cool.
I think, especially if you'rebuilding an application, I see
it really good for kind ofbuilding something that's
already been built or writingscripts.
It's a great one.
Like I had a script to writethe other day and I just
prompted it.
I was not looking forward towriting that script and it got
(49:56):
it.
It did it.
Drew Bragg (49:58):
The landscape's changing.
I don't think our jobs are asin jeopardy as some of the AI
folks would have us feel likeour jobs are in jeopardy, but
yeah, the landscape is changingfor sure.
Yeah, agreed, cool.
So I want to respect your time.
Is there anything else that youwant to talk about with the
(50:19):
release?
Coming up With anything thatwe've touched on, anything else
that we didn't go deep enoughinto?
I'll be on here with you forthree 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 componentrelease would be super helpful.
Joel Hawksley (50:36):
We've been doing alpha releases for a while that
I know some people have beenintegrating, but getting it
integrated as soon as possible,even just on a branch, to run
against your CI.
Like I said earlier, the way wetreat 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 onpaternity leave when you run
into that bug and there arethere's other people who are
(50:57):
going to be working on theproject.
I'm not worried, but this is agreat time to be involved and
test out the release and let usknow how it goes.
Drew Bragg (51:04):
And so where can people find you and whatever
projects you want them to findon the internet?
Joel Hawksley (51:11):
My website is hoxleyorg.
I don't do any social media oranything, and viewcomponentsorg.
Drew Bragg (51:16):
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 (51:24):
So today's the 30th Monday.
We'll probably have RC2 laterthis week.
I would guess there's a thingor two we want to toss in.
I'm taking a week off to go onvacation 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 (51:42):
Right after the old RailsConf in Philadelphia.
Very cool.
Speaking of conferences, willyou be at Rocky Mountain Ruby
later in October?
Joel Hawksley (51:52):
I will be Love that we now have a great
conference in town.
It's like I could almost bikethere from my house.
Drew Bragg (51:58):
Boulder is such a cool city to have a conference
in so walkable, so much coolstuff going on around it.
Spike and team have a greatvenue and awesome conference
Looking forward to it.
Cool man, thank you so much forcoming on talking a little bit
about Vue components and all thework that you're doing at
GitHub.
It is well overdue having youon the show, so I really
(52:21):
appreciate you coming on.
Thanks for having me andlisteners.
I'll see you in the next one.
Bye.
Hello everyone and welcome to another episode of
Code and the Coding Coders whoCode it.
I'm your host, drew Bragg, andI'm joined today by Joel
Hawksley.
Joel, I'm sure that manylisteners don't need an
introduction to you, but forthose who do, could you please
briefly introduce?
Joel Hawksley (00:14):
yourself.
Sure Thanks for having me onthe show.
My name is Joel.
I'm an engineer at GitHub.
I've been here for over sevenyears now.
I've worked on a bunch ofdifferent things at the company,
most notably creating the Vuecomponent framework, of which
I've remained the leadmaintainer since gosh late 2018.
I've also done a lot of work onaccessibility, spent a couple
years working on that and mostrecently, a couple months ago, I
(00:36):
joined the Ruby architectureteam.
Really cool opportunity to workon Ruby and Rails on behalf of
GitHub.
Drew Bragg (00:44):
Yeah, that is awesome.
The way this is going to workis I'm going to ask Joel three
questions, and they're going tobe awesome based on his little
intro there.
I'm going to ask him what he'sworking on, what kind of
blockers he has.
If he doesn't have a currentblocker, he can talk about a
recent blocker he had, how hegot around solving it, things
like that.
And then the last question whatis something cool, new or
(01:11):
interesting that he's learned ordiscovered?
It could be related to being onthe new Ruby architecture team
at GitHub, but it sounds like wehave a lot to get into, so I
don't want to yammer on for toolong.
Joel, what?
Joel Hawksley (01:17):
are you working on?
So the big news of what I'mworking on is the next major
release of Vue component, whichwill be the fourth major.
The previous major was V3,which was a couple years ago
Ironically similar timing in mylife.
I was expecting my first childwhen we were working on the
(01:37):
third major, and my wife and Iare now expecting a second child
, which has kind of forced myhand to work on the fourth major
.
Drew Bragg (01:45):
Congratulations.
Sounds like you'll be havingyour 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 goout yet, but as of June 30th,
Release Candidate 1's out andthere's a pretty long list of
(02:06):
various changes, bug fixes,breaking changes, etc.
But the one thing that caughtme a little bit, first thing
that jumped out at me is sort ofthe phrasing of the release
sort of makes it sound likeyou're done not with maintaining
Vue components, but it'sfeature complete, it's a mature
gem and you don't have a ton offuture plans for it.
(02:29):
Can you talk a little bit aboutwhere you are with Vue
components?
Joel Hawksley (02:33):
I think you described it well.
It's wild to see something youcreated that you had an idea for
on an airplane years ago gothrough all the stages of
maturity, including long-termsupport.
And that's where we're at,which is me and Cameron and
Blake and Simon and Hans thecore maintainers of the
(02:57):
framework have kind of allreached this general agreement
that the project has beenfeature complete.
Actually, for a little while wekind of took a step back as I
was starting to talk about goingon paternity leave to talk
about what the next steps werefor the project and realized
that we hadn't seen a lot ofmajor changes.
We hadn't seen a lot ofproposed breaking changes, and I
(03:21):
think that's a great sign.
There were a ton of changesearly 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 otherpeople's code bases.
But I think it's time.
I think that it's good forprojects to reach this kind of
(03:43):
level of long-term support.
You see it in other projects aswell and I think that we are
certainly there.
Drew Bragg (03:49):
What's something that could change, whether it be
with Vue components underlyingarchitecture, or if it's
something a change in Rails?
Is there anything that you havein 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 tostart working on V5.
Joel Hawksley (04:12):
As part of going through this V4 cycle, I was
fortunate enough to have thelast three months full time,
with almost no meetings, to workon this project.
This release isn't just aboutdoing a major breaking change.
Actually, for me, it's aboutputting the whole project in a
long-term support mode, and thatinvolved reviewing and
(04:33):
resolving every singlediscussion issue and pull
request on the project, whichwas a massive amount of work.
Apologies to everyone out therethat I neglected.
Apparently, discussions weren'tnotifying me, so I didn't see a
lot of them.
Anyways, they weren't on myradar, especially when I wasn't
able to focus on the project asmuch.
Drew Bragg (04:49):
If only there was someone you knew who worked at.
Joel Hawksley (04:52):
GitHub that could fix that.
Well, and what I think it is isthat I think that when we first
introduced discussions, thenotification setup maybe was
more opt-in, and I think that wechanged it, maybe a couple of
years ago, to be opt-out, sothere were a lot of older
discussions that I hadn'tparticipated in.
I also know that I was atreduced capacity for other
reasons for a couple of years.
Anyways, in going through thatprocess, it was pretty clear to
(05:17):
me that there were a couple ofkey themes that have yet to be
addressed by the framework, andthe biggest one is CSS and
JavaScript architecture, and infact, we had documentation on
the framework website fordifferent ways of doing CSS and
JavaScript, and as part of thev4 release, we're removing all
(05:38):
of it because no one could agreeon it.
It went out of date super fast,so it just wasn't really
serving to have this part of ourdocumentation.
But I think that speaks to anopportunity in the future, as
you asked about, because, as I'msure you've seen in your career
, there has been so littleconsensus on how things are done
(06:01):
in that space and people comeasking to the project like, oh,
how should I do my CSS, howshould I do my JavaScript?
We don't even have one answer.
In the GitHub code base.
We're making great progress onit, getting towards something
that we feel is like moredurable in the long term sense,
but even then I don't think ourapproach is applicable to a
(06:21):
small Rails app, and that's kindof a philosophical corner you
end up painting yourself intowhen you are building something
that is so Rails adjacent, likeViewComponent.
That's just meant to be like aplugin that you pull in and just
feels like another layer youput on top of Rails.
It just should have been thereall along.
It's really hard to have anopinion about something that is
changing so much when you are inthat spot.
Drew Bragg (06:41):
Rails itself essentially went through that
like it was Webpacker.
This is how we're going to doJavaScript and CSS going forward
.
This is the way.
And then it was like, okay,actually the people in the
JavaScript space just changethis shit every other month.
We can't keep up and we don'twant to keep up, so instead
we're just going to kind of letyou do your own thing and give
(07:02):
you the access to you, dowhatever you need to do,
whatever works best for you andyour team, and we'll just adapt
for that.
Joel Hawksley (07:10):
so I think rails went through that a little bit,
so it makes sense that viewcomponents would kind of take
the same approach right, and Ithink that what is especially
difficult is that view componentis as much a mental model as it
is a framework, which is to saythat we're trying to help you
think like you would think as aReact developer, and I think
that what people crave in theCSS and JavaScript side of
(07:33):
things is the ability to thinklike they are in React when they
are not and from like arendering markup standpoint.
That was not hugely difficult topull off, like there's a lot of
gotchas inside the frameworkthat we navigate around, but
it's a whole different ball gameto say, try and implement
things like style encapsulationand dead code elimination those
(07:56):
kinds of things that peoplereally crave coming from the
React world.
It's just a whole different setof disciplines that I don't
think that, quite frankly, we'retotally, even technically,
equipped to solve in the currentstack we have.
I think that's actually why yousee GitHub ultimately writing a
lot more React code is that wehave the need for those things,
and even having web componentexperts at GitHub hasn't been
(08:18):
enough to get us over the humpof scaling out a non-React stack
that solves those problemspersonally, I hope that that's a
yet thing.
Drew Bragg (08:29):
Totally haven't gotten the web components yet.
But yeah, react, ate the webfor a while there.
It's nice to see that we haveoptions outside of react, but I
understand, especially at githubscale, potentially not being
able to just be like yeah, we'redone with React.
Joel Hawksley (08:46):
One example of that is styled components.
So we use styled components foryears.
We've recently I wouldn't saywe've eliminated it, but we've
moved away from it in our designsystem and are working to move
away from it almost entirely inall of our applications, and
that's a technology that I don'twant to say it was strictly
necessary, but certainly it madea lot of things easier that
(09:07):
were not as possible in theplatform.
We are now using CSS moduleswhich are closer to the platform
, and that's an example of themore status quo improving and
allowing us to move away frombespoke React or what I would
call like SPA framework specificsolutions, and in fact, that's
allowed us to do a lot morestyle reuse across both our
(09:30):
React and non-React interfaces.
Drew Bragg (09:32):
In my last episode I had Vova from Evil Martians on
and he was talking a lot aboutputting Rails in the browser and
I think a lot of what he wasenvisioning its use for was
tutorials instead of hey, go toyour computer outside of the
browser and go try this, just aninteractive thing there.
But do you and your team haveany kind of well?
(09:54):
Maybe when Rails in the browseror Ruby Wasm improves to X
point, then there's more.
That opens up for what viewcomponents can do, because we're
limited by we're completelyserver side now we don't have
enough access to the client, oris it kind of like that is so
far out in the future that it'snot even on the radar yet?
Joel Hawksley (10:18):
I think that to a certain extent and maybe this
actually speaks to how I thinkabout the framework in general
at this point we've kind ofdrawn a line in the sand when it
comes to the complexity we arewilling to implement outside of
react and we put a ceiling inthat.
I think that is very realisticbecause what we were finding is
(10:38):
that as you get into incrediblycomplex, dynamic uis with a lot
of just for example, like ourmerge box, the bottom of a pull
request when it shows all yourcheck statuses, what your
permissions are, what the stateof the branch is, what your
merge target is incredibleamount of complexity, state,
(10:59):
dynamic loading all thisasynchronous stuff.
That was really really hard tomaintain in a non-react
architecture, despite the workof many very smart people over
many years doing what they could.
It took a ground-up rewrite.
Now, to be fair, a ground-uprewrite in the full rail stack
(11:22):
might have also gone pretty well, but the ability for a new
engineer to come in and modifythat code in react is an order
of magnitude better.
So what I'm starting to get afeel for is even with changes to
the platform, I still have agut feeling that there's a
(11:43):
certain level of complexity thatis going to be a long time
before.
Certainly, practically, we canbuild it without something like
React.
And what we're finding is,conversely, what is expected in
the industry is increasinglyfalling on the other side of
that line.
Falling on the other side ofthat line as we make GitHub more
(12:04):
modern and more app-like, theexperiences we want to build are
disproportionately falling inthat land where React becomes a
clearer and clearer, optimalarchitecture for what we're
trying to deliver to ourcustomers.
So I struggle to think aboutwhat it would take to get that
far.
Now I see applications that arepowered by Hotwire.
(12:26):
Hay is one example, reallygreat application and I really
appreciate the velocity thatdevelopers get, especially on
small teams.
I mean, that's what Rails isbuilt for.
But what we're finding is that,especially over the long term,
is you have to maintain thosethings, make them accessible,
avoid visual regressions.
We have state machines thattest that merge box and visually
(12:48):
regress it and all this coolstuff, and that's very hard to
do.
We've tried to do some of thatwith view component, with
lookbook, but I mean it reallycomes down ultimately to
functional purity.
Like a React component is afunction of the state you give
it, versus when you're workingin a lot of these Rails
paradigms whether it'sexclusively your Ruby code that
can have access to any of theglobal state on the server,
(13:08):
versus React code has none ofthat on the client.
Or, if you think about it,similar concept with styles.
If you are working in thetraditional big blob of CSS
setup, you can have as good adiscipline as you want, but
you're still going to ultimatelyespecially at our scale run
into these really gnarly kind ofjust isolation kind of problems
(13:31):
.
I don't see the story of thatmeaningfully changing anytime
soon.
I know we have things likescoped styles with web
components and whatnot coming up, but those things would still
have to become popular for us tothen have people who are
willing to work on them.
Because the other inertia wesee with all this is that
(13:53):
there's just so much energygoing into making the React
developer experience great.
It is mind-boggling to see howproductive people are, and this
is getting amplified by AIbecause TypeScript is strongly
typed.
So I have a hunch that theseLLMs are really able to provide
higher quality experiences todevelopers writing React code in
(14:16):
TypeScript.
There's also just like a muchlarger corpus of TypeScript to
look at Now, whether it's a goodtraining set or not, we can
debate, but I see all thesefactors kind of sociotechnical,
like a sociotechnical landscapethat makes it really hard for me
to imagine a place where theweb platform is delivering for
(14:36):
what GitHub is building today,even like three years from now.
Drew Bragg (14:41):
Doesn't mean it doesn't, but it's hard to say.
I mean, there was a period oftime where I'm sure even the
idea of web components as wehave it now was kind of like oh,
I don't see that being a thingfor years and years.
And now here we are and it'slike web components still have a
ways to go, but they are somuch more powerful and so much
more useful, I guess, Practical,practical.
Joel Hawksley (15:08):
That I guess practical practical, that's the
word I'm looking for.
They're so much more practicalnow than they were a few years
ago.
So, and what we're going tofind is, I think, that these
platform changes, they raise thebar of how long you can use the
platform, and that's kind ofwhat I'm getting at.
Is that like okay, will weeventually raise the bar to the
point where, like all of githubfalls below that bar and then we
get into like hybridapplication problems where it's
like okay, do we really want tohave two stories for front end
of the company when we havehundreds, if not a thousand,
(15:29):
engineers working on our product?
Do we really want to have toteach them two very different
ways?
Because the other tricky partabout this is that, like it'd be
one thing if it was thesetechnologies layered on each
other, but they're sophilosophically different and
this is like another core thingwith the viewue component
framework that's been so trickyis that we are both trying to
take the best parts of React andbring them back to Rails, while
(15:50):
also not breaking mental modelsin a way that's confusing.
We don't want to try and dothings that fundamentally don't
map to Ruby.
What I found is that we wentthrough this thread for a while
where we were trying to keep acommon core including
potentially with web componentsin between our react and view
component implementations of ourdesign system and what ended up
(16:13):
happening is that you just hadthe worst of both worlds because
you have the common denominator.
It's like if you only had tocook with ingredients from two
different cuisines, the overlapof two different cuisines, but
you still had to cook in bothcuisines, but only with that
intersection of the Venn diagram, you'd make really bad food of
both cuisines and someone wouldcome and like look at cuisine A
or cuisine B and be like, oh,this is an insult to like the
(16:35):
spirit of this food.
So I think that's what you seeit's like.
Okay, if we're going to useReact, let's use it to its
fullest potential.
And I think that as soon as youstart looking at these
compatibility layers, you haveto be really careful of what
you're taking off the table.
And that goes also from theRails direction back to React.
We were even looking at how dowe architect components, say, we
(16:56):
had like a complex viewcomponent.
Well, we tried to likearchitect it the same way in
React and then we had somecompromises there, and the
problem is that thosedifferences started to affect
even how we did styling inJavaScript, and that got really
messy.
Then it's like okay, as soon asthey diverge enough, you then
have to audit them foraccessibility in a completely
(17:16):
separate manner, because youcan'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 (17:24):
Yeah, there's quite a bit that goes in there and I'm
sure, at GitHub scale it's liketo a degree that I can't even
fathom.
Like I've pretty muchpredominantly worked on small or
smaller teams like GitHub scale.
It's kind of like seeing theGrand Canyon for the first time.
You're like I knew what itlooked like, but it didn't quite
click until I saw it in person.
Joel Hawksley (17:47):
I think there's an interesting phenomenon,
though, because I think thatthere's a certain amount that's
trickling down, and maybe not ina good way, because some of the
reasons we make these decisionsdon't depend on the scale of
the application.
Accessibility is the thing I'veworked on for years at the
company and did a lot of veryinteresting work, worked with a
(18:09):
lot of great people, verypassionate people.
It is amazing to me theimplications of that work on the
technical side of things.
It's a very real and pressingconstraint that required us to
do a lot of things that, quitefrankly, were hard to justify
before.
Accessibility in terms ofaround like, say, consistency,
like how many times as aprogrammer have you be like, oh,
(18:30):
I wish these 100 buttons in ourapplication were all like the
exact same code, path, the exactsame thing.
Well, with the accessibilityrequirements, you kind of don't
have a choice, because you gotto guarantee that your whole
application can be used and isconsistent and whatnot.
So it forces those factors.
What I'm seeing in my non-lawyerprofessional opinion is that
(18:53):
that pressure is going to cometo more and more companies than
is the case right now, and Ithink that we all see is that
the way that we solve problemsat a GitHub becomes more along
the lines of what needs to bedone at smaller companies
because of that pressure.
So, for example, in the lastfive years, 80% of the top 500
(19:16):
e-commerce websites in the worldhave been sued for an
accessibility violation.
They've faced actual legalaction.
That's a lot of lawsuits.
So I know y'all are at Podia,are in e-commerce.
I think this was more likeshopping A little bit different,
but sure Digital e-commerce,and I think that what we're
(19:36):
going to find is that you'regoing to be pressured to do more
accessibility work, as I thinkis a good thing for the world.
If you have to say let's justthink about this conceptually.
As a software engineer, ifyou're going to need to, through
your architecture, guaranteethat certain key failure states
do not exist, that requiressomething like a design system
(20:00):
with constrained options.
I'll just give you a classicexample.
It's like okay, how do youguarantee that all of your
images have alt text as long asthey aren't decorative in your
application?
If you were to have like astatic guarantee, you'd probably
lend maybe some sort of teststhat would render every view.
Drew Bragg (20:16):
Yeah, something along those lines would be like
the first thing that comes tomind.
But I'm cheating a little here,cause I've seen your
accessibility talk a few timesand there are tools that help
with this.
Joel Hawksley (20:31):
Right.
But that requires you to be ableto, in a test, render every
single view state which a morefunctionally oriented paradigm
like React, which is literallystate machines for UI, is set up
to help you solve, because youcan enumerate the state
permutations of your application.
(20:52):
You look at our design systemand we do this on the real side
too to a certain extent.
We have what are called stickersheets, which is literally a
matrix of two options on acomponent.
So you might have size on theY-axis and color on the X-axis,
and that shows you thepermutation of all those
combinations for that component.
And you can do this across abunch of different options for a
(21:14):
bunch of different componentsand you can start to see the
actual surface area of all thepotential states your design
system can be in.
Now imagine if you don't have adesign system.
You would have to do that forliterally every path through
every user interface, every menu, to make sure, say, for example
, that when you focus on anysingle thing with your keyboard
(21:34):
it has sufficient focus outline.
That's a key, key thing we'vebeen doing in our product, and
getting to that level ofconfidence is very hard without
a lot of browser-based systemtests in the Rails side of
things Okay.
Drew Bragg (21:48):
Yeah, that makes sense.
You brought it up in your intro.
You just brought it up a fewtimes, so it feels like a good
time to ask about theaccessibility work that you've
done at GitHub.
Is the accessibility work thatyou've done at GitHub an ongoing
thing still, or is your move tothe Ruby architecture team kind
of maybe moving it into someoneelse's playground a little bit?
Joel Hawksley (22:09):
Right.
Like any huge initiative, ithas different phases and
different milestones, and partof the reason I moved elsewhere
in the company is that we hadreached a point of operational
maturity not maturity in theoutcomes, but we had the tools
and processes to execute well.
I can't share any specificmetrics or anything like that,
but I can say that the programcontinues to meet significant
(22:32):
further milestones after I leftmy time on the team, and it's
really impressive to see thatGitHub is continuing to invest
in those things.
It does become an evergreenthing because new UI is being
built, so like, for example, westarted the project before
Copilot was a thing, so nowthere's a whole new world of AI
(22:57):
accessibility, and I haven'treally been a part of that but
making sure that, as we'rebuilding especially new
experiences that are unfamiliarand novel, that people who are
using assistive technology canstill get the same value out of
them interesting.
Drew Bragg (23:12):
I hadn't even thought about co-pilot as
something that would need theaccessibility.
That is very interesting thatyou'd have this accessibility
initiative and then a newproduct like Copilot gets added
and like a whole new world opensup for that initiative that you
probably couldn't have evenforeseen when the initiative
(23:34):
first started.
Exactly.
Joel Hawksley (23:36):
Anytime there's a novel UI, like the example I
like to give people, is thatpart of the reason we use design
systems is to make it so thatour resources are available for
when something comes up.
That isn't typical.
If we were having to have ouraccessibility designers and
engineers work on every new page, even if that page wasn't that
different from another one, wewouldn't have the resources to,
(23:57):
say, go work on a new novel AIthing, 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 youmight not be able to retrofit a
good assistive technologyexperience on top of it.
Drew Bragg (24:13):
Interesting.
Hadn't thought about that.
So tell me a little bit aboutthe 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 workthat you're going to do with
being on the Ruby architectureteam at GitHub.
Joel Hawksley (24:29):
Sure.
So the team has a coupleresponsibilities.
One of them is keeping Ruby andRails at GitHub up to date to
head to head, so we literallyhave a dashboard that says the
number of commits we are behindRuby and Rails head in
(24:50):
production.
And that is a key thing,because we're such a big code
base that we effectively serveas a extension or an annex of
the Ruby and Rails test suites.
And I think that that'sactually something that everyone
can do at their companies isthey can run and you can pin the
(25:11):
commit.
Obviously, you don't have totake every new commit as it
lands, although I do that insome places.
It's a wild ride.
But yeah, we serve as a feedbackmechanism because you could
imagine the kind of pickle youcould end up in as a big code
base if something lands upstreamthat is going to be very
expensive or difficult toaccommodate in your code base.
(25:34):
You want to know about it rightaway because your ability to
influence a potential changeupstream is significantly
different as time goes on.
If we were waiting for anactual gem push from rails and
the thing we want is a breakingchange, that gets weird, but we
(25:57):
could get in and make thatchange before it gets out to
rubGems and that allows us tohave that kind of impact.
So it's basically the team ofpeople that are Ruby and Rails
experts at the company and wekind of follow that pattern.
We also do things that areinvestments in the language.
So, for example, we look atperformance related things.
(26:18):
We're working on ZJIT with ourfriends at Shopify, but also on
the Rails side there's this kindof broader evergreen initiative
as well to make our Rails appboring, because it's not in our
interest to maintain customlogic on top of things that are
(26:39):
of Rails concern.
So this is a story that's beentold publicly for many years.
Eileen Bouchetel has told itwell around.
There are just so many things,for example, didn't exist in the
community when they were firstbuilt.
At GitHub, we did some thingsaround background jobs, for
example.
We've done some things arounddatabases that were not in Rails
(27:01):
, but we're not in the businessof those things.
So we need to be best aspossible moving them upstream,
and it's good for all the otherusual good open source reasons
too, like it's great for us tobe able to share our experience
of things that can run it.
They can serve 10 billionrequests a day or whatever we
serve, if it can work for us, itshould work for everyone.
Drew Bragg (27:21):
If it's a technical thing, that is super cool and so
you brought up your friends atShopify.
How much overlap is there orhow much coordination and
cooperation between the teams?
I'm sure there's a lot ofoverlap and we want to work on X
, they want to work on X.
Is there a lot of communicationbetween you guys saying we're
going to work on MySQL sequel?
(27:42):
You guys can take postgres.
When it came to like I don'tknow, I was using those as an
example, potentially a bad one.
I think you get the point.
Joel Hawksley (27:50):
Yeah, there's some projects we collaborate on
and we do it across a differentbunch of different venues.
I'm still getting a feel for it.
But, for example, we have, likethe trilogy database adapter
that's now open source, so likethat's not strictly done
privately.
But I know that the thing is Ilose track of which Slack
channels are where, but thereare some Slack channels that I
have that are just with Shopifypeople that are between GitHub
(28:11):
and Shopify and this is common,I know just generally in the big
rails community is that we'reall on Slack.
So there's some Slack connectthings that go on.
Have you ever used Slackconnect?
Yeah, a little bit, it's whereyou have an outside.
Yeah, but it's where you canlike link workspaces.
You can say, okay, this channelexists both in.
Maybe Gusto and Shopify mighthave one.
(28:33):
It's just like Gusto, shopifyand it's like a little pair we
hear a lot about the work thatShopify does.
Drew Bragg (28:38):
They're very vocal about it.
I feel like maybe to a degree,github's a little less vocal
about the work they do, butcertainly 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 metfolks 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'sintentional or is it just kind
(29:01):
of like not what we do?
I know ufuk is one of the headmanagers on the ruby and rails
infrastructure team at shopifyand he's fairly vocal.
I didn't know if that was justan artifact of him being there
or if github just takes thestance of like, yeah, we're less
public about the work that wedo, or it could just be me not
(29:23):
seeing it, not having the rightpeople in my timeline.
Joel Hawksley (29:27):
I think that what you're seeing with Shopify's
investment in the Ruby and Railscommunity is extraordinary and
is something to be recognized,and I think that I'm impressed
at the amount of resourcesthey're able to dedicate it to.
It's really incredible.
My understanding is thatthey're a much bigger company
than us and I can tell you someof my mental model things,
because I can't really speak toomuch to the company priorities
(29:48):
because I don't think there'sanything that's like hugely
intentional either way in whatyou're observing.
But one of the ways I thinkabout it is that our products
are somewhat different in theirtraffic patterns.
I would guess that Shopify seesan even greater pressure for,
say, per core request efficiencythan we do, because they're
serving e-commerce traffic onBlack Friday.
(30:11):
Our traffic is a much simpler,very predictable level and it's
mostly logged in and there's awhole dynamic to that.
Versus like, I think that youjust might see just a lot of
different engineering dynamicsgoing on.
I would still say that we pushRuby and Rails to the limit in
our own way, but it's justdifferent yeah, it was just
(30:32):
something I had noticed.
Drew Bragg (30:33):
I didn't know if there was something you knew
insider knowledge that you mighthave.
So this is a loaded questionbecause you've got so many
things.
You've got view components andthe accessibility work of the
past and the Ruby architecturestuff coming up and a kid, which
I don't want to call your childa blocker, but certainly could
(30:54):
fall into like what kind ofblockers do you have as far as
like hey, I'm getting ready forpaternity leave and that
requires me to do the V4 releaseleave and that requires me to
do the v4 release.
What are the kinds of blockersthat you're dealing with, or
what's one recently that youwant?
Joel Hawksley (31:11):
to kind of get into.
I think that talk about themajor release is a really
interesting one, because what Ifound fascinating is that it's
put me in like a semper mindset.
It's made me really internalizethe true philosophical
implications of following Semver, which is that your practices
(31:31):
as a software engineer feed intothat dynamic.
And what I mean by that is thatone of the things I've really
noticed working on the projectfor so long is that Semver and
Agile, to a certain extent thosemindsets encourage certain
types of outcomes.
So, for example, I don't knowabout you, but I fear major
(31:56):
releases.
They are both a great thing anda terrible thing, like there's
a lot of pressure to get themright.
If you truly follow Semver,which we try on Vue Component,
it's your chance to do somethingbreaking, to give people work.
And what it's made me realize,as I've had time to reflect on
(32:16):
these kinds of changes that arepossible, is how our day-to-day
leads to what I call like Semverpressure or like angst.
And one example of that is that, well, agile and Semver
encourage you not to breakthings and Agile encourages you
(32:40):
to just go to the next logicalstep.
Well, after seven years ofdoing that, wouldn't you hope
that you learned how to dosomething better.
The next time around you end upin a bit of a hole, and some of
these holes you obviously can'tdig yourself out of, like we
have thousands of components ofGitHub we're not going to make
(33:00):
any hugely massive changes, butlike even something simple like
configuration options.
Try not to have a ton of them.
We got rid of some of them in V4, but even we had started adding
configuration options, and itonly in this release, when I
took a step back to look at allof them did I realize which ones
were misleading, unnecessary orjust poorly named or organized.
(33:23):
So we basically ended up withlike two categories of
configuration.
One is for generators, whichI've never used a Rails
generator in my life, which Irespect that people do, but I've
never used one.
I like to write it myself andthen the second was for previews
.
I think we ended up with likeeight or nine configuration
options.
Only one of them was top level.
The other ones were notproduction related.
But if you were reading thelist that had come out of our
(33:45):
like agile, iterative way, youwould have no clue of knowing
whether those configurationoptions were of consequence or
not.
Those configuration optionswere of consequence or not.
So Semver creates a fear of whatI would call fully refactoring
something to be correct, and Ithink this is a big difference
between library and frameworkdevelopment and application
development.
(34:06):
Imagine if you SemveredGitHub's internal code Every
single release would be breakingright.
So it's a huge mindset shift togo from that to like I'm going
to make a breaking release onceevery two years.
In part it's because you'rebreaking other people's apps.
I view it as an immenseresponsibility to not do
(34:27):
something undue, but it makesyou realize how much we like
lean on our ability to changethings and are breaking away as
an application developer whenyou can't do it that makes sense
.
Drew Bragg (34:39):
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 Idon't want to say because I
don't want to put the explicitcontent warning on my show.
This is not a major change.
(35:01):
You should not have brokenanything 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 amaintenance window.
Yeah, Like no one no one needsto worry about this.
If it's not our API, it's fine.
Joel Hawksley (35:12):
What it's really opened my eyes to is like how do
you guarantee it?
I think that, as we're seeingmore LLM generated code, where
does your confidence come fromon this?
Like I have run into the trapof your writing little scripts
and whatnot that had bugs inthem, but because I didn't write
it, I think I was way lesslikely to see it, and I've
(35:34):
started to envy the folks in thestatically typed side of things
, the compiled side of things, alittle bit more.
Started to envy the folks whowrite Elm a little bit more.
I believe they guarantee noruntime errors.
Drew Bragg (35:50):
Joel Quinville loves Elm.
I've heard him talk a lot aboutit.
I have not played with but I'mfamiliar with, just because of
listening to the bike shed.
Joel Hawksley (35:58):
Right.
Those are the kinds of thingsthat in this moment of
reflection of taking on a majorrelease, that I start to wonder
about.
And we're starting to see thiskind of generally with even
writing Ruby at GitHub.
I think that a lot of the codewe write goes a long time
without being changed, so wedon't learn the lessons of
(36:18):
changing code.
And I think this is especiallytrue in the Rails field, because
Rails is the one personframework.
Lots of prototyping happens inRails and whatnot.
I think that as you get intothat realm of having to go back
and make big changes like wehave safer accessibility or just
like sweeping product changes,you start to see where your
confidence comes from.
(36:39):
As a software engineer andespecially writing like a
framework in Ruby, it's wild tobe like oh my gosh, I'm changing
this thing and I know we have avery thorough test suite.
We've had 100% code coveragefrom day one, even branch
coverage.
But I still am worried.
We've made some fairlysignificant changes under the
(37:00):
hood in this release.
We haven't really had to changeany test cases.
It's not like they've beenbreaking changes in the tests.
It still makes you wonderBecause we don't have those
guarantees in our world, in ourRuby ecosystem in our world, in
our ruby ecosystem.
Drew Bragg (37:18):
I mean, even if you do have those quote-unquote
guarantees and like typescriptor 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 littlebit of craftsmanship but you can
say no, any right.
Joel Hawksley (37:39):
We use linters to a certain extent to file down
the sharp edges and ruby andrails.
I would guess if you look evenat rubicop, you'll see some
signs of that sprinkledthroughout, even just like
rubicop performance.
Like there are things that likethey might not explicitly be
dangerous but they might be, andwe lint against those.
Drew Bragg (38:39):
AST of Ruby code like it's unlocking some really
awesome things, that it's goingto make the whole experience of
writing Ruby that much betterand hopefully get some of that
danger, you're doing somethingpotentially bad.
Joel Hawksley (38:45):
What I wonder, though, is if to kind of go back
to something I said earlierabout, like the common
denominator of ingredientsbetween two different cuisines I
do wonder whether we are, atthe same time as we make Ruby
quote unquote better, in thoseways, making it worse for what
it actually should be, because,on the flip side, we've done a
(39:07):
lot of that work at GitHub, andI would say that I generally
feel mixed about it.
I see why we have to do it, butit certainly makes it feel less
like the language I fell inlove with.
I see why we have to do it, butit certainly makes it feel less
like the language I fell inlove with, and that is a reality
of the scale, but I can see howthere is some hesitation in the
Ruby community to add a lot ofthese things that ostensibly
make it safer and morepredictable, because I've seen
(39:29):
some Ruby code that is very safeand predictable that makes you
want to learn Go, because I'mlike well, if we're going to go
this direction, is it better totake something that is elegant
and beautiful and flexible andput it in handcuffs, or is it
better to go use a tool that wasbuilt with that in mind?
(39:50):
And this is a kind of anexistential debate I think that
I'm having with colleaguesaround the company how far do we
want to push the language andthe framework to do things that
take it further away from whatit might generally be good at,
or what it should be good at ina very like philosophical sense,
because these things are alltechnically possible.
Like we're engineers, we canbuild just about anything.
We could slowly over many yearsturn Ruby literally into Go.
(40:13):
You could just one breakingchange at a, one christmas
release at a time.
We could converge into go.
It would take time, could wenot?
that'd be great but yeah, I seewhat you're saying.
Yeah, we're on that path.
So it's like how far do youwant to take it?
Drew Bragg (40:27):
I think, for me at least, the thing I like is that
most of these guardrails, mostof these improvements that make
it a little bit safer, a littlebit 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 butit doesn't actually do anything
(40:48):
.
It just gives you the abilityto do more safety-esque things
with Ruby.
It improves how RuboCop canwork.
It improves how the LSP looksat and can find errors in our
code and whatnot.
But if you want the pure joy ofwriting Ruby like you had
(41:10):
before any of these things, youjust turn them off and then
you're back to just.
I can write my 10,000 line Rubyscript of chaos because I can
and I want to, and it's apersonal project and no one else
will ever see it and I likethat.
I like the fact that I canstill do my weird Ruby stuff.
But when I'm working at workand I need some more safety and
(41:31):
I'm dealing with thousands offiles and stuff I've never
touched or hasn't been touchedin years and the person who
wrote it left five years ago.
As it is Now, we have toolsthat help us.
It's not the same as astatically typed language per se
would be where we can likeclick on something and find
(41:51):
every iteration of it.
But even some of the new stuffin the LSP where it can guess
receivers and, as long as yournaming conventions are good,
like it does a really good job.
The guest receivers.
Joel Hawksley (42:03):
It's quite good, and I think you're having me see
it more as like separatedialects of the same language,
where it's like you have thissafe Ruby dialect or sorbade
Ruby dialect is like I sometimessee it and those things can
coexist.
I think that what I seehappening kind of maybe even
beyond the language, is thatpeople then start to compare it,
to be like okay, we're doingthis in Ruby, is this the Ruby?
(42:25):
Is this still the language wewant?
In this situation, I feelultimately torn about it.
I think that it is kind ofinteresting because it probably
extends the runway prettysignificantly for the language
and I think that it's verypragmatic.
I think that, while we do see alot of benefits, we
occasionally will take a serviceat work and rewrite it and go,
because it's just way bettersuited for the language.
Drew Bragg (42:46):
To that point, though, I would argue that
getting it built in Ruby firstwas the right call, because
you're just going to move faster.
Joel Hawksley (42:54):
And even if you rewrote it, it'd probably see a
lot of the performance benefitstoo.
What I try to avoid in thesekinds of debates is making them
technical, because these thingsare not technical decisions.
There's people and systemsinvolved, and we found that
certain types of services andlanguages and whatnot are easier
to deploy in our infrastructureand whatnot it's easier to hire
for, and I think that that'swhere just seeing the different
(43:15):
forms ruby can take is prettywild, because it can kind of
shape shift now into thesedifferent modes yeah, it is very
cool.
Drew Bragg (43:22):
It's exciting.
You are going to lose a littlebit of what made ruby so
wonderful, like just the abilityto do whatever no, guard rail,
sharp knives kind of thing.
But it's a maturity thing,right.
When we were teenagers we alsodid a lot of dumb stuff that
like, yeah, we miss it, but alsolike it hurts now to do some of
(43:44):
those things in the nextmorning, so maybe we don't do
those.
We've matured.
We could talk about this for awhole nother episode.
Joel Hawksley (43:51):
I think it's funny you say that because the
GitHub monolith is what?
17, 18 years old or whatever atthis point, so you're like your
analogy tracks well that to acertain extent, these things.
I mean it's a real testamentthat the github monolith has
remained ruby on rails for aslong as it has.
It's taken countless hours ofwork by so many smart people to
(44:12):
do that, but we're still hereand it's going to be around for
a long time, and I think thatthat's where you really learn
the implications of yourdecisions as an engineer is when
your stuff sticks around, and Ithink that that's kind of the
thing that I feel superprivileged about, ultimately in
my position, is that, like Ihave gotten to see ViewComponent
exist for six years, I'velearned so much about the
(44:35):
consequences of my decisionsversus if I had job hopped every
two years, I would have neverseen even the two-year
consequences, let alone the fouror the six-year ones.
To a certain extent, if I stickaround long enough, I might be
the person who removes it as adependency from GitHub.
I don't know, I don't thinkthat'll ever happen, but it's
the kind of thing where I thinkthe longer you are around, the
(44:57):
better lessons you learn as anengineer and it helps you make
way better decisions day to day.
Drew Bragg (45:03):
Yeah, I can agree with that because, again, we
could talk about all of thisstuff forever.
We're going to use myguardrails and we're going to
move to the next question, whichI'm sure will also yield lots
of discussion.
But what is something cool, newor interesting that you've
recently learned, discovered,read whatever.
It doesn't have to be codingrelated.
(45:24):
I've had people talk aboutendangered hobbies and cloud
whitening, and book series I'mcurrently addicted to was one of
them, which I don't know how Ifeel about it yet because I've
spent so much time reading theseries, but it can be.
We've also had people talkabout Ruby Wasm and things that
are coming out in Ruby or thatthey're building with Ruby that
(45:44):
are super exciting, or that theyjust found so for you and all
the various things that you'reinvolved with.
What is something cool, new orinteresting that you want?
Joel Hawksley (45:53):
to share.
As part of my onboarding underthe Ruby architecture team, one
of the key things I was told wasto go read Ruby under a
microscope, with the disclaimerthat 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 waythrough, but I think that if
you've been in Ruby, I feel likeyou should be automatically
(46:15):
mailed that book when you enterlike the fourth year of working
in Ruby, because you just shouldknow like I'm reading this
stuff and I'm like I've seenthese terms.
It helps me understand at afundamental level what some of
the error messages I've gottenreally meant over the years and
I I mostly understood.
Now I can deeply understand howRuby actually takes a text file
and turns it into tokens andthen takes those tokens and
(46:37):
turns it into machine code andlike the kind of like
fundamental process that if youwatched every single Aaron
Patterson keynote you'd probablyget the same education.
He did write the foreword forthe book, so it makes sense.
But yeah, that definitely wouldbe my recommendation.
It's a really solid read.
I can only handle so muchrecommendation.
It's a really solid read.
I can only handle so much.
I read like three pages rightbefore bed and it's like, okay,
(46:58):
well, I'm definitely going tosleep well tonight.
Drew Bragg (47:00):
It's a very technical, technical book and I
feel like I agree the same waywith my technical reading.
I can read like a chapter of atechnical book and then I'm like
that's enough for now With myreadings.
For fun I can read like, oh,it's been three hours, I'm still
not done reading yet.
But yeah, with technical it'sjust like I only have so much
capacity.
But yes, ruby under amicroscope is a great
(47:23):
recommendation, good call.
Joel Hawksley (47:25):
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 amicroscope, written in black.
Oh my gosh, the lessons I'velearned about ActionView.
But I think that writing onefor all of Rails would be deeply
fascinating.
I think there's a couple ofpeople on the current or former
core team members I think couldwrite a really interesting read
(47:46):
there.
I would read that book too.
Drew Bragg (47:49):
It is interesting, especially like there was a
point in my career where Inoticed myself going into the
Rails source code to debugsomething in my own application.
And just starting to go downthose layers was such an
interesting journey and seeingwhat was actually happening for
the stuff that I had just beenusing, I didn't actually know
(48:11):
what was going on.
Once I started, getting intothe source code completely
changed a lot of what I thoughtabout 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 (48:27):
Totally yeah, cause these lessons are hard to
learn when you're debugging,when you're bundle opening, when
you put your first binding dotpry 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 (48:46):
Yeah, but copilot does not fucking understand that
.
Well, I guess I'm putting theexplicit content on now.
Oh well, copilot does notunderstand this.
And if I type binding and it islike, oh, you mean dot pry and
I'm like no, stop it.
How many times do I have totype, how many times do I have
to type bindingirb before itwill learn?
(49:08):
I want bindingirb time, do youknow?
Because you work at the place.
Joel Hawksley (49:14):
Time to put it in a system prompt or something
like that.
Drew Bragg (49:16):
Yeah, I hear you.
All the AI stuff is fascinatingthe way that it looks at code
and analyzes code, the way thatit writes code.
I don't think I've gotten tothe same level of trust as a lot
of people have with it, but itis really interesting yeah.
Joel Hawksley (49:36):
I would say I'm in a similar spot.
I've been spending more timedoing it as I start to wind down
ahead of paternity leave.
I'm having a little more timeto play around with it.
I think it's really cool.
I think, especially if you'rebuilding an application, I see
it really good for kind ofbuilding something that's
already been built or writingscripts.
It's a great one.
Like I had a script to writethe other day and I just
prompted it.
I was not looking forward towriting that script and it got
(49:56):
it.
It did it.
Drew Bragg (49:58):
The landscape's changing.
I don't think our jobs are asin jeopardy as some of the AI
folks would have us feel likeour jobs are in jeopardy, but
yeah, the landscape is changingfor sure.
Yeah, agreed, cool.
So I want to respect your time.
Is there anything else that youwant to talk about with the
(50:19):
release?
Coming up With anything thatwe've touched on, anything else
that we didn't go deep enoughinto?
I'll be on here with you forthree 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 componentrelease would be super helpful.
Joel Hawksley (50:36):
We've been doing alpha releases for a while that
I know some people have beenintegrating, but getting it
integrated as soon as possible,even just on a branch, to run
against your CI.
Like I said earlier, the way wetreat 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 onpaternity leave when you run
into that bug and there arethere's other people who are
(50:57):
going to be working on theproject.
I'm not worried, but this is agreat time to be involved and
test out the release and let usknow how it goes.
Drew Bragg (51:04):
And so where can people find you and whatever
projects you want them to findon the internet?
Joel Hawksley (51:11):
My website is hoxleyorg.
I don't do any social media oranything, and viewcomponentsorg.
Drew Bragg (51:16):
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 (51:24):
So today's the 30th Monday.
We'll probably have RC2 laterthis week.
I would guess there's a thingor two we want to toss in.
I'm taking a week off to go onvacation 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 (51:42):
Right after the old RailsConf in Philadelphia.
Very cool.
Speaking of conferences, willyou be at Rocky Mountain Ruby
later in October?
Joel Hawksley (51:52):
I will be Love that we now have a great
conference in town.
It's like I could almost bikethere from my house.
Drew Bragg (51:58):
Boulder is such a cool city to have a conference
in so walkable, so much coolstuff going on around it.
Spike and team have a greatvenue and awesome conference
Looking forward to it.
Cool man, thank you so much forcoming on talking a little bit
about Vue components and all thework that you're doing at
GitHub.
It is well overdue having youon the show, so I really
(52:21):
appreciate you coming on.
Thanks for having me andlisteners.
I'll see you in the next one.
Bye.
Popular Podcasts
United States of Kennedy
United States of Kennedy is a podcast about our cultural fascination with the Kennedy dynasty. Every week, hosts Lyra Smith and George Civeris go into one aspect of the Kennedy story.
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com