Bazel with Alex Eagle - AiA 422 - Adventures in Angular

Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:06):
Hello, everyone, thanks for coming to another episode of Adventures
in Angul There. Today we have Aaron Frost, your host.
I work with Hero Devez and with Angie Koon. And
on the panel we have Joseph Eames.

Speaker 2 (00:20):
Hello, I also refer to myself am the third person
Joseph Imes here and the CEO of thanks to Happy
to be here.

Speaker 3 (00:27):
We have Jennifer Widella.

Speaker 4 (00:29):
Do I have to say something witty and in the
third person.

Speaker 3 (00:32):
Third person's optional whitty? We already knew you were. What
do you require?

Speaker 4 (00:36):
Okay? Well, I am a JavaScript developer at a consulting
company called the Toove. And we'll make fun of Aaron
as much as I can.

Speaker 1 (00:44):
Why are you talking about the ka I thought you were.

Speaker 4 (00:48):
I will take the whole podcast just to talk about kombucha.
And I actually just bottled a new batch and it's
extra fermented and pineapple Serrano.

Speaker 3 (00:55):
Flavored pineapple serrano.

Speaker 4 (00:58):
Oh yeah, Like I gave it to my my girlfriend's
like husbands like spat it out his nose because he
wasn't prepared for the spice. It was hilarious.

Speaker 3 (01:05):
Well that's amazing. That sounds really good.

Speaker 1 (01:07):
And then we have a special guest today. He comes
from US from San Jose area, Moum, New area. His
name is Alex Eagle and he's from the Angular team.
He works on CELI. I'm gonna let him introduce himself, Alex,
go ahead, Hi.

Speaker 3 (01:23):
Yeah, Alex Eagle is a third person? Can I use
the royal we? Is that confusing? That might be confusing?
Especially language? Good? Yeah, So we work on it was
CLI team. Yeah, I've been to Google for over ten years.
That we're working on Angler for like four and a
half years and recently working mostly building test developer tooling

(01:46):
kind of stuff. So I've been leaving Cli for the
last six months or so, and I've been working on
Basil for a couple of years, which I think we're
going to talk about. Yeah, yeah, let's talk about it.
So I tweeted last night that you need to be
wary of people that have first names for last names.
Is Eagle a first name? I was really tempted to
reply to that last night and say like like this,

(02:08):
this seems unkind to someone, and of course James Henry
for god, No, I don't feel like anything to contribute
to that threat. As far as I know, Eagle is
only a last name.

Speaker 1 (02:17):
Eagle's only it's pretty cool nickname, though it could be
a person name is on sain.

Speaker 3 (02:22):
People may need to be worried of you. You're you're
in the gray area, right.

Speaker 5 (02:26):
It's a title. It's not a first or last name.
It's a title.

Speaker 3 (02:30):
Alex the Eagle, the Eagle Squire, the third yep, so Alex.

Speaker 1 (02:35):
We've been hearing about Basil for less time than we've
been hearing about IVY, but still a long time. Yeah,
we all know IVY fixes everything, but Basil fixes a
couple other things.

Speaker 3 (02:47):
So so what's kind of a state of Basil right
right now? So the state of it is we launched
an opt in preview at ng CONF, which is coincidentally
the same thing that IVY is in. So yeah, there's
two big efforts that are both at a similar stage
in their in their in their life cycle, which is
that they're big disruptive changes. Well disruptive in terms of

(03:08):
there's a lot changing in angular Obviously, both of these
we want to land without disruption for users, and so
the hard thing is to go like to vet whether
whether it works for everybody's applications before we try to
roll it out widely. So that's true for iv and
we're right. We've we've asked people to opt into IVY
and tell us if it breaks their up. For Basil,
it's similarly possible to opt in and use BASIL today.

(03:31):
But I think you know what we'll spend most of
our time talking about is what why would you want
to do that IVY? As you said, like, there's this
perception that it does. It does solve a bunch of things,
and it also unlocks our team to be able to
do a bunch of things. Basils is solving a more
specific problem, which is largely enterprise scale building really big
apps with lots of engineers and lots of lots of code.

Speaker 4 (03:53):
What's your elevator pitch? Why should we opt in today?

Speaker 3 (03:57):
So I think the elevator pitch is mostly directed that
people have a specific problem, and so if you don't
have that problem, then I don't necessarily want to get
everybody to use a thing that adds, you know, a
risk for you and doesn't doesn't have upside. So the
upside is that Basil is a different approach to how
to orchestrate all of the work that needs to happen

(04:18):
when you run your building test, and it decouples all
of the different tools in a way that is sort
of like the Unix philosophy. It is like each of
these tools can be run independently, and then we just
need like an equivalent of the Unix pipe, which lets
me take centered output of one tool and put it
into sandard input of the next. So that means the elevator,
I mean, the elevator pitch is really we want to

(04:39):
make your building test a lot faster, and we think
that this is an area where the CLI hasn't been
really strong for for big enterprise apps. This isn't the
problem we've tried to solve in the past, so this
is us trying to solve that problem. So currently, I
make a new Angular project, right, and then.

Speaker 1 (04:53):
Me and my me and my workmates we build on
it for six months, a year, a couple of years,
and now it covers the whole time. Webpacks kind of
got my back and it it just kind of does
everything I needed to do. Like I have no idea
what's behind the curtains with the CLI right now. Eventually
the an your team may try and just like swap

(05:15):
that webpack for Basil. For me, what are kind of
the triggers that like I would look forward to say,
I might need to consider Basil, like I might need
to proactively look for Basil rather than just waiting for
this CLI to force it on me. Are what are
some of those triggers that you know, the everyday developer,
the every day Anula developer can be looking forward to
to to know when when it's time to start watching

(05:38):
Alex Eagles conference talks.

Speaker 3 (05:40):
Before I answer, one quick clarification, we have to be
I want to be clear that Basil doesn't replace Webpack,
like you totally run web Pack under Basil, Like I
think the mental model is a little more subtle, where
Webpack is kind of doing a couple of jobs and
we just want Basil to do one of those jobs.
Totally still makes sense to his Webpack totally possible to
like have a Webpack and fig and there are a
lot of options right for how to run your tools.

(06:01):
Webpec can still be with them. Okay, so yeah, what
are the triggers? How do you know that you need
this thing? So it's really that there are a few
of them. One is that you are operating in such
a large scale that your CI takes like an hour
and like it takes way too long to run all
of your tests, or it could be that you're running
locally and when you do a production build it takes
over fifteen minutes, and so you're like completely unproductive if

(06:23):
you need to debug something that's only that only shows
up in the proud build. Another trigger is that it's
a little more organizational. How do you interact with other
teams around you? So, if you're doing microfront ends, how
do you test that your your Angular app will work
when somebody else is either they're dynamically loading some stuff
into the same page or you have totally separate spas

(06:44):
like you actually do a server round trip between apps,
but you're passing information in like the URL parameters. How
do you test that the whole system is going to work? So,
if you want to be able to integrate your software
across multiple apps, then Basil helps with that. Also, if
you want to work more closely with your back end
team where you find a lot of defects in production

(07:04):
because you weren't able to integrate the front end back
end inside of all of your integration tests, then you
want to build system that understands the full stack, and
so you have a problem that's bigger than just Angular.
You're like, well, I have a Java back end or
have a c sharp back end, and when I make
changes there, I want to be able to verify that
the front end still works. So now you want a
build tool that understands that's, you know, a bigger is
solving a bigger problem for the entire ecosystem and not

(07:28):
just for your front end. So those are subtle, right,
I think if you think of like I just do Angular,
my team writes an Angular app. Yes, webpac has my
back today, You're fine, and you should definitely not watch
my conference talks unless you know you're just like a
build system geek.

Speaker 4 (07:41):
So, speaking of your conference talks, for anybody who is
not privileged enough to see your talk at Energy conf,
can you maybe explain a little bit more about like
what it means to be a build tool versus a
dev tool versus CI Like you mentioned it not replacing webpac.
Can you go a little bit more in depth into
explaining that.

Speaker 3 (07:56):
Yeah, thinks it's a good one. So I think for
a lot of people these things get kind of can used.
Like we sent out a survey saying what build tools
do you use today? And I got a lot of responses,
which was Jenkins. So Jenkins is a continuous integration that's
just you know, it's schedules so it like watches for
changes to your EPO, or you can have it be
like a CRON that schedules periodically and then it just

(08:16):
runs whatever you say is your build tool, so you
like it runs some program. Then later you need to,
like at the other end of the stack, you need
to do specific transformations to your code. You need to
like run the type strip compiler to convert it to JavaScript.
You need to run SAS to do your CSS pree processing.
You need to run webpack or roll up to bundle
things together into fewer files. So in the middle of

(08:38):
those two things is okay. So the build needs to happen,
like the CIS has triggered, and there are all these
different steps that I need to do, like run typescript
and run SaaS. So then I want something that I
would call a build system. You can think of it
as like orchestrating the build and that's a layer that
can be a layer in the middle that is independent
of like what's ciuus, and it's also independent of what
tools you use. And I think The reason this is

(09:00):
really confusing in JavaScript today is that we used to
have Grunt and then we had Gulp, and those were
those fit this middle of the stack. They didn't know
how to do a particular transformation. But then the sort
of replacement of of Gulp was okay, picked Webpack or
roll up or you know a different like a like
I think Cyprus has plugins for these different things. Basically,

(09:22):
you pick one workflow tool and then its job is
to have plugins to go and do all of the
individual transforms. So so basically you can think of as
being like the next in the lineage after Gulp, as
opposed to replacing a bundler or a test runner or
a depth server.

Speaker 1 (09:40):
So it doesn't replace like a bundler. And I currently
we currently we use the CLI as a bundler, right,
We use it as a generator like a Yeoman generator,
and then we use it for other tools and then
for the build step we you.

Speaker 3 (09:55):
Know, it leverages Webpack for its bundler features, right mm hmm.

Speaker 1 (10:00):
I understand that one day I may be able to
like opt into a version of the cl I that.

Speaker 3 (10:10):
It will kind of you'll.

Speaker 1 (10:12):
Kind of do all the all the things that webpac
does form already, you guys will kind of autumn you
will auto make the Basil doing that for me, like
you'll kind of you'll kind of ship it with a
bunch of predefined tasks that it knows how to do.

Speaker 3 (10:24):
Is that true? Yeah, that's right. Okay, So it's consumed.

Speaker 1 (10:29):
It's being able to say one day I'll show up
at work, I'll do an MPM install, and then my
build is actually using Basil that day.

Speaker 3 (10:37):
Yeah that's right. Okay, So Basil an NPM. So just
like you could have had Gulp in your package chase
on and you know, you run NPM build, NPM, run
serve whatever, the workflow for a developer on your team
doesn't change. So either the either the CLI does everything
for you and nobody in your team has to do anything,

(10:58):
which is sort of the end vision. We'll see if
we ever really get to a point where it's it's
a full like zero effort drop in replacement, and certainly
in the meantime some often effort required. We can talk
about what the effort is. And even there only somebody
on your team who's aware of like, like imagine this
somebody today who like is into webpack and figure what

(11:19):
they're doing, and most people on your team don't ever
touch that because it's scary and it breaks things. Yeah,
to model, like you have somebody who can who digs
a level deeper into the build, and like, yeah, so
that's the person who's changing how your build works, and
everybody else on the team should be completely unaware that
that's happening.

Speaker 1 (11:34):
So with Basil being on NPM and it it trying
to kind of be the next step of like a gun,
a gunt or a Gulp. With like Grunt and Gulp,
we had these other MPM package is, like I could
have grunt Babel or like that grunt Babel was like
a Babel, a Grunt plug in that would do Babel

(11:56):
stuff for me, right, Or I could have had I
had all all these Grunt and gold plugins that kind
of were already kind of configured to do their thing
inside of the Grunt or Gold ECOSCRP. Is Basil having
a lot of that same plugin system or is that
not really a thing?

Speaker 3 (12:11):
Or like how does that's actually totally identical, totally same
mental model. In our case, we followed what Typescript did.
So if you have some NPM package, let's say you
know banana, then you would look for at types slash
Banana would be the name of the NPM package that
gives you the typings, right yep. And then some packages
shipped like are written in typescript and so they ship

(12:33):
the typings inside of the package and so you don't
need anything. You just get the package and it's all
built in. Yeah, same models at types. So if you
had a package called Banana, you would use at basil
slash banana to get the plug in. Okay, it must
be lunchtime here. Why I'm thinking about bananas.

Speaker 4 (12:49):
My husband and I just started playing the New Jockey Klong,
so that was picking me laugh.

Speaker 3 (12:54):
Yeah, okay, so we talk about barrels too, although that's
kind of confusing, you know.

Speaker 1 (12:57):
Oh.

Speaker 3 (12:58):
And similarly, if you had a package that was with Basil,
then it could just be that it distributes Basil files
in it and you don't need any separate sidecar package.
So another way to describe this, also new back to
Manji CoV talk is Gulp, Grunt, and Basil are all
kind of this hub and spoke model where you have
one like orchestration tool and it needs one plug in
for each test runner or like transpiler, Like every one

(13:22):
of the tools in your toolbox is plugged into this orchestrator,
and so you know, so you imagine this is the
third Like if there's Gulp, Grunt, and Basil are the three,
then you have three times. However, many tools is how
many plugins needs to be written. Compare that with what's
what you have when each tool becomes a monolith and
needs to understand the whole ecosystem. Then you have an

(13:42):
M by end matrix where you have each all the
columns are all the tools in your toolbox, and all
the rows are all of the end user like workflow tools.
So like I need a Cypress typeescript plug in, and
I need a webpac type stript plug in, or I
need Cipress to run webpack. If I'm using roll Up,
then I need to roll up type script plug in.
And so you can imagine one one one column is
typescript and then for every tool that you use, there's

(14:04):
a row where you have to plug typescript into that tool.
Then you have to plug SaaS into that tool, and
so you just end up with this much bigger space
of like the plugin might not exist, like maybe there's
no like roll up, I know, like roll up and
view for example, I was recently looking at how view
is hooked up, Like there's a roll up view plug in,
but it's kind of like not supported as much as
the view plug in for webpac is. It seems like

(14:25):
you know, here, I'm not the expert ob at all,
but like the fact that you need to go through
all of the tools and fill in this box is
a problem. And then you end up depending on so
many different contributors for so many open source projects, and
like it's awesome that that open source and JavaScript in
particular is this bizarre model of like many many people
building things, but it's it's harder to get like one
tool chain that actually works end to end when there's

(14:47):
so many different things to coordinate. So I think this
is this is part of sort of this is This
doesn't make you, as a developer do anything different, but
I think as tooling authors in the ecosystem, we should
be thinking about like all of these monoliths means that
it's really hard to make a new tool because you
have to plug it into all the workflow stuff, or
it's really hard to make a new workflow thing, Like

(15:08):
if you want to make a new bundler, you have
to write plugins for every tool, and so we've kind
of gotten into a point where everything works with webpack.
That's great, Like there's something wrong with using webpack, right,
but does everything work with roll up? Well, I don't know,
maybe not everything. And then like you write a whole
new test runner, Like how are you going to do
all the transpilers for your new test runner? And so
it means that we don't have as much innovation because

(15:28):
there's such a barrier to making a new thing to
plug it into everything else in the ecosystem. So this
goes back to this Unix philosophy that like, well, it
seems like you should just be able to publish your tool,
and then it should be able to work with other
people's tools without having to like there should be a
standard sort of you know, in the case of Unix,
it's like text files with line endings. That's that's the
protocol that the different tools speak with each other. And

(15:49):
then there's they're composable and you don't have to have
a monolithic tool that understands cut and said and awk
and everything built in. I could rant about that forever.
How long do we have.

Speaker 4 (15:59):
Well, Actually, I kind of wanted to go back to
Aaron's question talking about triggers and looking at because I
feel like in the enterprise world, like a lot of
times this stuff can creep up on you like a
frog not in boiling water, but like slowly being brought
to boil water, where things just get a little bit
slower and a little bit longer as they grow. Like,
do you have any good horror stories of like people

(16:20):
that have really pushed the max or like at what
point would you go in and see something that Basil
is trying to solve and would like walk into a
code base and just start crying at the compile time?

Speaker 3 (16:29):
Yeah, frog in a boiling pod is totally the right metaphor.
I mean, I think we've probably all seen this on
our projects. Given a small project, like things kind of
get slower over time and a certain amount of effort
that you put in to keep your development process fast.
And you know, it's hard to get a big company
to fund developer infrastructure and developer productivity, and I think
it's something as developers were all trying to find like

(16:52):
some spare time or like somebody on our team who's
especially gullible, who will help to do this stuff and
like keep us all working, and yeah, that's that's that sucks. Like,
I think there are certain inflection points where you notice
that it's happening, and probably one of them is you
need to go into the CLI and like change the
max heap size for node and then and then you
have some developers who are like, oh, I don't have
sixteen gigs of RAM on my laptop, and you're like, well, okay,

(17:13):
everybody's getting a new laptop if you want to do
a production build, and so like, there are certain points
where it's especially obvious that that's happening. But yeah, I
agree that it's it's hard to basil is just is
just one of many things where we want to keep
ourselves productive, and as we scale up, it becomes hard
to do. A lot of the enterprises we talk to
are interested in mono repos right now because it's hard
to I mean, just something's going on in the industry.

(17:35):
We can talk about that as its own topic. That's
a big investment in keeping yourself productive. Like once you
start using a mono repo, it's another reflection point where
you realize, oh, if I don't have a build tool
that can that understands all the software in here? Then
how do I build all the things in this Monto repo?

Speaker 1 (17:50):
So I'm looking at Basil and like as it kind
of an experienced engineer, I hear people describe it, and
the descriptions get a little like I like, I kind
of like go oh, because people are like, hey, you
can run your build across forty cloud servers, and I'm like,

(18:11):
what what kind of what kind of build needs to
involve the cloud? Like that sounds crazy? That sounds scary
to me, that like I need to spin up some
easy two instance is just to run my a build.

Speaker 3 (18:22):
You like, it makes enerous, So like, explain the power.

Speaker 1 (18:26):
Explain where you're trying to take us, because it sounds
I realized there's some immense power. I know that your
team your build went from an hour to like seven minutes,
so I know that it's got huge potential.

Speaker 3 (18:38):
I'm just trying to understand some of the scary edges
that I hear about. I'm like, I'm not ready for that.
That sounds way too cool for like what I'm doing.
By the way, we talked about testing earlier. So Joe
Joe left the podcast because he hates that stuff. Yeah,
he's back.

Speaker 5 (18:56):
So the good thing we are not talking about testing anymore.
I don't want to talk about it.

Speaker 3 (19:00):
Yeah, I's about to answer your question with with mentions
of testing. Okay, No, go ahead, yeah, answer answer to
answer to answer my question. Okay. I feel like this
is giving me a second shot at Jennifer's earlier question
what's the elevator pitch? Because I was like, I don't
want people to use this. Okay, here's here's the vision
for how how awesome this can all be. As your
software grows and you have a big Mono repo and

(19:20):
I make a change somewhere and I want to be like,
does everything still work right? And if I have integration tests,
that's really cool because now I can be like, Okay,
if I run all the integration tests, I'm really confident
that when I ship this, like everything is like the
whole system works altogether. And as I write more integration tests,
I have more engineers on my project, and there's more,
you know, like software does nothing but grow, right, and

(19:42):
so like eventually, over time, the amount of CPU, the
amount of resources I need to do builds and test
grows and eventually we hit this limit where we say, okay,
well we're not willing to wait that long, like we
could get a big, beefy machine to do our build,
or like I can get a faster laptop and eventually
I get to a point where it does doesn't feel
fast enough, and like the obvious thing to do is okay, well,

(20:06):
you're just trying to do too much work, So don't
run all the tests every time you make a change.
Don't run the front end integration tests when you change
the back end, or you change like the data schema
that is used for the you know, the protocol that
the services in the front end are using to talk
to the back end. Like nobody's got resources to run
all those tests, like why even try? And so then
we end up with every team is on their own

(20:26):
little island and they're running a continuous build, which they
call continuous integration, but they're not integrating their software with
the other teams, so it's not really integration anymore. I
think we've kind of gotten in this false mindset where
we're doing CI, but everybody does their own little CI
for their own peace of the world, and it's only
later when we go to ship that like hopefully during like,
you know, we have some period when we're doing manual

(20:48):
testing and we discover bugs or else they go to
production and then we're like, oh, like the version X
of this thing didn't work with the version why of
that thing, like you know, and we're like, oh, well,
could we have written an integration test for that? If
you think in a post mortem sense, like what could
we have done? Well, we could write a whole bunch
of integration tests across the whole stack and run them
every time I make a change, and then you're back
to like, Okay, well now our build is way too slow.
So really the vision is like I want both. I

(21:09):
want to be able to like, every time I make
a change, I want to be like, yeah, test might change,
and pretty quickly from like most kinds of changes, I
should get feedback that says everything in the whole system
still works, Like you can ship to PROD and there
won't be any integration failures between back and on the
front end, or between different micro front ends, or like
however you divide up your work. So okay, so let's
let's still go into that a little bit. So okay,

(21:29):
so I just said I want to rerun all the
tests when it made a little change. So first of all,
I don't want to actually re execute all the tests. First,
I want there to be something you can kind of imagine.
It's like change detection and Angular like something was changed,
and now I need to re render the view, and
I don't want to like recreate all the dom And
this is getting into too much you know, tech detail,
But like, this is what Anglo does under the covers,

(21:50):
is it does this algorithm to figure out, okay, based
on what just changed, what could do I need to render?
And what we're talking about in the build system is
totally equivalent. Based on the source code file you just changed,
what tests possibly need to be rerun. So one of
the things we have, one of the things Basil needs
in order to solve our problems is it has to
understand this dependency graph. And so you know, we can

(22:10):
talk about how it understands that dependency graph. But assuming
it knows the graph, then it can figure out, okay,
these are the only things that are possibly need to
be rerun. The second thing is it could say, okay,
so now something needs to be rerun, but let me
look at all of the inputs for each step in
the build and if the inputs haven't changed, Basil assumes
that it doesn't need to rerun that thing. And so
there are a lot of there's there's a lot of

(22:30):
cases where you know, you change a comment and then
downstream in your JavaScript you've stripped all the comments. Let's say,
so then the inputs to the test are not changed
because you change this comment, and so the test doesn't
need to rerun. And this is incrementality. And so Basil
has like really good incrementality properties of only needs to
rerun certain things, and it can assume, based on the
inputs exactly what work needs to happen. Right, that's a

(22:52):
good fancy word too, incrementality. Yeah, incremental. I mean we
all kind of know that, Like I made this little change.
I don't want to rerun all integration tests in the
world except the one invasion test that actually would have
caught the problem I just introduced.

Speaker 1 (23:04):
Right.

Speaker 2 (23:05):
Yeah, I don't know if this as cool as transclusion,
but it's pretty cool.

Speaker 3 (23:09):
Yeah, there's no transclusion in Basil. Don't worry. Okay, Okay,
So now so there's two more steps along this journey. Okay,
so now something does need to rerun, right, One of
my inputs, one of my job script files is different,
and so the test needs to execute. But it turns
out my coworker already ran the same build and they
had the same change. Or maybe the CI already ran
and it had the same change. Maybe I like pushed

(23:30):
to commit and so the you know, he was doing
a pre submit run on my CI. So if anybody,
if one of my coworkers or my CI has already
done this exact build with exactly the same inputs, then
Basil can use a cash and so now I can
cash the build artifacts, the intermediate build artifacts, right like
the steps in between typescript and webpac. Let's say this

(23:50):
can be cashed, so I don't need to rerun that
step if anybody else has already run it with identical inputs.
So that's cool. It means even like if my CI
is up to date and I and I sink to
and I rerun the build, I should mostly be getting
cash hits and so I can have incrementality even in
a case where you would imagine you'd normally get a
really cold build. So that's that's step two of the pitch.
So step three is Okay, I change something and I

(24:12):
don't get cash hits, Like I just like updated the
version of Angular in my project, and so everything is
affected by that. Right, you look at the dependency graph
and you're like, okay, all my components, all my nGy modules,
like everything depends on the version of Angular. And I
didn't have this on CI yet. So now I actually
do have a bunch of work to do. Like I
have to do the big build, I have to run
all the integration tests. I don't have enough comput on

(24:33):
my laptop to do that. So this is where I
want to just throw a bunch of CPUs at this problem.
And so Basil, since it understands all of the inputs
for each step that needs to run, it can just
upload those inputs somewhere else where there's enough available CPU,
and it can farm out the build so it can paralyze.
If there's twenty things that could be happening in parail,
I can get twenty machines to do those things. And
so not only am I not constrained anymore by like

(24:56):
you know, in Node, it's hard to even use all
the CPUs on your machine because JavaScript is single thread
and like single process. I should say, although Node now
has this worker threads API. That's pretty new, and so
like you can kind of farm out things to the
rest of the CPUs on your machine. But like what
we really want is I just want to throw like
one hundred and fifty CPUs at it. And so now
we finally get back to what Frosty said earlier, Like, yeah,

(25:16):
on Angular, when we threw one hundred fifty machines at
our CI, it went down like eighty seven percent, right,
It went from sixty minutes to seven and a half
or something because because we were willing to like throw
machines at it, right, and cloud is getting cheap for
all the time and buying laptops for all your engineers
can't possibly scale to what the cloud can do.

Speaker 5 (25:35):
You're saying that the key there is that determination.

Speaker 2 (25:37):
It's not so much that it inherently increases the speed,
but it lets to you either decide one only rerun
a small set of the tests that need to be run, right,
or make the determination a large set of testing to
be run. So does that mean that it's possible to
decide somehow the computer gets to decide. You know, the
system is somewhere Basil is deciding, hey, I only need

(26:00):
to run a small set, I can run those locally,
versus I need to run a longer set.

Speaker 5 (26:04):
I'm going to send those up. Is there like some
criteria there?

Speaker 3 (26:06):
Is it?

Speaker 2 (26:06):
More like, hey, because it knows and it kicks off,
you know, some eighty seven minute process on my machine
versus normally it's kicking off a thirty second process.

Speaker 5 (26:14):
And somehow I did.

Speaker 2 (26:15):
The magic change that cascaded across so many pieces that
we have to rerun the whole entire thing.

Speaker 5 (26:21):
Is that what we're talking about here?

Speaker 3 (26:22):
Or yeah, So what you're getting at is that once
we decide we have to do one of the steps
in the build.

Speaker 5 (26:29):
And when you say we decide, whose weed the basil?

Speaker 4 (26:32):
Right?

Speaker 3 (26:32):
Right, Yes, you've may changes to your inputs, and so
some number of the build steps needs to be rerun.
Excuting tests and tests are great to paralyze like some
depend on each other, right, so.

Speaker 5 (26:43):
Right, if they do that, you and I need to
have a talk.

Speaker 3 (26:47):
Yeah, exactly. So if the test needs to be rerun,
then then yeah, Basil can decide should I schedule it locally?
Do I have plenty of CPUs locally? Do I need
to run it remote? And yeah, it depends on sort
of the width of the graph. There's a lot of
things to paralyze, then it's worth it to take the
extra latency hit of uploading my inputs to the cloud
and then downloading the resulting build artifact. Whereas if my

(27:10):
if I'm if I'm doing an incremental build, then my
local my local resources are sufficient for the build steps
from running. And so yeah, Basil will like just paralyze
the work over your local CPUs. And one thing I
really like about Basil is that that scheduling algorithm is
totally independent of how you express your build and how
the build executes. Right, so bezel is making new releases
like in in the release that just came out this week,

(27:32):
it automatically tries to keep compilers warm, and so like
the typescript compiler, we can keep it running and so
we don't have to pay the cost of like a
new node process. It's the same thing as TSC dash watch,
like you run compiler running in a watch mode. And
so Basil is able to do things like that too.
To assuming that you're that you've that your Basil plug
in for the compiler knows how to keep the compiler running,

(27:54):
then Basil schedule like, okay, well, I'll just keep four
copies of the compiler alive so that I have much
less latency when I send it work to get to
kick off the type trip. So yeah, this is this
is totally inside stuff. Like as a user you don't care,
but Basil can be smarter about the heuristics for where
to do the build to handle this trade off between
do I have enough resources and what's the latency of

(28:17):
using a farm of remote build workers.

Speaker 2 (28:20):
That sounds like the kind of magic that turns into
a disaster when you try to, Like I hear people
talking about I've heard before people talking about some kind
of thing that's like, hey, we can make this happen
like this, and then when you go to do the details,
you realize, oh my gosh, this is like five times
more complex and ridiculous, and I can't get this configure

(28:42):
correctly because I'm.

Speaker 5 (28:43):
Just trying to think through the process of it.

Speaker 2 (28:45):
Makes a decision that you've changed enough inputs that your
local you know one, understanding your local machine and the
power that it has available, right, and then to understanding
how to send that up to your CI system in
the cloud and say no, no, kick this off on the cloud. Then,
you know, like I understand the process of what it's
like when I'm on the developer and I'm on my
box and I've got a set of CI tests and

(29:06):
i go change something and those tests need to rerun.
Sometimes those tests take forever, and sometimes they don't. And
if Basil incrementally says, hey, I don't need to run
all the testimony, run the small set, then who thank goodness,
this test round is only taking me twenty seconds, whereas
if I have to run the whole test run, it
takes me ninety minutes.

Speaker 5 (29:25):
Right. But the minute that you make the decision of oh.

Speaker 2 (29:28):
My gosh, you know, or analyzing what's on the machine
and saying this has to go somewhere else, and I think,
oh my gosh, that either a set.

Speaker 5 (29:35):
It's either crazy magic or snake oil.

Speaker 2 (29:41):
So from you, it sounds like my opinion is it's
got to be magic, right because I know you.

Speaker 5 (29:48):
But that's it's just it just sounds amazingly whacked. That's
the best. The best word that's whacked.

Speaker 3 (29:57):
Let me offer an existence proof that somebody does it
this way, which is, you know, we haven't pointed out
yet on this podcast, but like we always say this
at every enjin com. Google does it this way, right,
This is how we develop the biggest apps at Google.
It's by having thousands of machines. And I used to
be the tech league for our continuous build system and
at that time it was like tens of thousands machines.
I don't know what it is now. I'm probably not

(30:18):
even supposed to say if I did know, but like
lots of like resources and production data set. You say
that number, say it, I would be guessing. So maybe
it's fine for me to guess it's got to be
like over one hundred k machine. But you know, I
mean you divide that by how many engineers work at Google.
So like, yeah, you have a few machines per person. Basically,
like we bought you a laptop and we have like,
you know, three machines in the data center to your builds.

(30:40):
That's reasonable, right, So yeah, so like we we do
this and yeah, it's it's there's a lot of complexity
and making me work and so yeah, it sounds kind
of scary, like how do you decide to run local
or remote? So first of all, this is not something
users care about. Right. The user does is say like
I have a director. You have typescript files here, that's
all you say, tobout and you say, oh, and it
depends on this other directory over there. And I know

(31:01):
Aaron's asked about this the pendency graph thing. As a user,
like as long as Basils dependency graph, it knows what
to do. Right As an author, when I wrote, when
we write the typescript compiler plug in for Basil, there's
a couple of things we have to do, but it's
basically we have to be careful that the only things
we need are the things that we told Basil we're
going to use, and that we don't rely on like
local paths on the disc, because the thing could run

(31:23):
somewhere else. So when you're writing one of these things,
you have to put some basic rules about being hermetic,
meaning like you only depend on the things you declared right, right,
and so then like when Basil lays out your thing
on some other machine, it's like in some different directory,
but your your typescript can figure, your ts can fig
file is there on disc, and all your typescript inputs
are there on disc, and your DTS files are there
on disc. Run the typescript compiler. You tell basil where

(31:45):
the outputs go and then it downloads them back. So
as as a plugin author, you have to declare all
the inputs, declare all the outputs, and be and be
hermetic about how you operate. And you also should be deterministic.
You should make sure given the same inputs, I produce
the same output so that the casting can work, right,
because you don't want to like pollute the cast because
then you'll cause a bunch of rebuilds that shouldn't happen. Right.

Speaker 2 (32:06):
So, one of the things that I think is universally
true is if it's a good idea for Facebook or
Google to do something in every company in the world
to do something that's universal, that's universally too, right.

Speaker 3 (32:18):
Yeah, it's universal. You just made a fact.

Speaker 5 (32:21):
I did. I'm pretty sure I stated I or made
a fact. You're right, I made a fact. I made it.
That's that's the fact I made, folks. Yeah, right.

Speaker 2 (32:30):
So when I see what Facebook is doing with their development,
obviously that's what every company in the world needs to
do for their development. When I see that Google's using basil, like,
I'm going to start up right now. We have a
quarter time developer, literally twenty hours a month.

Speaker 5 (32:43):
That's what we have for development.

Speaker 2 (32:45):
So I should be turning him onto getting him that's
his next project to implementing BASIL.

Speaker 5 (32:50):
Right, you do it it that?

Speaker 3 (32:53):
That doesn't That does not sound right. I'm pretty sure
you want that person to develop code that's useful for you. Yeah,
there's there's a scale question. I think the only startups
I see who are who get started with this sort
of scalable build infrastructure are ones where somebody left Google
or Facebook and is like, oh, I just want to
have the same thing I'm used to from day one
and like set that up right. So somebody who just

(33:14):
has that proclivity or like they have the experience doing it,
and they're like, hey, on the team, I just quit
Google and so like here's Baseil. Like you're welcome.

Speaker 2 (33:21):
We talked earlier on about like criteria things you should
look for, and you said a really long build time
was like the number one criteria you should look forward to.

Speaker 5 (33:29):
Say, hey, it's time.

Speaker 2 (33:30):
So you're at a company, your build time is obviously
maybe something at least north of twenty minutes. Right, your
sei time is at least north of twenty minutes, maybe
more running on a single machine, that's time to start thinking.
What about another criteria I think is still useful, Like
I could be a solo developer and end up with
a sixty minute I'm having a tough time imagining actually

(33:52):
getting to that point, but I think it's possible that
there's a there's some place where there's a solo developer
with a sixty minute SEI time. Right, if your solo
developer is that kind of that characteria, like, eh, you
probably don't want to spend the resources it's going to
take implement or is it gonna is that like ROI
gonna be pretty reasonable that even if you're solo and
you've got to do all the basil implementation work yourself.

Speaker 1 (34:13):
It sounds like I'm gonna I'm gonna guess. I'm guessing.
It sounds like because it's like functional and if the
input's the same it doesn't rerun that step, it could
still be massively time savings for one person.

Speaker 3 (34:27):
Still, I think the answer is, yes, there are cases
where a solo developer would want it, But I don't
think it's for build time. I think I thinks always right, like,
it's hard to imagine like writing enough code that it
takes an hour to execute, like your building test as
a single like you need you need millions of lines
of code, right.

Speaker 2 (34:43):
I was imagining somebody who's super into end tests and
just like what nuts about it? Right, Like I'm writing
an end I'm like doing BDD I writing end to
end tests for every piece of functionality, right, and I
end up with a thousand end to end tests on
my twenty thousand lines of code.

Speaker 3 (34:59):
Right yeah, I mean even there, like you're you should
find your picture come up faster, even if it's a
separate topic.

Speaker 5 (35:06):
Right.

Speaker 3 (35:07):
No, But so like I'm just thinking to answer the question,
like if I was doing a small project when I
start with basil, and I do actually, and there are
a couple of reasons. One is that I can do
full stack. I can like everything, like you know, I'm
not just writing an angular front end unless I'm like
you know, using somebody's API, Like I'm just talking to
get a API or something, right, And it's just like
a pure front end project, so I need to like
I'm building more than just types strip code. The other

(35:29):
reason is that the way you put your bill together
is is but I can like drop in like oh
I need one of these, any one of those like
I'm gonna have a type strip library that's an input
to a bundler step you express. The configuration is just
really ergonomic, and so if you've already, like if you've
learned Basil already, then it takes it it's a lot
less time to set up your your your tool chain

(35:51):
and like keep it up to date. Basically, I don't
know that that's the reason that you would that you
would want to spend the time to learn Basil necessarily,
Like you know, you can probably get other options off
the shelf, and I guess it kind of depends on
how custom your build is. Like if you're if you're
if Ango Cli doesn't exactly what you need, then you're
done right. And if somebody else's tool chain does exactly
what you need, that's fine. I think it's it's really

(36:13):
you know, at Google, every build is a snowflake and
everybody needs to customize what it does. And if we said,
even the Anglo Cli internally at Google, we mostly use
it for scaffolding files and then people edit the build
configurations by hand. It's not the same way it does. External.

Speaker 2 (36:27):
Are the build snowflakes because they're beautiful or because they're delicate,
or because if there's a there's enough of them you
get buried under them and you you drown and suffocate.

Speaker 3 (36:36):
I think it's because that each one is different. I
think that's why say snowflake. But I think your other
analogies are actually pretty good too.

Speaker 4 (36:42):
I think we have a new talk title, so.

Speaker 5 (36:46):
That is that would be an awesome talk title, wouldn't it, Uh, Alex, I.

Speaker 3 (36:50):
Got a question.

Speaker 1 (36:51):
So the A team they go through this big effort,
they reduce their build internally at Google from sixty minutes
to seven right, right, how does that positively affect your team? Like,
I don't I don't know how it was negative? Fucking
you can you kind of spell out to some people
this is how we benefited from that type of a
savings because some people might have a hard time understanding.

(37:14):
I don't care if it takes an hour or eight minutes.

Speaker 3 (37:17):
So the first one is nothing is worse than you
push a PR and then like you get in the
car and you're like, oh, like oh sorry, you push
a PR and you're around for a few minutes and
you're like okay, like it's running, that's cool. And then
you leave and you switch context and then like an
hour later it was read because of some dumb tests
that you could have Like you could have fixed that
in the same loop, right, So like losing a development
round trip, or you're sitting there in your machine and

(37:38):
you're like, this has to be green. It has to
merge before I get home. Let me sit here for
an extra hour and wait to see if it's green. Yep.
That's only for the Angular team. Like, you know, we're
working lots of things at once, and so we're pushing snapshots,
you know, we're pushing commits to our prs, and like
like a faster round trip just allows you to do
things in real time that you would otherwise have to
like you know, context switch out in it. So there's

(37:58):
a real productivity boost. The other thing is Igor has
claimed Igor is the illustrious leader of Angular. He's he's
His feeling is that by introducing Basil, we're now like
getting a jillion more prs through the project. And so
really it was like scaling up our ability to pump
changes through this thing. And Angler itself is like a
big mono repo. It's a pretty good example. If you

(38:19):
send us a pr and you watch, like you know,
angler uses circle CI. But then you look at the
circle CI jobs and like a giant, a bunch of
them spin up, and then the Basil one spins up,
and there's like there's a lot of testing to do
when you make a change, and we really want to
get that feedback on a PR. So the other thing
for us is that we know when we merge things
that all of our integration tests are passing for everybody's PR,

(38:41):
for every commit that we push to a PR. And
if we weren't using Basil, I think we wouldn't be
able to keep up on our CI anymore. And then
we would be making the trade off I described earlier
where we'd be like, well, we'll run the test in
the directory that you change, and then like sometime later
we'll find out whether anything still works. And then and
then like I don't know how we would ever ship Angular,
Like we released song Green, it's like we really like
our CI is trustworthy and we run it all the time.

(39:03):
There's something I want to make sure I say it
before we get know other questions because I noticed like
Aaron's question in our in our chat here about like
how do you create this all these cloud servers? What
does it look like when we actually opted into RB,
we flipped a setting in Basel, so we said like
dashed Aashknfig Eagles remote and then we signed up for
a service that is on Google Cloud called Remote Build Execution.

(39:26):
And so I'm actually partnering a lot with that team
as they're onboarding. They started onboarding some Angular enterprises already
they manage this whole sm of machines for you, so
and they do all the elasticity of making sure you're
not being builed when you're not doing builds and like yeah,
so you're you're not going on Amazon EAC too, and
like provisioning like you know, your own Kubernetes cluster of

(39:47):
build workers, Like no, you just you just turn on
a flag and you give Google Cloud your credit card,
so like you can run one of these on premises,
Like there are open source versions of it, but I
think for most people it's just it's way more effective
to just use a cloud service that already does it.

Speaker 1 (40:00):
I don't have to learn Kubernetes and docer in order
to use Basil, Like that's that's my goodsert of like
gat day.

Speaker 3 (40:06):
You should learn those so you can be friends with
Dan wellyn and you get more jobs that way. There's
lots of Kubernetes and docer are awesome, and they actually
do have tie ins with Basil that you know, if
that's your thing, Like we can discuss how those how
that kind of deployment and that kind of target environment.
You can do those builds under Basil too. But no, like,
we have a service that does this. Everybody should check

(40:26):
out if you go to Basil dot Angular dot io,
which I guess we should put in the show notes,
like this is the one place to go. The first
thing under resources is a link to this remote build
execution service.

Speaker 1 (40:37):
Okay, So I'm currently we're going with a team where
there's thirty developers and I'm trying to understand the words
you're saying and apply it to the.

Speaker 3 (40:46):
Like this team.

Speaker 1 (40:47):
Just yeah, I do this anytime I'm listening to podcasts
and I'm listening to you, Like, all right, how does
this apply to me? So, like, let's say I'm on
the team with these thirty with these thirty folks and
uh person, like way over in their stead room they
changed some file right and that and that, So do
I run this at debt time? And then that puts

(41:08):
like pushes like the I can't remember what you called it,
the output, the the.

Speaker 3 (41:13):
Intermediate build artifact, Yeah, the.

Speaker 1 (41:15):
Builder, the I b A. It pushes the IVA out
to some like team build process that Google provision for
me because I use the link you just told us
to go to, and then next time I make a commit,
it doesn't have to do that step because it did
that step when he when that person started he or
she when they did it, it did it. Then.

Speaker 3 (41:36):
So my builds faster because am I understanding it?

Speaker 1 (41:39):
Right?

Speaker 3 (41:40):
Like my my current builds faster.

Speaker 1 (41:41):
Because when they made the change on their machine, that
IBA got pushed out at that time, and then all
builds that need that in the future are faster.

Speaker 3 (41:50):
Explained to understand it, Yes, that that is correct. You
kind of those build artifacts with your co workers so
you don't have to redo work that's identical to the work
they already did. So if there's thirty of us and
we're all sharing the same and.

Speaker 1 (42:03):
I'm not even like building, I'm just doing like I'm
in dev mode, it's not even pushed out to a server.
I can my reloads really be like instant just because
we're all sharing the same IVAS, like is that kind
of what we're talking about.

Speaker 3 (42:16):
Yeah, I mean the the the important use case to
think about is like you come in the morning and
you do your first like you know, energy serve, Like
after you sync to heead have to compile all the
typeescript and run all this ass and like you know,
like twitting and whatever else is in the in the
critical path to bring your local server up, and all

(42:36):
those steps should be cashion. It's because it's like somebody
already did it before you got in, or the CI
already did it.

Speaker 1 (42:41):
And basic will just be like, oh wait, I'm just
I'm just using the uh the thing in the in
the remote build server thing that you guys all share now.

Speaker 3 (42:52):
Yeah, I mean the simple thing. Actually, you can set
up a cash in your office and it's just a
WebDAV server. So like forget about the road execution part.
Let's say you're like execution always happens here on your
laptop because this is much simpler to set up just
web deft server with like a you know, like a
fast solid state disc or something, and like you all
point to it and yeah, now you can share those
you can share build artifacts with your coworkers.

Speaker 1 (43:13):
So I'm going to come back to a different question
that Joe asked earlier, because it sounds like maybe the
answers even if my bill doesn't take an hour, it
still sounds really beneficial because with the CLI, I've seen
times where or just with Webpack in general, I've seen
times where I make one file change and it's like
twenty seconds to recompile and refresh.

Speaker 3 (43:33):
My page to make sure nothing broke right.

Speaker 1 (43:35):
It sounds like le Basolo, it would be like most
of that the input's the same, so I don't need
to recompile, Like is that just.

Speaker 3 (43:43):
This is where like so for this example, like my
webpack was slow to come up, Well, first of all,
the webpac team is already working on this, and like
Webpac five is going to have an on disc pash
so that when you restart the webpack dev server, you're
not you don't get a cold boot. So so like yeah,
I mean like everybody in the ecosystem is working on
solving the same problems. It's not like Basil has the

(44:04):
only solution to these problems. So like one answer is well, yeah,
I mean like when like webpac is going to improve
and like you're not going to wait for cold starts
as much. The next part of the answer is okay,
So let's say, like we do think like webpac is
doing more work than it should need to do. We
have to break it down a little bit and like
profile webpack and say, okay, is the slow step, Like
in the worst case, the slow step is read the

(44:25):
graph of all of my import statements in my code
and figure out where to do the code splitting and
how to like make the chunks and if I have
the common chunks plug in, then like calculate which chunks
are in common between between two routes. Let's say, if
I'm doing route based code splitting, that's a global program analysis.
Like you change any file you might have, you know,
some common chunk that now includes something it didn't before.
And if that's the slow step, Basil doesn't just make

(44:47):
that magically faster, because a global program analysis still needs
to be run and it's going to take the same
amount of time. Like Basil just knows how to run processes,
like it just spawns processes. So it's really the question
is that you have to, like if you could see
the graph of what's happening inside of webpac, if you
could see like the type trip compile separate from calculating
the chunks, then you would know, Okay, like if I'm

(45:07):
spending time in something that could be incremental or parallelizable
versus I'm spending time in something that like is going
to be the same no matter who runs it.

Speaker 4 (45:14):
Okay. So I always like to hear about the why
behind tools and the kind of problem you're solving. Have
you had any just spectacular horror stories that you feel
like Basils really going to step up to the plate
and solve, like any just ridiculous build times that you
can't even imagine happened.

Speaker 3 (45:30):
I mean, I live in the A in a special bubble,
like you know, internally at Google, we've had Basil since
I started, and like you know, on the Angular project, yeah,
like we had we had builds that the tickle on time.
We've been using Basil for two years. I think, like
I think Angular six was shipped, like was built by Basil,

(45:52):
and then we pushed a ten PM from there.

Speaker 1 (45:53):
It is don't name names, but tell us your horror story.
Give us the horror story. Don't name names matters here,
but give us the horror story. I like Jen's question.

Speaker 3 (46:04):
I would love to tell you a great horror story.
I'm trying to think of one.

Speaker 4 (46:07):
I mean, you don't get like people complaining on give
it Hub being like oh my gosh, my buildtime was this,
and you're like okay, well, or you just like blinders,
don't don't pay attention. No.

Speaker 3 (46:16):
I mean I've talked to some some Angular customers and
they tell me like their overall build time is like
you know, we wait ninety minutes to you know, like
build the whole thing, or like you know how much
ram that needs to go into their build. And I think, yeah,
there are some extreme cases like that that sound totally crazy. Here,
let me let me tell you this horror story. It's
not the one you're looking for. Oh imagine. So, so

(46:38):
Google has this mono repo, and the mono repo means
like everything is compiled from source. Right, So if you
want to build your Angular app, you first have to
build Angular. You want to build Angular, you first have
to build the type strip compiler, and like goes all
the way down. Okay, So here's the horror story. Googler
comes in on their first day and is like oh okay,
mg knew and then like, let's build the app. And
it says like compiling clang, right, you're come piling the

(47:00):
C plus plus tool and you're like, oh my god,
and like because like you're like, oh my god, Like
I think we compile node from source in the Mono repo, right,
like we have the sources for node, and obviously, like
in order to compile typescript first you need node. In
order to get node, you first have to compile it.
So the horror story is, yeah, we actually built everything
from head but like, thank goodness there's remote cashing because

(47:22):
like there's no way anybody would ever do one of
these builds, right, yeah, that would be horrible. Yeah, my
horror story was really more like yet another sales project
I'm working on.

Speaker 1 (47:30):
Sorry, yeah there was also another like a Google's really awesome.

Speaker 3 (47:35):
I mean there are times that that's handy, right, So
like we can like bring in a node, a new
like node binary and then test everything and see what breaks,
because it's all yeah, that's cool.

Speaker 1 (47:45):
All right, Well, uh thanks for letting us grill you
with questions. I learned a life like other life, Like
I'm more well prepared than I was before the podcast
to kind of work with these things. So there's many
people with questions and they might want to reach out
to you.

Speaker 3 (48:00):
How do people get ahold of you?

Speaker 1 (48:01):
What's like, what's the best way what would you prefer
the community to reach out to you at?

Speaker 3 (48:04):
So you can start from basil, dot angle, dot io
and you know, read through the resources there we have,
you know, like obviously, like I don't have enough time
to answer you know, hundreds of questions a day, so like, yeah,
get her, I don't. I don't actually follow get her.
There's a slack for basil, so you start using it.
You can you can go search for basil slack Joe

(48:25):
Joe another slack bro.

Speaker 5 (48:26):
I'm excited. I'm definitely joining up.

Speaker 3 (48:31):
Memory. You can commit to a chat. It's good.

Speaker 2 (48:34):
I'm my goal is to get to an into one
hundred Slack organizations.

Speaker 4 (48:38):
Are you being sarcastic? Do you want to.

Speaker 3 (48:43):
Memory that he has to run slack from a cloud.

Speaker 5 (48:47):
Actually use basil just for slack though, and every time
there's a.

Speaker 2 (48:53):
Message that has to go through and figure out all right,
based on.

Speaker 5 (48:56):
This message, how many instances do we need?

Speaker 4 (49:00):
Okay, maybe that's like Basil's new pitch. Though you don't
have to close Slack to run it.

Speaker 1 (49:04):
Yeah, Basil build your Angular app and chat.

Speaker 4 (49:12):
Literally you need to hire us to be the new
marketing team.

Speaker 3 (49:17):
Well no, now I'm just thinking about like, hey, like,
what are the Basil rules look like for building an
electron app, because so I could actually build slack itself.
But that's funny. There's also DevRel at angular dot io,
so then you can send questions over to I assume
most people listening to Minko getchev. He's he's their community,
and he's he's he's on our team now, and he's
he's working. He's he's the DevRel contact for Basil. He

(49:40):
answers a lot of stuff. Too cool. We're gonna move
on to the pick section.

Speaker 1 (49:45):
I had to pick. I'm trying to camera my pic.
I may go pickless and the A'm going pickless. Oh wait, no, no,
no pick here. It is acts throwing. You have to
grow a beard to do it, so that's the one downside.
You don't have to grow a beard. You rent an
axe and they they rent you a wooden wall to
throw it at.

Speaker 3 (50:05):
It's pretty amazing acts starring.

Speaker 1 (50:07):
If you've never done it, it doesn't really feel very
it doesn't sound very social to me. It doesn't feel
like inherently a great date activity.

Speaker 3 (50:16):
I love it. It felt like it was a really
fun date activity.

Speaker 1 (50:19):
It's real, it's real fun to hang out with your
friends too, So it's it's it's it's kind of an
all activity anyway, just saying.

Speaker 4 (50:24):
Did you never play darts at the bar?

Speaker 1 (50:27):
Yeah?

Speaker 3 (50:27):
I mean I've never murdered anyone with a dart though, Well.

Speaker 4 (50:30):
I mean, wait, who do you murder with an ax?

Speaker 1 (50:33):
I've never heard of anyone murdering I meant, I've never
heard of anyone murdering people with darts, That is what
I meant.

Speaker 3 (50:39):
So access brutal, man access brutal.

Speaker 1 (50:42):
So so yeah, acts throwing, that's my pick, Jennifer, you
want to go next on the picks?

Speaker 4 (50:49):
Oh gosh, my pick is such trash so scandalous. News
broke out in Bachelor Nation yesterday from Reality See with
one of the contestants having a girlfriend and back home
the whole time. So I've just been like deep down
the Reddit rabbit hole of all the spoilers happening from
the season. It's great.

Speaker 3 (51:07):
So is your your pickage is the bachelor or.

Speaker 2 (51:11):
Is it having your girl friend at home while you
compete on a dating show, which I'm.

Speaker 4 (51:16):
Okay, basically all the drama coming off season.

Speaker 5 (51:20):
Basic pick is drama, pick is Reality TV.

Speaker 3 (51:24):
Channel is from Reality TV.

Speaker 4 (51:27):
And I'm really excited because in case you see, I'm
giving a pub con talk if choosing a jobascrit primework
well as like an episode of The Bachelorette, and I'm
doing it on the season of the Bachelorette, So I've
got primo material to work with.

Speaker 1 (51:39):
Yeah, it was almost like it was serendipitously planned for you.

Speaker 2 (51:42):
That's good, Joe, you have a you have a have
got two picks. Actually, my first pick is soccer.

Speaker 5 (51:51):
Okay, right now? The World Cup? Yeah, yeah, surprising.

Speaker 2 (51:59):
Looking into the history of the word soccer is a
very interesting thing to do, by the way, But soccer
is awesome right now. Football for the outside of the
US right now it's going on and the Women's World Cup.
And what's particularly great about that is the US dominates
in women's world soccer. We are, you know, a clear, clear,

(52:19):
clearly dominant force. They just trashed Thailand thirteen to nothing.
Thailand was great competitors, by the way, but yeah, thirteen
to nothing of biggest thirteen thirteen, the biggest score and
biggest gap and biggest set out ever in World Cup
history and the history of the of.

Speaker 5 (52:38):
The human race ever since cavemen started bashing.

Speaker 4 (52:42):
How do you feel about the pushback against the team
for dominating that badly instead.

Speaker 2 (52:46):
Of like, well, you can only sub three times, So
that's one reason, and they did use all three steps.
But to answer Jennifer's question, some of the responses that
I heard I thought were really particularly on point.

Speaker 5 (52:59):
One of the responses is, this is the men who
we having this conversation.

Speaker 2 (53:02):
I'm not sure that's true or not, because this has
never happened with the men, because the men are, you know,
not that good, right, Like the women are awesome and
the men are pretty down, you.

Speaker 5 (53:13):
Know, at the bottom of the barrel.

Speaker 2 (53:15):
Being thirtieth or fortieth in the world is kind of
like being last. So one we can't know that, we
can't know if this would happen, if this happened, like
the biggest We had an eight to one with Brazil
and Germany last World Cup and like a ton of
people lost their jobs, but that's nothing compared to thirteen

(53:36):
to nothing. The second thing that somebody said, which was
then maybe this will be a wake up call to
countries around the world to spend more time and energy
but on their women's soccer programs. Really dig that one, right,
And I do believe in fairness and not running up
the score in the non competitive levels. But when you
hit a certain level, I personally am saying, hey, women

(54:00):
deserve to prove how great they are. They absolutely deserve
to prove how great they are, and the rest of
the world should understand how dominant this particular team at
this particular time is.

Speaker 1 (54:09):
Oh, Joe, you're you're comfortable with Michael, Jordan and Kobe
winning all those championships too? Then well, wait a second,
we're talking about and is not scored.

Speaker 2 (54:21):
Come on, we're talking about a different mechanic here. That's
the I'm I'm like stacking a particular team within a.

Speaker 5 (54:28):
Market, right, I agree with you.

Speaker 3 (54:30):
I agree.

Speaker 2 (54:31):
I don't believe LA should ever be allowed to play
in any professional sport ever. Again, like there should not
be they Ell should not be able to field professional
sports from now on until his the end of time.

Speaker 5 (54:43):
But that's a different matter. That's speaking from a small market.
Second second pick.

Speaker 2 (54:48):
Second pick is playing dudges of dragons with Aaron Frost,
not just I picked Dudges of Dragons before, but I'm
going to pick playing Dudges of Dragons with Aaron Frost.
We've had such amazing times and such hlarious stuff, and
playing without him there's about a folk you guys have
to play without Aaron and it's been fun. But he
just he adds a really fun element. Aaron is just

(55:09):
a really great guy to do it.

Speaker 5 (55:10):
Just about anything with.

Speaker 2 (55:11):
But I will say Dungeons and Dragons. I've seen something
happen at our table that you could not possibly script right,
Like a writer couldn't come up with nothing that acquisitions incorporated.
What are the big ones? The Adventure Zone and what's
the other one? The other big D and D all
the voice actors and they have the video show?

Speaker 3 (55:31):
What is that?

Speaker 4 (55:32):
No?

Speaker 2 (55:33):
No, oh my gosh, I can't believe. I'm like embarrassed
to not know this, But everybody else is. Everybody's listening
to this.

Speaker 5 (55:38):
It's it all in the D and D is gonna
be like, dude, is this and whatever it is?

Speaker 2 (55:43):
None of them have done anything as amazing as what
has happened at our table.

Speaker 5 (55:46):
I can guarantee it. I will put money on it.

Speaker 2 (55:49):
You can't pick something that was as awesome and as
funny as what happened to us at the end of
our last adventure.

Speaker 6 (55:55):
So yeah, So, Jennifer, just to kind of give you insight,
I created the I created a character who's the oblivious
male in the room and he.

Speaker 1 (56:07):
Does some of the stupidest stuff because he's ignorant to
like norms and stuff.

Speaker 3 (56:13):
And he's so fun to play. It's it's so ridiculous.
I get to make up a story.

Speaker 1 (56:20):
About what I think the dumb all all man is
and he's it's just the funnest character. So yeah, anyway,
thanks Joe. All Right, Alex, do you have any picks?

Speaker 3 (56:34):
Yeah, I can give you a pick. Do you think
anybody's still listening at this point? Like soccer? I guess
so I talk.

Speaker 1 (56:41):
About testing and soccer, So if they're still here, they're
real fans.

Speaker 3 (56:44):
Yeah, Jordan benningson amazing like rookie goalie only played half
a season, wins wins the Stanley Cup. You know, maybe
people are still listening because they're driving in their car
and they know it's not safe to like, you.

Speaker 5 (56:56):
Know, up pick up their phone in my podcast.

Speaker 3 (56:59):
So for that person, and I'm just gonna say, like yeah,
you're you're doing the right thing. Keep your hands on
the wheel, don't don't you pick stiff drivers. I only
have ten more minutes of filler right here before I
send you my pick. Okay, yeah, okay, cool, I would pick.
I wanted to watch some space shows. I was trying
to find TV shows to watch, but I have no
time for anything. And like, my problem with most TV

(57:19):
shows is that they're just like, oh, they have like
a secondary plot line, and it just takes all this
extra time and it's not it's not dense enough. So
I found the show Firefly.

Speaker 4 (57:27):
You guys, are you kidding me?

Speaker 3 (57:29):
Yeah?

Speaker 4 (57:30):
Are you choking?

Speaker 3 (57:31):
You found you joking? And maybe everybody already knows it.
But here, oh my god, there I found this guy.
You need to his name Shakespeare. I don't know if
you've heard of them, bro.

Speaker 1 (57:44):
I got some other things I need to tell you about.

Speaker 3 (57:49):
This movie Star Wars and on the third episode.

Speaker 6 (57:54):
Those spoilers and Firefly guys, give them some time.

Speaker 4 (57:59):
I'll else my pretty floral bonnet. I will.

Speaker 5 (58:04):
Oh Alex literally that is.

Speaker 2 (58:06):
It was by far the best sci fi show to
ever be on TV, absolutely barred out.

Speaker 5 (58:10):
I mean, Star Trek's great.

Speaker 3 (58:11):
Don't get me wrong.

Speaker 4 (58:13):
Have you watched the Expanse yet? I have the throne
both Firefly and Battle Star Galactica for me really.

Speaker 2 (58:20):
So, I was not a fan of Battle Star Galactic
far too dark. I don't like shows that are gonna
the stories around how much bad can we make humans do?

Speaker 5 (58:30):
Right? And that's the that's the core underlying plot of
Battlestar Galactica.

Speaker 3 (58:34):
They were all humans. They were all humans.

Speaker 5 (58:36):
Well that's true, but they were. The point was that
nobody cared what the cylons are doing.

Speaker 2 (58:40):
It was the humans, Like, how can we write a
story that shows humans devolving?

Speaker 5 (58:44):
Right? I don't know.

Speaker 2 (58:45):
I like the stories that bring humans up beds.

Speaker 5 (58:51):
Yeah, but the Expanse I thought was great. But I
just I really like that better than Firefly.

Speaker 4 (58:57):
Yeah, for sure, And like I am, I was dire
Firefly fan. I'm on the fan of I'm on the
fence about Joss Whedon in general right now, but like
loved Firefly, but for like a truly to its core
good sci fi show, because like Firefly is like space,
Pirates and good and happiness and all that is great
with the Whedon verse Space Cowboys, Yes, Space.

Speaker 5 (59:16):
What did I say?

Speaker 4 (59:18):
Space Fighter.

Speaker 2 (59:19):
Okay, that's not raw. You're not wrong, But yeah, did
you see Castle? Did you watch Castle?

Speaker 4 (59:26):
I did not.

Speaker 2 (59:27):
Oh there's there's like three payoffs after Wait.

Speaker 4 (59:30):
No, I did see the episode where he dresses up
as a space cowboy for Halloween. Is that what you're
gonna say?

Speaker 5 (59:35):
So?

Speaker 1 (59:36):
But my favorite about this pick is that Alex was like,
I don't know if they've ever heard of it. I mean,
I'm gonna say it and hopefully someone knows, hopefully is
not too obscure.

Speaker 3 (59:49):
And then everyone who's listening is like, oh my god. Yeah.

Speaker 4 (59:54):
So once he finished Firefly, you have to go watch
Doctor Horrible.

Speaker 5 (59:58):
Oh yeah, I'm making the and Castle. You should watch Castle.
It's a good one too.

Speaker 2 (01:00:03):
But I am so excited, Alex that you have discovered Firefly,
and you know, organically, I'm.

Speaker 3 (01:00:09):
So excited that you've discovered remote build execution. Joe.

Speaker 2 (01:00:14):
I would not say that I have discovered that, to
be honest, I'm gonna say somebody told me about it.

Speaker 5 (01:00:19):
It's like it's like hearing the Firefly is a thing. No, no, no,
you discovered it. I have.

Speaker 2 (01:00:23):
I'm just like, yeah, it's a thing, I've heard about
it someday I'll be cool enough to be involved. But
you are now joining this really awesome firefight club, and
I feel.

Speaker 5 (01:00:32):
I feel privileged, right, Like I think Alex Evil joined
my club. That's that's big. Yeah.

Speaker 1 (01:00:39):
Well, hey, I'm gonna cut this off. It's it's we're
an hour and fifteen, so I'm gonna end this. But Alex,
you are a gracious guests that you were coming on.

Speaker 5 (01:00:49):
Yes, yeah, thanks for listening too. This is like this
super awesome episode. This is this is going down, you know,
top one of my top ones.

Speaker 2 (01:00:57):
I liked this one, not just for the ending, not
for the discussion about the picks.

Speaker 3 (01:01:01):
Okay, everybody, thanks for coming. We'll check you next time. Peace.

Speaker 1 (01:01:05):
Peace,

All Episodes

Bazel with Alex Eagle - AiA 422

Episode Transcript

Popular Podcasts

CrimeLess: Hillbilly Heist

Crime Junkie

Stuff You Should Know

.css-15opob5{left:0;position:absolute;top:0.8rem;} All Episodes

.css-14f5ked{margin:0;word-break:break-word;display:-webkit-box;-webkit-box-orient:vertical;box-orient:vertical;-webkit-line-clamp:2;overflow:hidden;}Bazel with Alex Eagle - AiA 422