1 00:00:06,759 --> 00:00:11,599 Hello, Welcome to Adventures and Angler, the podcast where we keep you updated 2 00:00:11,640 --> 00:00:16,039 on all things Angular related. This show is produced by two companies, Stop 3 00:00:16,079 --> 00:00:19,719 and Doves and Onvoid Top and Doves, where we create Top and Doves who 4 00:00:19,760 --> 00:00:24,440 get top and pay and recognition while working on interesting problems and making meaningful community 5 00:00:24,519 --> 00:00:30,120 contributions, and Onvoid which Promote, which provides remote design and software development services 6 00:00:30,160 --> 00:00:35,240 on a task basis, so clients only pay when tasks are delivered and approved. 7 00:00:35,759 --> 00:00:40,679 In today's episode, we will talk about the Angular Cli and all the 8 00:00:40,759 --> 00:00:45,560 new features around it from the latest versions and also what is coming next. 9 00:00:46,359 --> 00:00:51,600 And I can say that we know what's coming next because my name is Lucas 10 00:00:51,640 --> 00:00:55,840 Paganini. I'm your host and a podcast. But joining me in today's episode 11 00:00:56,079 --> 00:01:00,880 is Alan Aguz, which is working from Google in the Angular Core team and 12 00:01:00,920 --> 00:01:07,640 focused on developing the Angler Cli. So welcome, Alan, Thank you for 13 00:01:07,680 --> 00:01:11,359 having me here. It's a true pleasure. Thank you for taking time. 14 00:01:12,280 --> 00:01:17,319 Well, let's get onto it. So Alan, why don't we start with 15 00:01:18,040 --> 00:01:23,280 the latest changes and then we can later go into what's coming in the future. 16 00:01:23,599 --> 00:01:29,879 So we are currently on version seventeen of Angular at least the stable released 17 00:01:30,000 --> 00:01:36,840 version of Angler is the seventeen So do you think there are any notable changes 18 00:01:36,920 --> 00:01:42,920 that may be the Angler developers worldwide aren't taking full advantage of yet and they 19 00:01:42,959 --> 00:01:49,079 should be aware of. Okay, So in version seventeen or three, which 20 00:01:49,120 --> 00:01:56,200 will actually be released as stable later on this week, we introduced an optional 21 00:01:56,239 --> 00:02:04,319 migration for users to upgrade their existing applications to use the application build there which 22 00:02:04,359 --> 00:02:13,719 is based and uses is built and white. This basically enables to reduce the 23 00:02:13,800 --> 00:02:19,120 number of commands you need to run if you use SSR or SSG, improve 24 00:02:20,800 --> 00:02:30,400 the reload time like the added refresh loop basically and also reduces the the build 25 00:02:30,479 --> 00:02:36,960 times. Other than that the application will be built would be the bunds will 26 00:02:37,000 --> 00:02:42,400 be output to e SM instead of like the APE format, so we also 27 00:02:42,479 --> 00:02:50,879 modernize the output format and yeah, other than that, in verse seventeen HM 28 00:02:51,280 --> 00:02:58,759 dot zero we also like improved the SSR and SG experience for users and so 29 00:02:58,960 --> 00:03:05,639 now when users create a new application, they can immediately choose to use service 30 00:03:05,680 --> 00:03:10,400 side greendering and STATI side generation. I think from the ENGLIS those are the 31 00:03:10,479 --> 00:03:16,800 main things that we introduced recently. Nice you mentioned that we are now outputting 32 00:03:17,120 --> 00:03:24,840 es modules and it's correct nice well. Apart from the performance improvements, there 33 00:03:25,039 --> 00:03:30,159 is a browser compatibility concern that you well, at least used to be a 34 00:03:30,199 --> 00:03:36,919 major concern. I'm happy to say that nowadays web developers have been less concerned 35 00:03:36,919 --> 00:03:44,280 about this as modern browsers have been more diligent in auto update features and also 36 00:03:44,360 --> 00:03:51,719 just keeping keeping them updated on the latest were on the latest features from actmascript. 37 00:03:52,120 --> 00:03:59,479 But I do think that something that people aren't very aware of is that 38 00:03:59,840 --> 00:04:04,960 Anglar does have some automatic poly fields. So correct me if I'm wrong. 39 00:04:05,680 --> 00:04:12,719 But for example, if you have a browser's browsers list, I think that's 40 00:04:13,080 --> 00:04:15,920 the correct the correct name of the file, right, So it should be 41 00:04:16,000 --> 00:04:21,040 dot browser list RC, and you can put there all the browsers that your 42 00:04:21,079 --> 00:04:30,720 application is supposed to support, and then the Angler cli will automatically add CSS 43 00:04:30,759 --> 00:04:38,920 prefixes and add other necessary JavaScript polyfields to make sure that your code is going 44 00:04:38,959 --> 00:04:45,199 to be as much supported as possible in all those browsers. Is that correct? 45 00:04:45,759 --> 00:04:48,759 Well, it does add CSS prefixes and when there prefixes for CSS. 46 00:04:48,759 --> 00:04:55,920 However, it does not add any JavaScript polyficse. What it does is that 47 00:04:56,720 --> 00:05:08,399 basically it will down level certain fe features two Uh, there previous ECMA versions. 48 00:05:08,639 --> 00:05:13,920 So for example, instead of ah if, for example, a browser 49 00:05:13,920 --> 00:05:18,279 doesn't support the spread operator to use object as as signed, et cetera, 50 00:05:18,480 --> 00:05:24,759 so it doesn't add polyphice, it just uses a different output version of ECHMA. 51 00:05:26,480 --> 00:05:34,120 That being said, there is also a constraint, which is there might 52 00:05:34,279 --> 00:05:40,839 be certain browsers that simply do not work because Angler doesn't support all the browsers 53 00:05:41,079 --> 00:05:46,279 there are and officially angular supports like the last two major versions of Chrome, 54 00:05:46,319 --> 00:05:54,120 the two major versions of Tafari, and I believe also the two last major 55 00:05:54,199 --> 00:06:00,279 versions of Firefox. So yeah, while it can work on other browsers, 56 00:06:01,079 --> 00:06:09,000 it is not officially supported. Gotcha. But is that done in the Angler 57 00:06:09,079 --> 00:06:15,160 CLI or is that something that is based on the target module that I set 58 00:06:15,319 --> 00:06:19,160 in my TS config because I know that Typescript does that for me depending on 59 00:06:19,199 --> 00:06:26,759 the module that I'm targeting, So it just adds the necessary down level policy 60 00:06:26,759 --> 00:06:31,319 fields for that. So yeah, Actually, the type the target setting in 61 00:06:31,360 --> 00:06:38,759 the ts configure is not used because internally in the CLI always overridden just because 62 00:06:39,279 --> 00:06:46,040 to honor the browser's list, because otherwise users would have to manually keep them 63 00:06:46,079 --> 00:06:49,600 in sync based on what browsers you need to support, you need to change 64 00:06:49,639 --> 00:06:55,560 your TES configures. So a couple of major versions ago, we decided that 65 00:06:56,519 --> 00:07:01,560 the browser's list configuration is sort of the source of truth, which which based 66 00:07:01,600 --> 00:07:08,240 on the browsers to support you listed there, and that will output the right 67 00:07:08,360 --> 00:07:15,240 JavaScript and the right tests that it's compatible with those browsers, excluding any polyphase. 68 00:07:15,360 --> 00:07:21,839 So if there's a polyphil an API that doesn't exist on a certain browser, 69 00:07:23,160 --> 00:07:28,560 users would still need to add polyphores. Interesting. So for example, 70 00:07:28,600 --> 00:07:33,519 if I want to use structured clone and I want to make sure that the 71 00:07:33,560 --> 00:07:40,879 browsers are supporting it, then I need to manually add a structured clone poly 72 00:07:40,959 --> 00:07:46,160 field. Is that correct? Uh? Correct? If if if one of 73 00:07:46,160 --> 00:07:50,920 your browsers doesn't support it? Okay, okay, Interesting. That's good to 74 00:07:51,000 --> 00:07:56,040 know because for a very long time I thought that the Angler cl I would 75 00:07:56,079 --> 00:08:01,720 also add those JavaScript poly fuels too, But so now I understand that the 76 00:08:01,800 --> 00:08:05,920 geoscript POLO fields are based on the the so the Angler cl I only changes 77 00:08:05,959 --> 00:08:13,839 the target from typescript, and Typescript itself might not poly field, but down 78 00:08:13,920 --> 00:08:18,600 level those things, so they would they would still work. And what the 79 00:08:18,600 --> 00:08:24,480 Angler cli also does is to perfect the CSS properties. Interesting. Interesting, 80 00:08:24,439 --> 00:08:33,200 nice? Okay, what about next steps for the Angler CLI? What is 81 00:08:33,200 --> 00:08:41,799 coming next? Okay? So definitely we want to continue moving forward and invest 82 00:08:41,879 --> 00:08:52,000 in as build and white. Also since Karma has been deprecated. We also 83 00:08:52,480 --> 00:09:00,559 recently have released web thestran Air build there and I think I measures seem rely 84 00:09:00,679 --> 00:09:07,440 s just build there, and we want to continue improving them and eventually make 85 00:09:07,519 --> 00:09:16,320 them as stable. In version eighteen, definitely expect some changes and improvements around 86 00:09:16,600 --> 00:09:28,360 SSR and setixide generation, including improvements for AT and n OH. I think 87 00:09:30,240 --> 00:09:35,639 that is what's coming in the next major version primary in the CLI. Okay, 88 00:09:37,039 --> 00:09:43,960 you mentioned as always thing and as all ways like continuing back fixes and 89 00:09:43,960 --> 00:09:50,000 and things like that. Okay, you mentioned internationalizations, so I'm not sure 90 00:09:50,080 --> 00:09:56,080 if this is going to be inside the scope of the Angler CLI. I 91 00:09:56,200 --> 00:10:01,879 thought it wouldn't, but since you mentioned, I gotta ask. One feature 92 00:10:01,960 --> 00:10:07,000 that I know is possible in the latest version of Angler is to dynamically load 93 00:10:09,799 --> 00:10:15,480 translations. And this has been possible for a while now, but it's just 94 00:10:15,559 --> 00:10:20,159 not very well documented. But I know that it is possible. But we 95 00:10:20,279 --> 00:10:28,759 are still making multiple builds for each different language, right so you still set 96 00:10:28,080 --> 00:10:35,240 Angler to make the look if you have seven languages, is still going to 97 00:10:35,240 --> 00:10:39,440 to create seven builds at the end. It's much faster because it does a 98 00:10:39,480 --> 00:10:45,440 lot of the process, the shared process before and then it just applies the 99 00:10:45,480 --> 00:10:50,279 translations at the end. But it still does that in the equal amount of 100 00:10:50,399 --> 00:11:01,600 languages that day your application sports because the first I wouldn't maybe not first class. 101 00:11:01,360 --> 00:11:05,399 What I was going to say is that the main use case for internationalization 102 00:11:05,480 --> 00:11:13,600 in Angler is for the developers to actually make different builds like although Angler does 103 00:11:13,600 --> 00:11:18,840 support dynamically loading them, it's still the main use case. I think people 104 00:11:18,840 --> 00:11:26,279 are still making different builds and maybe loading based on the route prefix like slashy 105 00:11:26,399 --> 00:11:31,600 and slash pt slash yes, I think you were going to say something yees. 106 00:11:31,000 --> 00:11:35,519 So basically, there are two ways you can localize an application with Angular. 107 00:11:35,879 --> 00:11:41,399 There's the build time where you have like multiple bills as you mentioned, 108 00:11:41,159 --> 00:11:45,879 or there's the run time, which basically you have a single build and load 109 00:11:46,919 --> 00:11:52,759 the translation during run time, which can come from either being hardcloaded in your 110 00:11:52,000 --> 00:12:01,360 code or an external source like CMS, sortage, is and file. There 111 00:12:01,399 --> 00:12:09,279 are lots of advantages and therese advantages to both cases, primarily using built time 112 00:12:09,279 --> 00:12:13,639 translations, while it does slow down the build, it reduces the bunder size 113 00:12:16,080 --> 00:12:22,679 and also you have slightly faster experience for the users and there's no translations happening 114 00:12:22,960 --> 00:12:28,720 on the fly, while on the other hand, runtime translations you have a 115 00:12:28,720 --> 00:12:35,559 single build and you can also like change translations on the fly, meaning that 116 00:12:35,600 --> 00:12:39,639 if you have translations coming from an EPI or CM mess, you don't need 117 00:12:39,679 --> 00:12:46,000 to redeploy every time translation is changed or something like that. So it's also 118 00:12:46,279 --> 00:12:52,360 it's also depends on your requirements what sort of translation is SUE to best. 119 00:12:54,919 --> 00:13:01,399 And basically what we want to improve is the experience with both sort of translations 120 00:13:01,399 --> 00:13:09,879 when using ssurces G because from what the user tells us that there are some 121 00:13:09,919 --> 00:13:18,080 shortcomings and to definitely want to improve the experience around that area mainly, but 122 00:13:18,279 --> 00:13:24,879 that, as you explained, definitely right time translation are not well documented and 123 00:13:24,240 --> 00:13:28,679 we are aware of that and this is something that is definitely on our dar. 124 00:13:31,320 --> 00:13:35,840 Okay, besides, so let me see if I get this right. 125 00:13:35,240 --> 00:13:41,279 So there's the lack of documentation issue. Okay, we got that, But 126 00:13:41,159 --> 00:13:48,039 besides that, are you planning to change in any way how the run time 127 00:13:48,039 --> 00:13:54,840 translations are done or is it just an issue with documentation? So FORSR for 128 00:13:54,919 --> 00:14:05,799 ASR, there will be slight change for both sort of translations, but it 129 00:14:05,840 --> 00:14:09,679 should be not that visibility the user, So basically the changes will be more 130 00:14:09,720 --> 00:14:20,279 of an internal changes. However, it would improve how users would basically staff 131 00:14:20,320 --> 00:14:24,559 forward their application, meaning that they would not they will no longer need to 132 00:14:24,600 --> 00:14:28,639 add extra code on top of what we generate. It will be done by 133 00:14:28,679 --> 00:14:35,799 default, but the IEM and itself will not change. Okay, interesting, 134 00:14:37,240 --> 00:14:41,240 and currently, is there a way for me to generate a build of my 135 00:14:41,320 --> 00:14:48,440 application that doesn't contain any applied languages at all? Like I don't want to 136 00:14:48,480 --> 00:14:54,320 generate the base language one. I want to just generate one that only has 137 00:14:54,360 --> 00:15:01,159 the language tokens, and it doesn't have any any transcript even in the base 138 00:15:01,320 --> 00:15:05,639 language built in. It's just the language tokens that I'm going to load them 139 00:15:05,000 --> 00:15:11,919 on run time because I don't want to even spend one kilobyte of data downloading 140 00:15:11,039 --> 00:15:16,000 languages that are maybe not going to be the ones that are going to be 141 00:15:16,080 --> 00:15:22,360 used. Is there a way for me to do this currently? Not that 142 00:15:22,399 --> 00:15:30,159 I'm aware of. No, because the actual source codes, source code value 143 00:15:30,519 --> 00:15:37,000 or original language value is sort of the key of the translation at the moment. 144 00:15:37,639 --> 00:15:43,440 So what you can do is basically change that tool. Instead of saying, 145 00:15:43,480 --> 00:15:46,600 I don't know, Hello world, this is my application, you can 146 00:15:46,679 --> 00:15:52,279 change that to something shorter and make it as a key. So the actual 147 00:15:52,519 --> 00:15:58,559 text is the key. That's interesting because I always thought that it would generate 148 00:15:58,960 --> 00:16:03,720 rendom id and that would be the key. That's for the runtime translations, 149 00:16:04,039 --> 00:16:07,960 for the build time translations for the run time. It's slightly different mm hm 150 00:16:08,639 --> 00:16:15,039 since there's no run run since during the run time there's no The bill doesn't 151 00:16:15,120 --> 00:16:21,559 take care of internalization, it will not amend the keys. And how does 152 00:16:21,600 --> 00:16:29,639 it deal with with the same key but with different translations based on the ideal. 153 00:16:29,679 --> 00:16:33,200 Like let's say that I have the string Hello in two different components, 154 00:16:33,240 --> 00:16:40,200 and in one component it should translate to Portuguese to pola and the other should 155 00:16:40,200 --> 00:16:48,840 translate to yai. So I'm translating the same Hello string and real time that 156 00:16:48,960 --> 00:16:52,639 would work because it would generate different ideas, but at runtime it would just 157 00:16:52,840 --> 00:16:59,039 map to the same to Like the first instance that refines is that it uh 158 00:17:00,200 --> 00:17:02,919 That is a good question and on top of my head. I don't really 159 00:17:03,039 --> 00:17:08,799 know how it's really handled. Okay, okay, nice, I made the 160 00:17:08,839 --> 00:17:15,759 first difficult question to the d that actually built this thing, I did not, 161 00:17:18,559 --> 00:17:23,720 okay, okay, but that that works on it. Okay, okay, 162 00:17:23,839 --> 00:17:30,279 nice, Nice. Let me see what else we can talk about. 163 00:17:30,359 --> 00:17:36,000 So one thing that I generally do a lot on any Angular project that I'm 164 00:17:36,000 --> 00:17:41,920 working on is to add ANX for it. And there are many reasons to 165 00:17:41,000 --> 00:17:45,279 add an X to a cod base. So if you really want a moment 166 00:17:45,359 --> 00:17:48,240 repo, you want to have your front and in your back end, then 167 00:17:48,359 --> 00:17:55,759 sure. But I feel that in a lot of cases where I added NX, 168 00:17:56,599 --> 00:18:00,319 I didn't really needed the back end in there. I was just adding 169 00:18:00,440 --> 00:18:07,279 NX because I wanted to break parts of my application into libraries and be able 170 00:18:07,319 --> 00:18:18,240 to easily import them, import those those private libraries inside my main application code, 171 00:18:18,440 --> 00:18:23,039 and just make it easier to isolate things. And I know that Angler 172 00:18:23,200 --> 00:18:26,480 already provides a solution for that, so I know that I can use the 173 00:18:26,720 --> 00:18:33,400 Angler Cli to generate libraries. But the last time that I used the Angler 174 00:18:33,440 --> 00:18:37,839 cli for that, and I got to be honest, that was like two 175 00:18:37,920 --> 00:18:44,880 years ago. Maybe, so it might have changed from them from since then. 176 00:18:45,440 --> 00:18:49,799 But the last time I did that, I lost the hot reloading feature. 177 00:18:51,039 --> 00:18:56,720 I lost a lot of the the real time debugging that I that I 178 00:18:56,759 --> 00:19:03,359 got from just having the code in my maiation bundle. So I just got 179 00:19:03,480 --> 00:19:10,400 used to adding NX to every project so that I would have this live reloading 180 00:19:10,480 --> 00:19:15,880 changes and et cetera. I was wondering if there were any updates since then, 181 00:19:15,319 --> 00:19:22,240 and if not, if this is in the roadmap. So in the 182 00:19:22,240 --> 00:19:27,720 Engler Cli, we do have concepts of a library and application, and basically 183 00:19:29,519 --> 00:19:33,519 in order for you to live reload the changes, you would need to build 184 00:19:33,519 --> 00:19:40,480 the library and watch mode and the application and watch mode using two different commands, 185 00:19:40,759 --> 00:19:45,200 right, And there is a reason for that, And the reason being 186 00:19:45,440 --> 00:19:53,680 is that the way and next does it slightly different. And while you say 187 00:19:53,799 --> 00:20:02,960 isolate your code in library, that's actually not completely. It's what you are 188 00:20:02,960 --> 00:20:07,039 doing is actually having that library be built as part of the application, so 189 00:20:07,119 --> 00:20:14,759 there is no isolation. In theory, this can result in two main problems. 190 00:20:14,839 --> 00:20:21,559 Right One, a library has its own rules and its own compilation and 191 00:20:21,880 --> 00:20:25,839 uses a different build there which is not exactly the same as an application build 192 00:20:25,839 --> 00:20:30,200 there. That means in some cases, things that work when you build your 193 00:20:30,640 --> 00:20:36,759 library as part of your application, they do not actually work when you build 194 00:20:36,799 --> 00:20:41,039 your library as a library. So if you want to ship your library, 195 00:20:42,480 --> 00:20:48,839 you might have some challenges here if you sort of create an unpublished library and 196 00:20:48,880 --> 00:21:00,240 then move it to a publishing library in the next. However, users do 197 00:21:00,480 --> 00:21:07,599 use this version of non publishing libraries in a next and it's quite popular. 198 00:21:08,960 --> 00:21:15,599 It's just another way of organizing your code. But I just want to make 199 00:21:15,640 --> 00:21:19,440 it clear. It's not isolating your code from your application. It is still 200 00:21:19,839 --> 00:21:25,000 part of your application. It is still built fully as part of your application. 201 00:21:25,079 --> 00:21:33,480 So it's like having a subdirectory under a source the application because that library 202 00:21:33,480 --> 00:21:40,000 code is still treated fully as application code. I have a few questions about 203 00:21:40,000 --> 00:21:45,799 that before we go on, and just to make sure that everyone is understanding 204 00:21:45,559 --> 00:21:49,359 what we're talking about. So let me see if I get to scrrect. 205 00:21:49,400 --> 00:21:56,480 What you're saying is that when we are isolating things in a library and we're 206 00:21:56,559 --> 00:22:00,519 using the anglers you a lie to do it. It creates its own entire 207 00:22:00,680 --> 00:22:07,160 build contexts, and when you actually build that library, you're building that in 208 00:22:07,279 --> 00:22:18,920 isolation. And for NX, this isn't true in the meaning that those libraries 209 00:22:18,000 --> 00:22:23,519 are just going to be placed inside the application bundle as if you were a 210 00:22:23,640 --> 00:22:33,240 folder inside the application. So from a developer perspective, you're getting the isolation 211 00:22:33,440 --> 00:22:37,880 that you want in terms of code based organization, just like isolating the files 212 00:22:37,920 --> 00:22:42,000 and making it easy for like, if you want to just copy and paste 213 00:22:42,039 --> 00:22:48,640 an entire library into another project, you can because they are isolated in that 214 00:22:49,400 --> 00:22:56,559 But in terms of the actual build, it's still a single build. So 215 00:22:56,960 --> 00:23:03,920 this is what we're talking about. Interesting. So in that note, I 216 00:23:03,920 --> 00:23:10,200 I have one questions, So NX allows me to have different TS configs for 217 00:23:10,480 --> 00:23:15,559 each library. For each NX library, I'm going to call them NX library, 218 00:23:15,680 --> 00:23:19,920 so that we already have a distinction between Angular Cli libraries and NX libraries 219 00:23:21,119 --> 00:23:25,559 because as we were just discussing, they are different definitions. So I can 220 00:23:25,599 --> 00:23:32,279 have a different TS config for each NX library, but if they are sharing 221 00:23:32,359 --> 00:23:37,519 the same build process, how is that possible? So in the next there 222 00:23:37,519 --> 00:23:47,799 are also two concepts of libraries publishing publishabile and non published libraries, and it 223 00:23:47,880 --> 00:23:56,079 is also based on how the test configured bots are configured, meaning that in 224 00:23:56,119 --> 00:24:02,680 your application tests config for the library. There is a plus specified which can 225 00:24:02,720 --> 00:24:07,319 be either the types strifis meaning that the tut would be of the library will 226 00:24:07,359 --> 00:24:14,920 be compiled and bundled as part of the application, or actually the butt be 227 00:24:15,160 --> 00:24:22,319 pointing to an actually distributed version of the library or already built library. So 228 00:24:22,400 --> 00:24:27,720 it also comes down to how it is configured in your types of configuration. 229 00:24:29,279 --> 00:24:33,440 Gotcha? So if I were to set a particular n X library to be 230 00:24:33,480 --> 00:24:42,599 publishable, then it would create its own built context. Yes, but I'm 231 00:24:42,640 --> 00:24:48,839 not sure if it's I don't requalifyed by default. If it's constructed in a 232 00:24:48,920 --> 00:24:53,519 library, it will be built beforehand or just built as part of the library 233 00:24:53,559 --> 00:24:59,359 of the application. Excuse me? Interesting? Okay, So now getting back 234 00:24:59,400 --> 00:25:06,880 to pure Angler without NX, is there any advisable strategy like I imagined that 235 00:25:07,400 --> 00:25:11,240 inside Google, you guys are dog feeding Angler everywhere, right, So you're 236 00:25:11,279 --> 00:25:18,559 using Angler in many different internal projects, and there's probably a need to isolate 237 00:25:19,079 --> 00:25:27,160 certain parts of your Angular applications into modules. And I mean modules just in 238 00:25:27,200 --> 00:25:33,920 the sense of a folder that contains all the logic related to that particular feature, 239 00:25:33,400 --> 00:25:37,920 so that is easy to just copy and paste and port that to other 240 00:25:38,039 --> 00:25:47,519 projects. How what is the current recommended approach to do this with pure Angular 241 00:25:47,640 --> 00:25:55,599 without NX is to just place those as regular folders inside the application source so 242 00:25:56,799 --> 00:26:03,880 instead and outside Google, Angular is likely different because how you building Lars's different 243 00:26:03,880 --> 00:26:10,599 because internally in Google the Angular cli or annex is not used. We have 244 00:26:10,680 --> 00:26:15,240 our own build system, which is a blaze, which open source is called 245 00:26:15,359 --> 00:26:26,559 Basil, which basically handles everything for us, meaning that you can go as 246 00:26:26,599 --> 00:26:32,480 fine grain as having a built for a component, a single component, or 247 00:26:32,960 --> 00:26:40,759 having a build or library of a single module or a whole application. So 248 00:26:41,440 --> 00:26:48,079 it's quite fine grade of how you can structure the code inside Google, and 249 00:26:48,160 --> 00:26:53,480 in general, if you want to reshare code, it will be its own 250 00:26:53,680 --> 00:27:00,400 build, so it will be a sort of a type of library or in 251 00:27:00,720 --> 00:27:04,640 engy library, and it will have its own built which will be with your 252 00:27:04,680 --> 00:27:11,440 application or your other module will be dependent on the Basil will ah basically build 253 00:27:11,640 --> 00:27:18,119 everything and all the dependencies that are needed, so when you build your application, 254 00:27:18,279 --> 00:27:23,079 it will find all the dependencies that your application needs and it will rebuild 255 00:27:23,119 --> 00:27:30,359 them automatically. Interesting, so all of that in a single progress Yes. 256 00:27:32,279 --> 00:27:37,200 Interesting? Okay, And you mentioned that BESO is the open source version of 257 00:27:37,400 --> 00:27:44,400 place. Do you have any any plans, like the Angler team has any 258 00:27:44,440 --> 00:27:52,160 plans to make it easier for other companies besides Google to have this fine grain 259 00:27:52,880 --> 00:28:00,440 build system or is it just not in the plans? So? Ah, 260 00:28:00,839 --> 00:28:06,799 Actually we did try, I think around version eight or ten, we had 261 00:28:06,880 --> 00:28:14,200 an Angular Basil labs where you could use the NGO cl lie with Basil. 262 00:28:14,960 --> 00:28:22,400 However, that was not super successful just because a Basil needs quite a lot 263 00:28:22,440 --> 00:28:32,160 of configuration and unless you are building a very large application, it is not 264 00:28:32,440 --> 00:28:40,680 beneficial because you will not see that much of a built built gain. I 265 00:28:40,680 --> 00:28:45,079 mean if your code base is small or relatively small. Basil does have an 266 00:28:45,079 --> 00:28:51,279 overhead, so instead of having a faster built, if your application slow is 267 00:28:51,400 --> 00:28:56,680 small, your application built will be quite slow. And there before there were 268 00:28:56,720 --> 00:29:04,559 also some incompatibilities with Windows, so it's definitely not in our plans. Again 269 00:29:04,640 --> 00:29:15,279 too invest in making a Basil a first class citizen of anglar CLA. Okay, 270 00:29:17,039 --> 00:29:19,599 but is this still possible, like even though it's not a first class 271 00:29:19,599 --> 00:29:27,160 citizen, if anyone wanted to use Besio to render Angular builds. Currently on 272 00:29:27,279 --> 00:29:33,559 version seventeen and just going forward. Is that still possible, like, could 273 00:29:33,839 --> 00:29:38,759 a community driven plugging be created? Or yeah, I mean Basic can be 274 00:29:38,839 --> 00:29:42,279 used to build any language, so it can be used to build Go, 275 00:29:44,400 --> 00:29:51,240 Java, fighting anything. Any language can be built used in besil. Interesting 276 00:29:51,519 --> 00:29:59,759 and when it's used inside Google, is it for example, are we talking 277 00:29:59,759 --> 00:30:07,680 about using Blaze just to build an angular co base or is it also very 278 00:30:07,680 --> 00:30:14,440 common to have a back end in the same repository and having the same basio, 279 00:30:14,640 --> 00:30:18,480 the same Blaze process building the front end and the back end. So 280 00:30:19,160 --> 00:30:26,680 in Google there's a single MONORYPO with hundreds and thousands of projects, and there's 281 00:30:26,720 --> 00:30:30,160 only a BIL system, which is where there's one primary build system, which 282 00:30:30,200 --> 00:30:37,480 is Basil, which the same process can build an xt amount of languages because 283 00:30:38,039 --> 00:30:44,000 when you do like Basil built, it can check what dependencies your application needs. 284 00:30:44,039 --> 00:30:45,079 If it needs a back end, it will build your back end, 285 00:30:45,880 --> 00:30:49,759 and if that back end requires some other services, that will build them. 286 00:30:51,240 --> 00:30:56,640 So yeah, can build with the same process an infinite amount number of dependencies, 287 00:30:57,119 --> 00:31:03,279 an infinite amount number of languages. Okay, that's very that's very interesting. 288 00:31:03,359 --> 00:31:08,640 At least look for enterprise companies out there to know that this is an 289 00:31:08,680 --> 00:31:12,880 option. Although I imagine that it could be very costly to set up, 290 00:31:15,519 --> 00:31:19,799 and maybe due to the lack of other companies using it, it might not 291 00:31:19,880 --> 00:31:23,839 even be worth it, depending on how much time there they are saving. 292 00:31:25,160 --> 00:31:33,400 But at least this isn't an option that enterprise companies could consider interesting. Okay, 293 00:31:34,680 --> 00:31:41,839 Alan, we spoke about several things already. I know that there are 294 00:31:41,920 --> 00:31:48,519 many others that we could go into. I don't want to drag the episode 295 00:31:48,920 --> 00:31:55,680 too long just to keep the the main content concise for the audience, but 296 00:31:56,039 --> 00:32:00,559 I do want to open the floor for you and ask do you think there 297 00:32:00,559 --> 00:32:06,240 are any other topics that we should have covered, Like you think they are 298 00:32:06,359 --> 00:32:12,279 interesting and important enough that we should talk about them today, and that perhaps 299 00:32:12,359 --> 00:32:15,240 we haven't yet. Yeah, I cannot think of anything right now, like 300 00:32:15,440 --> 00:32:21,920 it's worth pointing out. Okay, In terms of some of the things that 301 00:32:21,960 --> 00:32:28,480 we were discussing before, we talked a bit about internationalization and runtime internationalization, 302 00:32:29,279 --> 00:32:34,279 and we mentioned that currently there aren't any good official dogs about it. But 303 00:32:34,400 --> 00:32:39,960 I was wondering if you know of any good source as a third party company 304 00:32:40,000 --> 00:32:46,440 that maybe wrote interesting articles about how to do runtime internationalization, just so that 305 00:32:46,480 --> 00:32:51,079 we can send something for the audience. For those that are interested in that, 306 00:32:51,440 --> 00:32:58,640 there is a third party community project that leverages singular internalization and built on 307 00:32:58,680 --> 00:33:02,599 top of it. I think it's called inter Loco. Let me try to 308 00:33:02,640 --> 00:33:08,759 find it. And this library leverages do you run time personalities? Right, 309 00:33:08,960 --> 00:33:19,519 not just the build time. It's actually for the runtime translations. I'm trying 310 00:33:19,599 --> 00:33:30,160 to find it. Mm hmm. Turns slow, but I think it tron 311 00:33:30,279 --> 00:33:45,359 slow into yes, I think I yeah, it was this one. Okay, 312 00:33:46,079 --> 00:33:52,720 okay, I'm going to send this in the comment section. So if 313 00:33:52,759 --> 00:33:58,079 you're listening to the show and there is no comment section from where you're consuming 314 00:33:58,119 --> 00:34:01,960 the show, you can just look for it on YouTube with the same title. 315 00:34:02,039 --> 00:34:07,159 So Alan argues Angler Cli Adventures and Angler, and you will be able 316 00:34:07,199 --> 00:34:10,840 to find it in the You should be able to find it in the comment 317 00:34:10,920 --> 00:34:16,920 section there, but if you don't, it's from the JAS verse, so 318 00:34:17,119 --> 00:34:22,840 JAS from jailascript, so from the Jas versus user on GitHub, there's this 319 00:34:22,920 --> 00:34:30,000 library called trends local and as Alan was saying, this library internally leverages the 320 00:34:30,119 --> 00:34:37,360 runtime capabilities of Angular internationalization. So if you're interested in seeing how you can 321 00:34:37,480 --> 00:34:45,280 add runtime translations into your Angular application, you can look at how this library 322 00:34:45,159 --> 00:34:52,280 is leveraging those functionalities, and maybe even just use the library directly. Do 323 00:34:52,599 --> 00:34:57,280 what would you recommend, Alan, would you recommend using this library or just 324 00:34:57,360 --> 00:35:04,400 looking at how they do it internally? I mean it it depends what are 325 00:35:02,920 --> 00:35:08,400 your needs. If you need something really sophisticated, that might that library might 326 00:35:08,440 --> 00:35:17,239 do it for you. However, the standard API that Angler provides might be 327 00:35:17,760 --> 00:35:22,480 enough. I think there's what There might be also some information on how to 328 00:35:22,599 --> 00:35:30,760 use the I and on the issue that sent in the chat okay sent that 329 00:35:31,400 --> 00:35:37,079 sent this link to for anyone that can't see the link. So inside the 330 00:35:37,400 --> 00:35:45,719 Angular repository on GitHub is the issue number forty six top forty six, eight 331 00:35:45,840 --> 00:35:49,840 hundred and fifty one, so four six eighty five one. If you go 332 00:35:49,960 --> 00:35:54,679 to this issue on the Angler repository on GitHub, there is a discussion there 333 00:35:54,760 --> 00:36:02,480 about how to how to use and time translations with an Angular Yes, and 334 00:36:02,519 --> 00:36:09,559 that issue will be updated once we had more documentation, et cetera. So 335 00:36:09,599 --> 00:36:15,199 if you're interested in no time translation, subscribe to that issue. Awesome. 336 00:36:16,639 --> 00:36:22,440 One other question that came to my mind kind of with small curiosity, but 337 00:36:22,760 --> 00:36:30,199 in recent versions there was a change from Angie dash dash version to energie version 338 00:36:30,360 --> 00:36:38,320 without the dash dash And I'm wondering, why why did we have this this 339 00:36:38,599 --> 00:36:43,119 small change. I have a friend that gets the wrong all the time. 340 00:36:43,559 --> 00:36:47,199 It's always like, ah, forgot about this. So there is a being 341 00:36:47,400 --> 00:36:53,880 that we changed. It was that we changed the entire system that the Angular 342 00:36:53,960 --> 00:37:00,360 CLI uses to build the commands and parce the command line parts one ie, 343 00:37:00,480 --> 00:37:05,599 argue, ons et cetera. So with that change, there were some something 344 00:37:05,679 --> 00:37:08,440 changes that needed to happen, and one of one of those was the Engidish 345 00:37:08,480 --> 00:37:19,400 situation. Gotcha, it's just to improve the parting of another of other functionalities 346 00:37:19,440 --> 00:37:25,199 to not make it confusing with other functionalities. Cool, okay, Alan, 347 00:37:25,679 --> 00:37:31,880 thank you so much. I think this was a very very interesting episode and 348 00:37:31,920 --> 00:37:39,840 we were able to go into some interesting questions about the Angler CLI. And 349 00:37:40,800 --> 00:37:45,360 thank you. Thank you for your time. I think this was very very 350 00:37:45,400 --> 00:37:49,280 interesting, very helpful. I know that for me I was able to make 351 00:37:49,320 --> 00:37:52,840 some questions that, at least to me, they were relevant some things that 352 00:37:52,880 --> 00:37:55,840 were in my mind. So thank you very much. Do you have anything 353 00:37:55,880 --> 00:38:01,719 you'd like to promote like this? The floor is shameless, plex No. 354 00:38:02,239 --> 00:38:06,440 I just wanted to mention one more thing that in the chat, I sent 355 00:38:06,440 --> 00:38:14,360 another library which is basically done by the community and it is done by also 356 00:38:14,599 --> 00:38:22,920 a former Angular team member, which is jax Translate. It was a real 357 00:38:22,960 --> 00:38:30,199 pleasure having having this chat with you. I hope I answered some questions and 358 00:38:32,320 --> 00:38:37,119 yeah, it was really fun. Thank you for having me. Yes, 359 00:38:37,559 --> 00:38:45,199 thank you for me on the show. I'm just gonna promote well actually not 360 00:38:45,199 --> 00:38:50,599 not really gonna promote anything. I think just the companies producing this show. 361 00:38:50,679 --> 00:38:53,960 So again, Top and Devs if you're looking to improve your development skills, 362 00:38:54,239 --> 00:38:59,639 So top and Devs is the company that produces this show and many others. 363 00:38:59,840 --> 00:39:05,039 So if you're looking for more technical content, you can look at topendev dot 364 00:39:05,079 --> 00:39:09,519 com. And if your company or someone that you know is looking for remote 365 00:39:09,840 --> 00:39:15,639 design or web development services, you can look for Void is you and the 366 00:39:15,920 --> 00:39:24,440 OI d so on and Void dot com and they offer remote design and software 367 00:39:24,480 --> 00:39:30,440 development services on a performance basis, so their clients only pay after tasks are 368 00:39:30,480 --> 00:39:35,599 delivered and approved by the customers. So yes, thank you very much, 369 00:39:35,679 --> 00:39:40,079 holland thank thank you the audience for sticking up to the end. Have a 370 00:39:40,119 --> 00:39:43,920 great week and I'll see you in the next one.