.Net Foundation Virtual User Group, 22 Dec 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: WebAssembly, a revolution that follows - Josip Klaric, BLbit (2020-12-22)

Description

.NET Conf is still in progress! Our next meetup is part of .NET Conf local events. The meetup will be in English. Our friend Josip Klaric talks about WebAssembly and just WebAssembly, no Blazor involved :) During the event, we will be giving away 2 licenses from our sponsor, JetBrains.

WebAssembly - a revolution that follows

Description:
IT technologies and tools are changing from year to year with a lightning speed that is hard to follow, but among all those new technologies, rare are the ones that are causing tectonic shifts in software development. The last change like that was containers like Docker. WebAssembly is surely one of those technologies that will shake the foundations of the IT industry and force all of us to a new and different way of architecting and designing software solutions, and here's why...
WebAssembly is the first totally portable binary format that can be executed on all platforms that support web, or in other words, that support web browsers. The performances are almost identical to performances of native code. On top of that, the features of WebAssembly are greater than their web browser hosts. The enthusiasts that are using WebAssembly or working toward its standardization have quickly realized that it needs to be used outside of the web browser, in some other environment. That's why the draft of the WASI (Web Assembly System Interface) standard has been created, as a definition of calls from the WebAssembly module to the host environment where the module is run. With that, we came to a unique point in IT history. Besides WASI, there are several other drafts for standards that will make WebAssembly even more powerful and safer. During this talk, you'll be able to find out some details about WebAssembly itself, WASI standard, as well as other standards that will change the development world. Of course, we won't just talk. There will be some demos too.

Speaker:
Josip Klaric
QueryStorm.com, Senior developer

Josip is an experienced full-stack developer working mainly with Microsoft-based technologies. His first programming steps made around the turn of the millennium with Visual Basic 6, and quickly embraced the .NET and switched to C# as his main language. Various projects he worked on steered him through a number of different technologies, but most of the time he spent on taming the web-related technologies. Besides that in his daily work tends to use various storage engines and related tools. He likes to follow the software development trends and experimenting with exciting new technologies, especially new JavaScript features and client-side frameworks. In his free time, he likes to spend with his family in any kind of outdoor activity

A

uh Hello, everyone, I hope we have started this time uh so yeah- welcome to the first uh will beat user group meetup of this year, this supposed to be the last makeup of the previous year, but we had some technical issues the last time, so yeah welcome and yeah. So this meetup is a part of the net global.net conf 2020, which is still ongoing. Although we are already in 2021, and today we have our friend jose clarice from zagreb.

A

uh He will be talking about webassembly standard, where we are at the moment and what the future brings. So we would also like to thank our sponsors, jetbrains and dotnet foundation for managing this stream and yeah. Also during this talk, we expect that you have some questions.

A

You can post them on the youtube chat or you can post them to our meetup event, page so we'll collect all of them and the first two people with relevant questions will be given a jet brain subscription for well to use on on one of their products. So yeah.

B

A

Further ado joseph, you can start. Thank you. Okay,.

B

Okay, thank you, miroslav thanks for kind introduction. So, let's start, let me first share my screen to start my presentation, my slides.

B

Okay, just a second okay. Here we are so I will talk about the web assembly and uh uh possible revolution. That's uh that follows uh in I.t industry, and this is uh agenda. What we'll talk about during this following maybe 45 minutes and, of course, we'll start with questions like what is web assembly and why we need it.

B

We'll talk about current state of web assembly, uh then we'll have a short demo uh demo with uh browser and some some small demo with uh in net.

B

We will then talk about webassembly origins, how we came to web assembly and upcoming features, some use cases and finally, we'll end this talk by answering why this revolution, at least in my from my point of view.

B

So let's start, uh why webassembly, uh as we all know- uh and we all use browsers today, browsers- are really really powerful piece of software.

B

They can run a lot of things that was not uh imaginable, I don't know, say five or ten years ago, just uh just in browser, but today they are really powerful, and since we moved our web page rendering from static server side to the rendering pages in a web in web browser to client, we can say that actually browsers are powered by javascript engines and even though they are so powerful, we still have some emerging technologies that will uh imagine technologies like virtual reality, machine learning and so on, but also some heavyweight category of software like video or image processing software.

B

That still requires some more processing power. For example, simple action for of rotating 4k image in various browsers takes various times, as you can see here. uh This is the discharge shows uh a measurement done by some of the google team research team that found that in different browsers, uh this section of simple rotation of 4k image takes from two to eight seconds. We can see the this measure measuring times in this blue vertical bar.

B

uh The other bars are some other technologies that that we are that are not so important right now, but we can see that javascript times where I completely uh totally in the opposite to the to these other engines or languages. Let's say so. We can see actually that uh processing in the javascript is not not predictable. That's the main problem, the main issue uh and what is web assembly? uh It's uh it's a way or a new technology that allows us to run non-javascript code in browsers without any add-ons.

B

We had some tries or running some non-javascript codes before like java, applet or or flash, and these all require some madness. But in this case we don't, we don't need any any add-ons to browsers. We uh browser browsers, have native support for running this kind of this technology.

B

It's a compact, very compact, binary format optimized for download. Also, it is not a machine code, even though it is near native. It has a near native speed and performance, but it's still not native code, because simply we cannot know on which brother on which architecture this code will be running. So it's uh uh it's actually a binary format uh in with intermediate representation, just a little bit with small overhead on top of machine assembly.

B

That will be really run on on the machine that where browser is running so uh when the browser runs this code, it will first compile it for the specific architecture of the machine where the browser is running. So it's not. uh It runs at near native speed, so just a small percentage or slower than real native uh codes, the same native code uh and it can be uh treated as language, uh but generally it's more.

B

It should be more uh treated or seen as a compilation target, because no one will actually write uh by hand any uh low level code like web assembly or like we the same way. We don't actually write any assembly code. We use higher languages for that, and then we compile that code to assembly the same way we will do with the web assembly. We will use our uh higher languages, higher level languages and compile our code to webassembly as a compilation target and, as I said, it's not a language for any specific machine.

B

It's a language for uh for some conceptual machine that will be, as I said earlier, said, compiled to real machine and where will where it will be run. uh Some important, uh important uh properties of web assemblies are isolations is isolation, and that brings us some benefits by default. uh Webassembly is sandbox, uh it is uh it.

B

It is running in uh in us a chunk of memory that is uh given to the machi of the web assembly engine at the start, and he it cannot access anything outside that memory set so uh by by default. It is limited to this uh memory set and, of course, that means it's uh secure. uh We our code outside that is also secure.

B

uh It can be compared with uh some virtual machines because it's isolated from the rest of the system, and actually we have several several levels of isolation in this box. Here I have my uh representation of these levels of isolation. Maybe it's not so nice, but uh we can uh get the picture of these levels in this yellow box. We have all the let's say, memory of the machine in this blue box.

B

We have a browser's part of memory that is assigned to browser by the system uh and inside that uh webassembly will get its own set of parts of memory that is going to run in so anything outside of this gray area for web assembly is not accessible and it doesn't know about it. So what are the benefits of this uh benefits is uh benefits. Are that uh high level languages get some speed and lower languages gets isolation?

B

Usually, uh isolation is actually problem, problematic with low level languages like c or c, plus plus, when they can crash the machine uh by accessing uh accidentally or or intentionally other parts of or the memory uh outside their own space. So in uh when, when this kind of then this code is compiled to them assembly and run it, it cannot cross these boundaries of their own uh memory. So it's safe, it's isolated from the rest of the machine, so uh we also get some strong type guarantees and consistent and reliable performance.

B

Regarding current state of webassembly, uh we uh we have a first version called mvp. uh It's actually point zero uh version, 0.1.0 released in 2017 and it's still not widely used, because it's uh just it contains just a core functionality and currently supports low level languages like c or c, plus, plus and rust.

B

It's still in early stage, especially regarding the tooling, because currently you have to a lot of things you have to do manually like accessing or managing these uh memory uh parts that we were talking about and uh handling, uh let's say strings.

B

It currently supports only uh number types, meaning uh integer and floats, and they're 34 or 60 for 32 or 64 variants. So that's simply it's low level and it's uh operates only with numbers, but still all popular languages are interested in supporting it and there are lots of new features that are coming to webassembly that are currently being standardized.

B

So, let's go to simple demo to check to see what how it, how actually web assembly works, but before going to code, I will start with with this site called web assembly studio. That is actually the best or easiest way to start with web assembly or playing with the assembly. uh You you get on this site when you get to the site, you have. You got some id like uh ui, where you can choose one of these template projects.

B

I will choose, select this empty c project and simply start push this create button, and we will get some uh templates with simple main method that returns this number integer. We have some uh defined html that uses that actually doesn't contain anything except using this javascript javascript file that is defined here, and it has some container here.

B

This javascript here uh defines some uh interaction between javascript and and the web assembly, and when we run this, we will get some output here. We get this 42 that is actually defined here as a return value from this method. uh Our example is uh based on this. You can simply download this project and I've done that and made some adjustments to that simply by adding some a few additional methods.

B

This is the main that returns the same 42 number. uh I I've added these two methods just to see how. How can we work? Actually, with, for example, with strings and how we uh call methods with parameters here, uh as you can see, we have here the same, not the same, but very simple, similar method like here. We only take two arguments and return them as uh add them together and return the results. In this case we have this screen agreed method.

B

Maybe I should make a code a little bigger, yeah, okay, and we can see here, uh I'm simply returning from this grid method, uh string, hello or in this case window even days. It's uh still my uh uh from my older presentation, but anyway, uh in this case uh I've added to this html. I've added a few more paragraph elements using the main javascript file that is defined here, and this file contains following scripts javascript code that actually fetches our main wasm file.

B

Usually, when you compile wasn't uh webassembly code, you get the the output is vason file or binary file with wasn't wasn't extension. We load that then we create array buffer from that response. After that we use these bytes from array and call instantiate method on webassembly class.

B

That will also then produce our us some object that we have uh that we can access instance from that and that, on that instance, we have exports. Exports are actually methods that we have defined here in in our main c file, uh so yeah main c. We have these main methods, uh add method and grid method, uh so how it works. As you can see, we simply here in these two cases main ads.

B

We simply call that these methods and provide parameters for this method and the result of this method is assigned then to this dom element as their content. That's it so since, in this case, we are returning integers, we can access this uh return value directly and uh write it to this uh dom element content.

B

But if we are going calling this method grid method that actually returns us uh some complicated structure like string as we said, uh the web assembly usually uh not usually actually works with only with uh numbers. uh We have some different way of handling string strings. uh In this case, uh we are calling we have to first prepare uh this array that will uh again from exports. We can access access it from memory, this memory buffer and in this buffer. We uh actually we will um just we will in this.

B

uh When we call this method grid, we will get pointer to the position in the memory where the where this uh string result of this method starts in this buffer in this memory buffer, and then we loop through this buffer check every character, uh every uh byte, if is that uh bytes uh null null color null character or not, and if it's not, we simply concatenate the message here and that's that's the way how we actually get the message from our string from this uh grid method.

B

As you can see, we directly operate with bytes uh in the memory of the memory and it's simply so low with uh when you work with uh uh with strings uh and and web assembly, and then finally, we assigned this message that we concatenated from the memory to this uh dom element and displayed, and now, if I run it, we'll see the this result. Okay, I have to navigate to file html file, and you can see here it is. uh We have result of main method.

B

We have a result of add method here and result of a greeting here. I use actually a different uh version file compiled in the in for this example. uh But since I have these, many, as you can see, have different versions of this main. I usually, I obviously use the the one here with bella bit, but here I used here is still stays within this, but anyway you get the point.

B

uh Okay and let's go now to uh another example of how to use the same wasm file uh with dotnet. Actually we usually we use. When you talk about that assembly, you immediately think of blazer, but blazer is. uh I will not talk right now about blazer, but uh how actually we can use web assembly without blazer in our console. App in dot net is pretty much the same uh same principle as we saw with javascript we've.

B

uh As you can see here, uh we I'm I'm using I'm reading this file as a byte reading all bytes from this file. Here main version is actually the same version file that I use in in this html example and use and load that into module, but that module.

B

I have to explain that is defined here in uh in this wasn't time package npm package, it's still in preview, as you can see here, you can download that from nougat and use it but, as I said, it's still in preview and it's still being developed, but it's developed by official organization called byte alliance. Now who is actually caring about uh webassembly and razi as standards?

B

Okay, and uh now we create uh hosts for this uh uh of web assembly. uh As you can see, we are using dynamic in c sharp here we create uh instance of the module uh and then simply call from that instance. We call this methods main here again and add here and here in this uh grid method. We call the we have a core here. We get the pointer here. We access the memory here and from that memory we have.

B

uh We read the string from the memory using this pointer, meaning that this this method is actually implemented inside this nougat package. So we are using this method to uh read all the strings or all the bytes, uh starting from this pointer to the until we reach node terminator. So we can have.

B

I don't know how many bytes that are uh that contains actually string and the rest of the bytes in memory contains no terminators, so it will read only those things that start with this pointer and end with the first terminator null terminator, and we will get this grid message and display it here. So if I run this codes, we will see actually that we have the same result here, main method.

B

You can see so it's displayed here. We have add method. Okay, I'm using these different parameters now and hello bella beat uh as a great message. Okay, that would be so uh all from the regarding the demos. Let's go back to slides and okay just second, so uh we will we'll talk now about webassembly origins.

B

We can't actually talk with uh about webassembly without uh mentioning or talking first about javascript, uh because javascript is the reason why we get the way we have webassembly.

B

Now, in the beginning, when browsers started using javascript or when javascript was created in 1995, it was interpreted and it was pretty slow and it was, let's say, stayed that for a long time about 10 years until uh we came uh to web uh to v8 javascript engine that was released uh in 2008 or end of 2008 in chrome, and that made the javascripts much faster uh because it was using uh jit compilation.

B

So uh it was not just interpreting the javascript code. It was. uh It was using that uh code and compiled that just in time when the when this time, when this code was running, uh others other browsers, follow their uh also introduced their own compilers, because that was that was the uh area uh age when, if you remember that we all as a developer, started using more and more client-side rendering, instead of simple, simply calling or requesting servers to do the rendering and just showing displaying pages. That was the uh age.

B

When uh ja, when jquery was started to be popular and uh we got all a new uh client-side engines like backbones started. I think first or you know the the the history, but uh generally all the uh excitement, let's say moved from server to to client and a lot of attention was moved to browsers and made making the website more interactive and more responsive to users, and one of the issues that we still have, even with this jit compilation that we have with a v8 engine and generally with on with their uh javascript compilers.

B

Is that dynamic types that that we have in uh javascript? That's are really something really cool for someone uh who likes javascript is actually something that, on the other hand, is affects the performance of the javascript.

B

So, as we said earlier, we cannot have the the consistency and reliability in the code execution simply because in many cases any variable can be anything just like in this simple function. We have on this on the inter on the right. We have add that method that accepts two parameters uh x and y, and we can pass x and the numbers and uh to x and y, and also we can uh pass things to x and y and we will get perfectly viable result from that function.

B

But uh when you think about it, regarding in in from the perspective of machine, it has to simply uh represent those numbers and or those things in memory, and if you constantly switching between uh in the same function between uh numbers and strings, it simply cannot be so performant.

B

So that's something that uh that is in javascript nature and uh guys in mozilla actually wanted to uh see. How can they improve uh still move further with javascript performance and they found some set of tricks to actually improve the performance and they call that asm.js and it proved to be a much to have much better performance and much more better consistency in performance.

B

The same function we saw earlier uh written with this asm looks like this, and you can see these uh logical or oring, with uh or or with these, both both of these uh parameters x and y uh with zero, uh and also with uh this result of the addition we also uh or with zero.

B

What does it make? uh What does it mean that actually uh give the some give some clue? uh The engine behind that compiles the javascript that these numbers are actually integers. So um uh these operations, as just to be sure we don't doing this operation, we don't uh make any changes to x and y.

B

We simply uh make sure that these are integers and the same uh for the for this return value, so that actually gave some speed boost to uh engine that uh it can be sure that that this function will always uh use numbers and uh do uh simply uh better, uh compile better and better optimized code for this for this function in in future, when it runs.

B

When you compare this process of uh webassembly and the javascript, we have these two, let's say phases.

B

This upper diagram shows the phases of javascript code that goes from transferring texts in textual format from the server then parsing on on the browser in browser, then interpreting, then executing and then jit compiling and the same process actually has to be done with uh with web assembly. But instead of uh it's a it's, it's actually a bit different.

B

uh It's not not called the same way because it's uh it operates on different type of data in in this case in case of webassembly, it transfers binary file, which is by by default uh smaller than textual file. It compiles that, uh but that compilation is much faster and much easier than interpreting and parsing this uh javascript, because its web assembly code is actually prepared on the server uh for for this um in intermediate language.

B

That is much easier to compile the machine language than doing all that process on the on the fly in on in javascript engine and finally, we have execution on webassembly. That is also, uh in certain cases, uh simply much faster than it can be in javascript, so generally, success of javascript open doors for new standard. Instead of going to doing. Instead of going for more tricks or annotations of javascript, they simply decided to create new standard that became finally uh webassembly.

B

So um what is wazi razi is a that. It became it's actually one feature that became uh so big feature that is uh now treated as separate standard because uh it will allow- or it allows webassembly to run outside out of browser.

B

So the same thing that we can compare that to maybe node and javascript javascript was also meant just to be running on in web browsers, or there was some awesome. There were some implementations of javascript outside the browser, but generally with v8. We uh got some new opportunity for javascript to run on server and we got node. The same thing is happening with uh bitweb assembly.

B

So since it's a really uh appealing format, binary format and with good performance, simply uh people who are working with webassembly, so the this as a chance. Why not run it outside the browsers browsers in their hosts in some engines that will uh act like a web browser, but we will run our code without actually browsing, so it will allow communication uh to communicate webassembly module to communicate outside of this sandbox it's running on and it will uh access some.

B

It will allow some access to certain system resources uh system calls like accessing file, system, opening network connections uh accessing cryptography or using clock, or some some other system calls.

B

uh Currently, we have used cases that uh for web assembly that are mainly related to porting, existing c or c plus plus code base to webassembly. Mainly these are games. I know few of them like quake or diablo.

B

The other is autocad lightroom by uh by photos or by adobe or using uh some, let's say, image codecs that are missing in web browsers, like web p, to enable browser to let's say render these. This kind of images uh example of usage uh real usage of web of webassembly is.

B

We can mention with shopify that they use the the webassembly infrastructure to use to allow their customers to plug in their own code and their own specific business logic to their and run that logic inside their uh platform, without any sacrificing any uh performance and also possible security issues. As you saw since web assembly modules are separated or isolated from the rest of the system, they can safely run these modules inside their platform without any risks and as they say, single worker handles over 1000 requests per seconds.

B

Fastly is another example of usage. Web assembly usage or fastly is uh use is a company that started as edge computing company or actually started as a cdn network of computers and with webassembly they expanded their uh business to edge computing. Since.

A

B

Noticed that they can use webassembly from the same reasons as a shop, as we mentioned for shopify, to run some code not just to host some static files to also run some computation com, computation or code on their uh network nodes uh around the world, and uh it's simply uh because it's uh affordable and easy for them to to compute to manage uh all these uh computation because it doesn't it's fast.

B

It's performant and this doesn't require, uh let's say some big servers to to accommodate that uh and they're especially uh proud with their own lucid engine that have a quick startup time under 60 microseconds compared let's say for with nodes process that needs about 5 to 10 milliseconds.

B

This is microseconds, so 60, microseconds versus 5 or, let's say 10 milliseconds. So it's a big. It's actually a huge uh difference, uh and one interesting thing is that they uh spawn a new instance for each request to their computational uh uh network. So you can see how how the web web assembly are. Performant.

B

So why it's uh revolution?

B

uh First of all, it's a revolution because is a it is a cro cross platform, real cross platform format, it's uh isolated, as we said, and today we simply uh used to use uh isolation in on various uh in various architectures, like we use, docker or or some other ways of virtual machines to isolate things and it's.

B

It is especially suitable for serverless scenarios where the the webassembly office solution for this cold start issue, because that problem, when you uh that we have with all uh these cloud, functions that if they are not used, they need some time to start and so on, but with uh with web assembly, this problem is actually solved.

B

um The other another point: why why this is at least I consider it as a revolution is so called developers united. I call it because we will. We will have a chance in a recent future to have single repository for all languages, that we will share our uh components and modules between uh all developers.

B

Let's say in the world: if, if the goal of webassembly uh will be achieved to all of us to uh simply compile our code into webassembly as a comparation target, and we will then push that code or packages or razor modules to certain depository like mpm and be able to use it anywhere on any platform and with wasm uh with vaazi, we will also have granular security.

B

That will also uh solve these issues that we have that we can have with using uh different uh npm or generally packages code packages that we don't own and that may be insecure for our usage. But what we have some solutions for that and vazi by itself is also a huge uh feature that will also uh revolutionize the way we architect or or our solutions. uh You know in future just to prove that uh we can see the this uh uh tweet by solomon hikes, who is actually uh creator of docker.

B

Who said that if we had this uh wasm and wazi uh technology in 2008, we wouldn't have need to create docker. So it's that huge if solomon hikes thinks that I think we can also, we can trust him. So that would be it from me.

B

Thank you and I will stop sharing now and answer some of your questions. If you have.

A

Okay, uh thank you asip. It seems that we don't have any questions so far.

A

I'm still waiting. I asked him a few minutes ago. If there are some questions but yeah, maybe we can ask you uh some. So what do you think about the future of javascript uh after after web assembly?

A

So will it uh will web assembly affect javascript future or not.

B

I am pretty sure that it will, but it will not be it will be gradually not like uh from tomorrow. We stop using uh javascript and of course it's not going to be like that, but in my opinion, uh web assembly is really is actually offering so much possibilities for all of us all developers and I think in recent future. It will uh be so feature rich that we will have no need actually for doing anything in uh with javascript if you're doing something with uh that assembly.

B

Why not do it all, but generally it's uh creators of webassembly doesn't don't think of it that way they they simply see a webassembly as a replacement for some certain specific uh tasks where javascript may not be so performant like very computing.

B

Compute extensive uh tasks like I don't know, computing some algorithmic hashes, or something like that, cryptography or or part of your site that have some complicated logic or complicated computation to do without going for that to the server you can implement that in a web assembly and call it from javascript and just use the result in further in javascript.

B

But as I said in my opinion, when you simply when you try web assembly and see what it can do, I think uh people will simply stay in that uh area and uh generally javascript is also not meant to be used in on the server when it was created. But now we are using it everywhere.

B

So it's it's difficult to predict that, but in my opinion, webassembly will prevail in web development in let's say recent years, but not maybe in two years, but in five years I think it will be much more.

B

um How to say uh visible uh in in the web present or better to say.

A

Yeah thanks: okay, we have a few more questions, so here is uh this one so dom for vasm. How long will it take?

A

B

Think document.

A

Object model yeah.

B

Yeah, uh actually it's uh it's uh it's accessible or you can use dom uh from web assembly right now, it's uh as we. So maybe I didn't talk about that completely, but in general uh webassembly offers you uh have this concept of importing imports and exports, and you can usually you export the things you want to call from javascript to be callable from javascript, and you also can in import things in in your web. Assemb uh yeah your webassembly module, and these things uh is actually a dome.

B

Access is one of the things you can import to your web assembly module and then manipulate with dom just almost the same way. You do with.

A

Javascript thanks, so we have a few more questions, uh so this one is from sakeeb. So what limitations does vasm have beside? It needs to run in a virtual machine.

B

Limitation uh cut: there are some limitations like uh uh it's currently working on a 32-bit bit space, so you can't have a file handle file more than four gigabytes or something like that. It's also uh in this first version it doesn't support uh threads but, uh as I said, I didn't actually skip that slide of features that are coming to web assembly.

B

There are a lot of proposals that will be uh in next uh that are currently being standardized and will be soon uh uh present uh or released in uh next version of webassembly specification, or also uh this uh uh how it's called host bindings. It's called this access to actually all uh apis web web browser apis will be accessible to webassembly. So, basically, you will not have to uh use javascript uh for anything you you can access anything uh from directly from uh webassembly.

B

There are also the ones important or or a big feature that is coming or is it's called simply? It's thing, it's short for a single instruction. Multiple data simply means that you it's a thing related to a processor architecture. When you, when the processor offers you some instructions that can operate on a set of bits, the same operate. Do the same operation set of bits instead of doing one by one, so it's uh yeah in some cases, especially for I don't know image processing.

B

It has a big impact because you are actually doing or in most of cases you are doing the same or very similar operation on multiple uh pixels that that can be done in a in one pass or instead of doing one by one.

A

Okay thanks, so I think we have one more question from andreas. uh So what's the performance difference between vasm and javascript, approximately yeah.

B

Rules, yeah, okay regarding performance uh generally, it it depends, but if we want to be honest uh at their peak performance, uh javascript and webassembly will actually be optimized just as native code and be performant as native cos. So there is no win in the in in the in that situation, but that's an ideal situation and it's usually not the case that you have that optimized completely optimized code. As I said, it's very difficult to optimize javascript code, because it's simply too dynamic and allows you everything.

B

I mean changing variables from time to type and that's that cannot simply cannot be optimized, but generally uh it should be. Performance uh should be improved in favor of webassembly at least uh two times. That's minimum uh but, as I said, it depends very depends on the on the situation on the code that you are running in a web assembly. uh Up to, I don't know 30 30 times faster than javascript, so that really depends on on your situation.

A

Okay, thanks yeah and just one more comment uh for the end, so srivandra hope I pronounce that right asks for the slides. Okay, yes,.

B

Of course I will should we will uh agree miroslav to uh can.

A

We compose them to meet up yeah.

B

A

Event, I added the link in here yeah. Okay, no problem, yeah, okay, that is it. I guess there are no more questions uh so for the first uh two questions from rizman and uh who had the second question: uh shivandra yeah.

A

So could you please contact me either to our bellabeat meetup page or send me an email directly to miroslav.popovics.gmail.com and we can send you the licenses for or a one-year subscription coupon for jetbrains products so and yeah? That's it uh joseph. Do you have anything to add?

A

No, no from nothing from me. Okay! So thank you very much for for the great presentation and hope to see you soon live no problem.

B

Present my pleasure.

A

Yeah, thank you all bye. Thank you. Bye. Thank.

B