Hello, Welcome to Adventures and Angler, the podcast where we keep you updated
on all things Angular related. This show is produced by two companies, Stop
and Doves and Onvoid Top and Doves, where we create Top and Doves who
get top and pay and recognition while working on interesting problems and making meaningful community
contributions, and Onvoid which Promote, which provides remote design and software development services
on a task basis, so clients only pay when tasks are delivered and approved.
In today's episode, we will talk about the Angular Cli and all the
new features around it from the latest versions and also what is coming next.
And I can say that we know what's coming next because my name is Lucas
Paganini. I'm your host and a podcast. But joining me in today's episode
is Alan Aguz, which is working from Google in the Angular Core team and
focused on developing the Angler Cli. So welcome, Alan, Thank you for
having me here. It's a true pleasure. Thank you for taking time.
Well, let's get onto it. So Alan, why don't we start with
the latest changes and then we can later go into what's coming in the future.
So we are currently on version seventeen of Angular at least the stable released
version of Angler is the seventeen So do you think there are any notable changes
that may be the Angler developers worldwide aren't taking full advantage of yet and they
should be aware of. Okay, So in version seventeen or three, which
will actually be released as stable later on this week, we introduced an optional
migration for users to upgrade their existing applications to use the application build there which
is based and uses is built and white. This basically enables to reduce the
number of commands you need to run if you use SSR or SSG, improve
the reload time like the added refresh loop basically and also reduces the the build
times. Other than that the application will be built would be the bunds will
be output to e SM instead of like the APE format, so we also
modernize the output format and yeah, other than that, in verse seventeen HM
dot zero we also like improved the SSR and SG experience for users and so
now when users create a new application, they can immediately choose to use service
side greendering and STATI side generation. I think from the ENGLIS those are the
main things that we introduced recently. Nice you mentioned that we are now outputting
es modules and it's correct nice well. Apart from the performance improvements, there
is a browser compatibility concern that you well, at least used to be a
major concern. I'm happy to say that nowadays web developers have been less concerned
about this as modern browsers have been more diligent in auto update features and also
just keeping keeping them updated on the latest were on the latest features from actmascript.
But I do think that something that people aren't very aware of is that
Anglar does have some automatic poly fields. So correct me if I'm wrong.
But for example, if you have a browser's browsers list, I think that's
the correct the correct name of the file, right, So it should be
dot browser list RC, and you can put there all the browsers that your
application is supposed to support, and then the Angler cli will automatically add CSS
prefixes and add other necessary JavaScript polyfields to make sure that your code is going
to be as much supported as possible in all those browsers. Is that correct?
Well, it does add CSS prefixes and when there prefixes for CSS.
However, it does not add any JavaScript polyficse. What it does is that
basically it will down level certain fe features two Uh, there previous ECMA versions.
So for example, instead of ah if, for example, a browser
doesn't support the spread operator to use object as as signed, et cetera,
so it doesn't add polyphice, it just uses a different output version of ECHMA.
That being said, there is also a constraint, which is there might
be certain browsers that simply do not work because Angler doesn't support all the browsers
there are and officially angular supports like the last two major versions of Chrome,
the two major versions of Tafari, and I believe also the two last major
versions of Firefox. So yeah, while it can work on other browsers,
it is not officially supported. Gotcha. But is that done in the Angler
CLI or is that something that is based on the target module that I set
in my TS config because I know that Typescript does that for me depending on
the module that I'm targeting, So it just adds the necessary down level policy
fields for that. So yeah, Actually, the type the target setting in
the ts configure is not used because internally in the CLI always overridden just because
to honor the browser's list, because otherwise users would have to manually keep them
in sync based on what browsers you need to support, you need to change
your TES configures. So a couple of major versions ago, we decided that
the browser's list configuration is sort of the source of truth, which which based
on the browsers to support you listed there, and that will output the right
JavaScript and the right tests that it's compatible with those browsers, excluding any polyphase.
So if there's a polyphil an API that doesn't exist on a certain browser,
users would still need to add polyphores. Interesting. So for example,
if I want to use structured clone and I want to make sure that the
browsers are supporting it, then I need to manually add a structured clone poly
field. Is that correct? Uh? Correct? If if if one of
your browsers doesn't support it? Okay, okay, Interesting. That's good to
know because for a very long time I thought that the Angler cl I would
also add those JavaScript poly fuels too, But so now I understand that the
geoscript POLO fields are based on the the so the Angler cl I only changes
the target from typescript, and Typescript itself might not poly field, but down
level those things, so they would they would still work. And what the
Angler cli also does is to perfect the CSS properties. Interesting. Interesting,
nice? Okay, what about next steps for the Angler CLI? What is
coming next? Okay? So definitely we want to continue moving forward and invest
in as build and white. Also since Karma has been deprecated. We also
recently have released web thestran Air build there and I think I measures seem rely
s just build there, and we want to continue improving them and eventually make
them as stable. In version eighteen, definitely expect some changes and improvements around
SSR and setixide generation, including improvements for AT and n OH. I think
that is what's coming in the next major version primary in the CLI. Okay,
you mentioned as always thing and as all ways like continuing back fixes and
and things like that. Okay, you mentioned internationalizations, so I'm not sure
if this is going to be inside the scope of the Angler CLI. I
thought it wouldn't, but since you mentioned, I gotta ask. One feature
that I know is possible in the latest version of Angler is to dynamically load
translations. And this has been possible for a while now, but it's just
not very well documented. But I know that it is possible. But we
are still making multiple builds for each different language, right so you still set
Angler to make the look if you have seven languages, is still going to
to create seven builds at the end. It's much faster because it does a
lot of the process, the shared process before and then it just applies the
translations at the end. But it still does that in the equal amount of
languages that day your application sports because the first I wouldn't maybe not first class.
What I was going to say is that the main use case for internationalization
in Angler is for the developers to actually make different builds like although Angler does
support dynamically loading them, it's still the main use case. I think people
are still making different builds and maybe loading based on the route prefix like slashy
and slash pt slash yes, I think you were going to say something yees.
So basically, there are two ways you can localize an application with Angular.
There's the build time where you have like multiple bills as you mentioned,
or there's the run time, which basically you have a single build and load
the translation during run time, which can come from either being hardcloaded in your
code or an external source like CMS, sortage, is and file. There
are lots of advantages and therese advantages to both cases, primarily using built time
translations, while it does slow down the build, it reduces the bunder size
and also you have slightly faster experience for the users and there's no translations happening
on the fly, while on the other hand, runtime translations you have a
single build and you can also like change translations on the fly, meaning that
if you have translations coming from an EPI or CM mess, you don't need
to redeploy every time translation is changed or something like that. So it's also
it's also depends on your requirements what sort of translation is SUE to best.
And basically what we want to improve is the experience with both sort of translations
when using ssurces G because from what the user tells us that there are some
shortcomings and to definitely want to improve the experience around that area mainly, but
that, as you explained, definitely right time translation are not well documented and
we are aware of that and this is something that is definitely on our dar.
Okay, besides, so let me see if I get this right.
So there's the lack of documentation issue. Okay, we got that, But
besides that, are you planning to change in any way how the run time
translations are done or is it just an issue with documentation? So FORSR for
ASR, there will be slight change for both sort of translations, but it
should be not that visibility the user, So basically the changes will be more
of an internal changes. However, it would improve how users would basically staff
forward their application, meaning that they would not they will no longer need to
add extra code on top of what we generate. It will be done by
default, but the IEM and itself will not change. Okay, interesting,
and currently, is there a way for me to generate a build of my
application that doesn't contain any applied languages at all? Like I don't want to
generate the base language one. I want to just generate one that only has
the language tokens, and it doesn't have any any transcript even in the base
language built in. It's just the language tokens that I'm going to load them
on run time because I don't want to even spend one kilobyte of data downloading
languages that are maybe not going to be the ones that are going to be
used. Is there a way for me to do this currently? Not that
I'm aware of. No, because the actual source codes, source code value
or original language value is sort of the key of the translation at the moment.
So what you can do is basically change that tool. Instead of saying,
I don't know, Hello world, this is my application, you can
change that to something shorter and make it as a key. So the actual
text is the key. That's interesting because I always thought that it would generate
rendom id and that would be the key. That's for the runtime translations,
for the build time translations for the run time. It's slightly different mm hm
since there's no run run since during the run time there's no The bill doesn't
take care of internalization, it will not amend the keys. And how does
it deal with with the same key but with different translations based on the ideal.
Like let's say that I have the string Hello in two different components,
and in one component it should translate to Portuguese to pola and the other should
translate to yai. So I'm translating the same Hello string and real time that
would work because it would generate different ideas, but at runtime it would just
map to the same to Like the first instance that refines is that it uh
That is a good question and on top of my head. I don't really
know how it's really handled. Okay, okay, nice, I made the
first difficult question to the d that actually built this thing, I did not,
okay, okay, but that that works on it. Okay, okay,
nice, Nice. Let me see what else we can talk about.
So one thing that I generally do a lot on any Angular project that I'm
working on is to add ANX for it. And there are many reasons to
add an X to a cod base. So if you really want a moment
repo, you want to have your front and in your back end, then
sure. But I feel that in a lot of cases where I added NX,
I didn't really needed the back end in there. I was just adding
NX because I wanted to break parts of my application into libraries and be able
to easily import them, import those those private libraries inside my main application code,
and just make it easier to isolate things. And I know that Angler
already provides a solution for that, so I know that I can use the
Angler Cli to generate libraries. But the last time that I used the Angler
cli for that, and I got to be honest, that was like two
years ago. Maybe, so it might have changed from them from since then.
But the last time I did that, I lost the hot reloading feature.
I lost a lot of the the real time debugging that I that I
got from just having the code in my maiation bundle. So I just got
used to adding NX to every project so that I would have this live reloading
changes and et cetera. I was wondering if there were any updates since then,
and if not, if this is in the roadmap. So in the
Engler Cli, we do have concepts of a library and application, and basically
in order for you to live reload the changes, you would need to build
the library and watch mode and the application and watch mode using two different commands,
right, And there is a reason for that, And the reason being
is that the way and next does it slightly different. And while you say
isolate your code in library, that's actually not completely. It's what you are
doing is actually having that library be built as part of the application, so
there is no isolation. In theory, this can result in two main problems.
Right One, a library has its own rules and its own compilation and
uses a different build there which is not exactly the same as an application build
there. That means in some cases, things that work when you build your
library as part of your application, they do not actually work when you build
your library as a library. So if you want to ship your library,
you might have some challenges here if you sort of create an unpublished library and
then move it to a publishing library in the next. However, users do
use this version of non publishing libraries in a next and it's quite popular.
It's just another way of organizing your code. But I just want to make
it clear. It's not isolating your code from your application. It is still
part of your application. It is still built fully as part of your application.
So it's like having a subdirectory under a source the application because that library
code is still treated fully as application code. I have a few questions about
that before we go on, and just to make sure that everyone is understanding
what we're talking about. So let me see if I get to scrrect.
What you're saying is that when we are isolating things in a library and we're
using the anglers you a lie to do it. It creates its own entire
build contexts, and when you actually build that library, you're building that in
isolation. And for NX, this isn't true in the meaning that those libraries
are just going to be placed inside the application bundle as if you were a
folder inside the application. So from a developer perspective, you're getting the isolation
that you want in terms of code based organization, just like isolating the files
and making it easy for like, if you want to just copy and paste
an entire library into another project, you can because they are isolated in that
But in terms of the actual build, it's still a single build. So
this is what we're talking about. Interesting. So in that note, I
I have one questions, So NX allows me to have different TS configs for
each library. For each NX library, I'm going to call them NX library,
so that we already have a distinction between Angular Cli libraries and NX libraries
because as we were just discussing, they are different definitions. So I can
have a different TS config for each NX library, but if they are sharing
the same build process, how is that possible? So in the next there
are also two concepts of libraries publishing publishabile and non published libraries, and it
is also based on how the test configured bots are configured, meaning that in
your application tests config for the library. There is a plus specified which can
be either the types strifis meaning that the tut would be of the library will
be compiled and bundled as part of the application, or actually the butt be
pointing to an actually distributed version of the library or already built library. So
it also comes down to how it is configured in your types of configuration.
Gotcha? So if I were to set a particular n X library to be
publishable, then it would create its own built context. Yes, but I'm
not sure if it's I don't requalifyed by default. If it's constructed in a
library, it will be built beforehand or just built as part of the library
of the application. Excuse me? Interesting? Okay, So now getting back
to pure Angler without NX, is there any advisable strategy like I imagined that
inside Google, you guys are dog feeding Angler everywhere, right, So you're
using Angler in many different internal projects, and there's probably a need to isolate
certain parts of your Angular applications into modules. And I mean modules just in
the sense of a folder that contains all the logic related to that particular feature,
so that is easy to just copy and paste and port that to other
projects. How what is the current recommended approach to do this with pure Angular
without NX is to just place those as regular folders inside the application source so
instead and outside Google, Angular is likely different because how you building Lars's different
because internally in Google the Angular cli or annex is not used. We have
our own build system, which is a blaze, which open source is called
Basil, which basically handles everything for us, meaning that you can go as
fine grain as having a built for a component, a single component, or
having a build or library of a single module or a whole application. So
it's quite fine grade of how you can structure the code inside Google, and
in general, if you want to reshare code, it will be its own
build, so it will be a sort of a type of library or in
engy library, and it will have its own built which will be with your
application or your other module will be dependent on the Basil will ah basically build
everything and all the dependencies that are needed, so when you build your application,
it will find all the dependencies that your application needs and it will rebuild
them automatically. Interesting, so all of that in a single progress Yes.
Interesting? Okay, And you mentioned that BESO is the open source version of
place. Do you have any any plans, like the Angler team has any
plans to make it easier for other companies besides Google to have this fine grain
build system or is it just not in the plans? So? Ah,
Actually we did try, I think around version eight or ten, we had
an Angular Basil labs where you could use the NGO cl lie with Basil.
However, that was not super successful just because a Basil needs quite a lot
of configuration and unless you are building a very large application, it is not
beneficial because you will not see that much of a built built gain. I
mean if your code base is small or relatively small. Basil does have an
overhead, so instead of having a faster built, if your application slow is
small, your application built will be quite slow. And there before there were
also some incompatibilities with Windows, so it's definitely not in our plans. Again
too invest in making a Basil a first class citizen of anglar CLA. Okay,
but is this still possible, like even though it's not a first class
citizen, if anyone wanted to use Besio to render Angular builds. Currently on
version seventeen and just going forward. Is that still possible, like, could
a community driven plugging be created? Or yeah, I mean Basic can be
used to build any language, so it can be used to build Go,
Java, fighting anything. Any language can be built used in besil. Interesting
and when it's used inside Google, is it for example, are we talking
about using Blaze just to build an angular co base or is it also very
common to have a back end in the same repository and having the same basio,
the same Blaze process building the front end and the back end. So
in Google there's a single MONORYPO with hundreds and thousands of projects, and there's
only a BIL system, which is where there's one primary build system, which
is Basil, which the same process can build an xt amount of languages because
when you do like Basil built, it can check what dependencies your application needs.
If it needs a back end, it will build your back end,
and if that back end requires some other services, that will build them.
So yeah, can build with the same process an infinite amount number of dependencies,
an infinite amount number of languages. Okay, that's very that's very interesting.
At least look for enterprise companies out there to know that this is an
option. Although I imagine that it could be very costly to set up,
and maybe due to the lack of other companies using it, it might not
even be worth it, depending on how much time there they are saving.
But at least this isn't an option that enterprise companies could consider interesting. Okay,
Alan, we spoke about several things already. I know that there are
many others that we could go into. I don't want to drag the episode
too long just to keep the the main content concise for the audience, but
I do want to open the floor for you and ask do you think there
are any other topics that we should have covered, Like you think they are
interesting and important enough that we should talk about them today, and that perhaps
we haven't yet. Yeah, I cannot think of anything right now, like
it's worth pointing out. Okay, In terms of some of the things that
we were discussing before, we talked a bit about internationalization and runtime internationalization,
and we mentioned that currently there aren't any good official dogs about it. But
I was wondering if you know of any good source as a third party company
that maybe wrote interesting articles about how to do runtime internationalization, just so that
we can send something for the audience. For those that are interested in that,
there is a third party community project that leverages singular internalization and built on
top of it. I think it's called inter Loco. Let me try to
find it. And this library leverages do you run time personalities? Right,
not just the build time. It's actually for the runtime translations. I'm trying
to find it. Mm hmm. Turns slow, but I think it tron
slow into yes, I think I yeah, it was this one. Okay,
okay, I'm going to send this in the comment section. So if
you're listening to the show and there is no comment section from where you're consuming
the show, you can just look for it on YouTube with the same title.
So Alan argues Angler Cli Adventures and Angler, and you will be able
to find it in the You should be able to find it in the comment
section there, but if you don't, it's from the JAS verse, so
JAS from jailascript, so from the Jas versus user on GitHub, there's this
library called trends local and as Alan was saying, this library internally leverages the
runtime capabilities of Angular internationalization. So if you're interested in seeing how you can
add runtime translations into your Angular application, you can look at how this library
is leveraging those functionalities, and maybe even just use the library directly. Do
what would you recommend, Alan, would you recommend using this library or just
looking at how they do it internally? I mean it it depends what are
your needs. If you need something really sophisticated, that might that library might
do it for you. However, the standard API that Angler provides might be
enough. I think there's what There might be also some information on how to
use the I and on the issue that sent in the chat okay sent that
sent this link to for anyone that can't see the link. So inside the
Angular repository on GitHub is the issue number forty six top forty six, eight
hundred and fifty one, so four six eighty five one. If you go
to this issue on the Angler repository on GitHub, there is a discussion there
about how to how to use and time translations with an Angular Yes, and
that issue will be updated once we had more documentation, et cetera. So
if you're interested in no time translation, subscribe to that issue. Awesome.
One other question that came to my mind kind of with small curiosity, but
in recent versions there was a change from Angie dash dash version to energie version
without the dash dash And I'm wondering, why why did we have this this
small change. I have a friend that gets the wrong all the time.
It's always like, ah, forgot about this. So there is a being
that we changed. It was that we changed the entire system that the Angular
CLI uses to build the commands and parce the command line parts one ie,
argue, ons et cetera. So with that change, there were some something
changes that needed to happen, and one of one of those was the Engidish
situation. Gotcha, it's just to improve the parting of another of other functionalities
to not make it confusing with other functionalities. Cool, okay, Alan,
thank you so much. I think this was a very very interesting episode and
we were able to go into some interesting questions about the Angler CLI. And
thank you. Thank you for your time. I think this was very very
interesting, very helpful. I know that for me I was able to make
some questions that, at least to me, they were relevant some things that
were in my mind. So thank you very much. Do you have anything
you'd like to promote like this? The floor is shameless, plex No.
I just wanted to mention one more thing that in the chat, I sent
another library which is basically done by the community and it is done by also
a former Angular team member, which is jax Translate. It was a real
pleasure having having this chat with you. I hope I answered some questions and
yeah, it was really fun. Thank you for having me. Yes,
thank you for me on the show. I'm just gonna promote well actually not
not really gonna promote anything. I think just the companies producing this show.
So again, Top and Devs if you're looking to improve your development skills,
So top and Devs is the company that produces this show and many others.
So if you're looking for more technical content, you can look at topendev dot
com. And if your company or someone that you know is looking for remote
design or web development services, you can look for Void is you and the
OI d so on and Void dot com and they offer remote design and software
development services on a performance basis, so their clients only pay after tasks are
delivered and approved by the customers. So yes, thank you very much,
holland thank thank you the audience for sticking up to the end. Have a
great week and I'll see you in the next one.