Hello, Welcome to Adventures in Angular, the podcast where we keep you updated
on all things Angular related. This show is produced by two companies, Top
and Doves and Onvoid. Top and Doves is where we create top and devs.
We get top and pay in recognition we're working on interesting problems and making
meaningful community contributions. And Onvoid provides remote design and software development services on a
tap basis, so clients only pay after the tests are delivered and approved.
In today's episode, we are going to talk about a subject that it's definitely
interesting for most developers, not just Angular developers, but it's also a subject
that seems very hard, at least at first. We're going to be talking
about web assembly and more specifically, how you can write code in Rust and
have that code running in your Angular application in the front end. And well
you already know me. I'm Lucas S. Paganini, your host in the
podcast, but joining me in today's episode is a very special guest. Iv
Guiney is a freelancer in Angular and also Rust, and he has researched on
that subject specifically, so he is our expert to talk about that today.
Give me. Thank you for your time welcome, Hello, Thank you for
having means great having you all right, So let's start with the definition of
things because I true in some concepts that I imagine lots of folks are going
to be at least familiar with the names, so web assembly and rust.
But the reality is that there might be developers listening to us that don't even
know what that means. Right, So maybe we can start with just one
minute quick definition of what is rust and also what is web assembly. Web
assembly is a set of instructions special format, binary format, and programmers can
use languages like c sharp plus lust, rust go to compile from these languages
to special web assembly format and then execute this code at native speeds in browser.
So it's my sound call if you need to execute something that's very computationally
expensive with a huge performance. And some applications actually might use this benefit of
web assembly, as for example, it might be video processing, video games,
LM like large language models, cryptography and things like that. And maybe
it's really not for every web application, but the application that need to do
things like that, they definitely need the assembly. Okay, awesome. And
then with regards to Rust itself, I imagine that most people are going to
be familiar with what Rust is, but for the purposes of our episode,
you can replace Rust with just any compiled language that you want to run code
in the front end, because we will be talking about Rust, but web
assembly itself is not just specific to rest Right. You could be writing code
in c sharp, for example, and then use web assembly to bridge the
gap between or regular front end code in JavaScript and the binary or maybe not
binary, but the compiled code that you have written initially in C sharp or
something. Right, So we'll be talking about Rust because that was your experience
and the technology that you chose to use to create your code, But for
the audience listening to this that might not be fully comfortable with Rust. If
you are comfortable with some other compiled language and there's something in your front end
application that needs to be extremely performant and you can't just rely on JavaScript code
to do it. You need something heavier, or maybe you want to rely
on libraries that don't yet exist on JavaScript, but they might exist in other
compiled languages. Then you can write your code in those other compiled languages and
compile and then package them in web assembly, and then you can import them
in your front end code. Yeah, that's it. Historically, there is
a lot of developers that work with Angular using c sharp back end, and
I think for them it will be especially beneficial to use c sharp as a
source language. Not trust, but because well it happened, like I have
more experience with trust and what about trust? Okay, regarding web assembly,
it's ouse what are the things that like in your definition, when would you
when would you go to web assembly? And when do you basically when is
it a right call to reach for web assembly? Because it's a tool,
and like other tools, you need to know what is the best place to
use it so that you don't over use it, and also what are the
things that you cannot do with lab assembly so that we also know when we
definitely should not reach to it. Well, if you need some don't manipulation,
then you should not use this website. But it's definitely small niche actually
for applications that should use web assembly, And if you are developing a video
game or something like large language model or some ou the editing software, then
performance of JavaScript will not be enough for you. And I mean maybe ninety
percent of or maybe ninety five percent of web applications don't need to addssent,
and those five percent that needed, they are definitely needed. So yeah,
it's a rare case, but when you need it, it's nice to Okay,
makes sense, And in your article you even gave some more specific examples
of when you use it that I think are really interesting for people to think
about some real world applications to it. So you mentioned complicated calculations, cryptography,
even large language models, like if you want to really run your large
large langue which model on the device instead of just making a remote API call,
you could technically do that by importing the the instructions for the LLLM as
the web assembly module. Also image and video editing, games and so on.
So I think those are thinking about those examples. Maybe brings people closer
to scenarios where they in the past we're trying to reach for something and didn't
do what, So that would be a good application for rub assembly. Yeah,
and it has some downsides like be just one size of the compilot model.
Sometimes it's few megabades, sometimes it's fifty megabytes, so some applications just
cannot afford wait, while fifty megabytes web model will be downloaded before step as
an interacting rech users, So it's one of the down sides. Yeah you
mentioned yep, Okay, that makes a ton of sense. All right,
Now let's talk more specifically about Angular and web assembly because generally speaking, well,
first off, anything that we can do with regular native front end code
we can also do in Angler. But generally Angler has this very unique way
of doing things. It's a very opinionated framework. So do we have any
different ways of importing and executing web assembly code in the context of the Angular
framework, Like, does the Angular framework recommends any best practices or even enforces
a way for us to deal with web assembly, or is the way that
we deal with web assembly code in Angular just how it is done with native
front and code. I mean, right now we are closer to the second
option. Now we in Angular can in our Angular applications we can import web
assembly models as they are imported in native in Vanila JavaScript. And maybe a
little bit later, maybe on the next week, full request that was merged
will be released in the next version of Angular, and then we can import
us models directly from Angular code using just world import. And it has beneaded.
It's much easier to do so you don't need a few lines of code.
If you can easier, you can h import model in their way.
But downside of it right now is it will be imported without types definitions,
so it will be like any everywhere and unknown everywhere. So yeah, it's
more safe and not so much complicated too and more h I know. Oh,
it's more set to use the approach that is described in my article right
now. But with the time browsers will improve plementations and then you can use
us models inside Angular without and big types without any additional tools, and it
will be awesome great. Another downside, just to make it clear for the
audience, is that currently the PR that was merged, well besides the fact
that you would have to be on the later's version of Angular because it was
merged on version eighteen right, so you'll probably actually be released in eighteen dot
one, so you would have to be on the later version. And currently
I don't know if they plan on somehow making it work with zone JS in
the future, but right now it is clearly stated on that PR description that
it will only work if your application is not relying on zone JS, which
I believe ninety nine percent of applications are. Unfortunately, still rely on zone
JS because the experimental the experimental zone zoneless APIs for Angular were very recently introduced
and we have had no no incentives to really use them on application. On
production applications, we have actually been been disincentivized of using the experimental zoneless API
because it is so experimental. So I think most applications in production won't be
able to rely on that extra sugar that Angler added to make it easier to
integrate with web assembly, but they can still integrated in the regular way just
using regular front endcode. Yeah, it's only because top level weight is not
supported. Because of that, you need a zoneless application. Yeah. Well,
I know a couple of applications working production zones already, but it's not
the majority of course, just a few of them in the world I think.
But yeah, if you are going to add the vast model to your
application, it actually means that most of the time, it means that you
are creating a new application. If you're creating a new application right now,
I would recommend you goes on less and even if you don't use that assembly
in that application, I recurrently goes onless. Oh that's really interesting. I
know that This is not the main topic of this episode, but I have
not seen any application at least of production applications onless yet, and I have
also not talked to anyone that has had production applications zoneless. So if you
don't mind us getting sidetracked a bit, what makes you recommend that, Because
from what I understand, the Angler docs themselves are saying that this is very
experimental and you should not rely on this technology yet it's not stable. But
are you confident that it is stable enough to use in production applications? As
always happens with experimental things, it depends. It depends on what third part
of the libraries you use, and some of them are not quite radio to
be zoneless. But to my surprise, many angular libraries actually behave quite well
in zone less applications, especially if they are written with on push only strategy.
And if your application is written using only on push strategy, that will
be trivial to switch to the zoneless application, and it takes just maybe a
couple of days to migrate medium size application it is, unless it's not that
scary. But some libraries, yeah, some libraries might not work with Thomas
gotcha. That's interesting. So it's not just a matter of you wanting to
use it and starting a project from scratch. You also have to think about
if the libraries you want to rely on for your project we work for it,
right, because maybe you write your code in such a way that we'll
be fine, but perhaps the libraries you want to import are not going to
work. Yeah, exactly, that's the right now. It's a main pain
point is thons gotcha? Okay, okay, that that is very interesting to
know all right. Now, heading back to web assembly, how does the
tread work with web assemblies specifically, because we have been thought that JavaScript is
runs in a single thread and whenever you want to parallelize work without blocking the
rendering, there are multiple different technologies that different techniques you can use to do
that. So, for example, one of the most powerful ones being service
workers or just web workers in general, because that way you can have your
code running in a separate thread. But how does web assemblies specifically behave If
I import web assembly code and I execute a function from it, is it
going to execute on the main thread or is it automatically going to be executed
in a separate thread of any main tread? And if you don't want to
create lugs during execution of heavy code, it's better to allow it to use
an service worker or web worker. Then it will work in a separate tread
and heavy computations will be executed without well blocking UI. Great, so we
can also import webal assembly code in web workers. Yeah, awesome, gotcha.
So basically, if we want to parallelize things in a different thread without
blocking the main one, the approach is still web workers. And if you
need something to run faster, not necessarily run in a different thread, but
just run way faster than you can go with web assembly. And then if
you want, if you need both things, then you can just use web
assembly inside a web worker exactly cool. And one one specification is if your
task involves a lot of numbers, a lot of numbers crunching, then it
is cool to you. It is a good use of web assembly. If
you are operating with strings with text, then sometimes JavaScript might do it faster
because overhead of colin web assembly. It's not known in web assembly is awesome
for tasks based on depending of numbers calculating the numbers like drawing some things with
audio video, but strings text is a different thing and it's sometimes maybe maybe
better to check if JavaScript is good enough for that before you start implementing it
in brass or sea share. Interesting with regards to this overhead of web assembly,
is it an overhead just on in it or on all function calls?
It's so all function calls. It's it's not huge, like it's not a
few seconds. It's maybe fifty milli seconds. But I mean, if you're
trying to save every every seconds, then some tasks should be done inside JavaScript
and some tasks should be done in web assembly. I mean, if you
want to just create mt five hash, there is no use for web assembly
because JASP will do it faster. But if you need to create some video
game where you can zoom in and zoom out, then jascript has no chance
to do it faster than web makes sense. Now, we also spoke about
the bundle size right, like sometimes you can have web assembling modules that are
just way too large. With JavaScript, we have several techniques to reduce bundle
sizes with web assembly. Do we also have similar techniques? Yeah? There
are. Well, I was working with Rust and there's great too. Wasn't
park and OpEd that help with optimization of wasn't model sizes and interest itself.
Some compiler figurations might help it binary size and yeah, general recommendation is use
fewer generics, use fewer strings for matching, and well you're going to find
more of them by links in my article because it's not the short things to
explain, okay, And in your article the link that we have to shrink
was code size is specific to Rust? Was right. So I was wondering
because when we compile something to have assembly, it kind of loses the reference
of whether it was written in Rust or c sharp or whatever, because it's
almost like, correct me if I'm wrong. At least you have a lot
more experience with web assembly than I do. But my understanding of web assembly,
at least conceptually, has always been similar to what Java does, in
the sense that Java compiles to byte code. I think that's the right term.
And then this is what it uses to be platform agnostic, right,
so that it can run in different operating systems. And I always understood that
web assembly did something similar. So if I wrote the same code and c
or in rest but compiled it in web assembly, I would not have any
references to the original REST or C code. Of course, they would be
different in the final compiled results, just because C and rest are going to
compile the same the same function in different ways. But the web Assembly code
itself is almost like a universal language and not specific to rest or see.
So I was wondering if that specific tool for shrinking was code size that seems
to be at least from a quick glance, very specific to Rust code written
in web Assembly. I wonder if that that package the library also works for
shrinking web Assembly code that was not originally written in Rust exactly because of the
reason you mentioned. After you got web assembly binary file, you cannot do
anything you're going to shrink its size. There are actually two steps. First
is you are compiling from your language like C Sharp or rest inter special set
of instructions. And after that this code really compiled in the binary. And
on the first step you can kind of if you're super expert, you can
manually edit the code generated from compiler from your rasters Sharp code and maybe optimize
something. But for example, I'm not that could and after you created the
by inner file, that's it and you can do anything. As far as
I know. So all the code size optimization tools they are bound to compilers
it's still ANG or scripting or Rust itself. They optimize the size using knowledge
about the language. So it's it's a task that compiler does, so it's
bound to a language. Gotcha. Okay, So if I understood correctly that
specific technique of reducing or drinking the web assembly size of your Rust code,
this is it is not like you run a command on the generated web assembly.
It's more like you run the command on the Rust code before it's turned
into web assembly. Is that yeah, you're kind of yeah, yeah,
exactly, You give some instructions to the compiler. That's how it works.
Okay, Okay, that makes a ton of sense. All right, So,
IVENI, we've been able to package a ton of content in just twenty
seven minutes. I wonder if there are any specific topics that I haven't brought
up but you feel are really interesting to bring up to the audience. Well,
maybe about the Rust itself. I mean, nowadays, if you write
in Typescript and you want to try Rust, I encourage you to do this
because if you write in typescript and you'll follow immutability approach all the time,
and you describe types everywhere, you never use any and then you're almost ready
to use rust actually, because it's quite close to rust code, to be
fair, and it will not take a lot of time to learn it.
If you are used to strict typing to follow it to use immutable data whereas
possible, then as I said, it will be easier for you to start
writing interest great. And what with regards to the syntax itself, I mean
you're saying that it would be really easy. I assume that is because if
you're written very strict typescript, then you're already used to not specifically the syntax
of rusty. It may be very different from how we do how we write
code in typescript, but I think the concept, I think what you mean
is the concept of always being very specific with your types. Is that it?
Or do you also mean that the syntax of rust is also pretty close
to typescript? Not that close? But yeah, what I mentioned is kind
of rules inside the language, the limitations. Typescript brings some limitations with types
and they are to help us, and REST does the same. It has
some limitations. Maybe sometimes it will fight with borrow chain care, but it
exists to help you not to damage here mental health, and because people who
write in Typescript are kind of used to such limitations, it will be easier
for them to meet such limitations in prest gotcha makes sense? Makes sense?
And what we in regards to the syntax itself, do you believe Let's assume
a somewhat experienced Typescript developer, Let's say at least a plain level Typescript developer,
his experiences, his or her experiences have been mostly with web development.
And now this person wants to learn Rust. How long Let's assume that this
person is like fully focused on that that learning journey. They're not bouncing time
between college and work. They just literally pause their life to focus on that.
How much time do you believe it would take for this person pectitiously to
go from zero to at least productive interest. If you wants to create,
for example, API for your back in for your website, then in six
weeks you will be productive and in eight ten weeks you will get your API
ready. That's how it was in well with me and with a couple of
other guys I know. And it's easier when you get help from the community.
And Rust has very very nice community. They help a lot, and
don't be afraid to ask ready to our slack or discord. People are very
ready to help you. Yes, that's very good to know. Okay,
all right, so I don't think I have any other major questions, at
least nothing that I can think of. So if you don't have anything else
you'd like to bring up, I think you can start wrapping up. Yeah,
that's right. Okay, all right, let's just do some quick promos.
Let's start with you. Do you have anything particular you would like to
promote. It doesn't even have to be related to REST or rather assembly.
No, but well, read mind madn blog. You'll find some maybe interesting
articles not only about and rest, by about other topics in Angular such as
signals, change detection and other things and zongless awesome. I have just sent
a link to your article in the comment section. Not everyone we'll see that
because you might be in a in a player that doesn't support comments. But
if you're watching us from YouTube, then there's a comment section there you should
see the link. Otherwise, if you're just listening to us, then you
can look up on Google as powering Angular with Rust, and you will most
likely see if needs article be the first result on Google. Okay, on
my end, I'm just going to promote the two companies that are use the
show. So there are many other podcasts produced by Top and Doves. There
is even podcasts about Ruby about I believe they reactivated the podcast about Freelancing.
Also JavaScript Jabber as a more generalized web development podcast, so highly recommend checking
that out if you're interesting in other technologies. Besides Angular, there's definitely a
show inside the Top and Doves universe of podcasts that is going to be what
you're looking for. And also Onvoid if you are a company or know someone
that is looking for either outsourced professionals to complete a project or a staff augmentation
just to extend your current team. Onvoid offers design and software development work,
and the most interesting piece is that instead of just paying by the hour,
which is what most agencies offer, they have a much more client friendly business
model where the client only pays after the work is delivered and approved, and
the costs are estimated upfront, so you don't have to worry about overtime or
the quality not being what you expected because the costs are defined beforehand, and
if you're not happy with the quality of the delivered work, you can just
request changes until you approve it, and it only becomes bilable after your approval.
So it's a very interesting model. If you're interested in that, just
check out you and void dot com on void to learn more and contact them.
All right, So that's going to be it for me. It Caani,
thank you so much for your time. At least to me personally,
I think this was an extremely valuable episode. This web assembly is something that
feels too hard, feels autograsp for most front and developers, but it doesn't
have to be. And I'm glad that we were able to break down some
of the myths regarding the complexity of doing it. So thank you very much
for that, and feel free to come back anytime. Yeah, thank you.
It was very interesting and good luck with the next episodes. Would be
nice to listen there. Thank you, Thank you very much. All right,
folks, thank you for sticking up until the end, and I will
see you in the next one.