Loading AssemblyScript Q&A

[00:00:00]
>> Have you said you know what? Nice job. Now you've so far today you've written Web assembly. You've written assembly script, which compiles to web assembly. And now we're calling that web assembly in our JavaScript. I know there's a lot of interweaving steps in between there to do the work.

[00:00:16]
And that's why we created the loader file to do all that work for us and now we're not worried about it. Now we just fetch web assembly and pull out those functions and exports as they come, are there any questions so far? This is fairly familiar. I really want to get the browser part because I think loading a node is fairly straightforward.

[00:00:34]
Loading the browser does take a bit more work, but that's where as front engineers, we're mostly going to do most of our web assembly work.
>> Is assembly script, strict superset of TypeScript?
>> Yes. It is a I mean, it uses TypeScript to become strictly typed. However, they're not one to one.

[00:00:53]
There are many methods in assembly scripts that don't exist in TypeScript. So you can't quite say they're the same It just uses TypeScript under the hood for the type checking actually, I'm glad you brought that up because let's, let's look at the docs as I like to do.

[00:01:12]
And if we go to assembly scripts in the docs, make sure it's big enough. And we got to basics because they have a part on quirks. Which is it kind of explains some of the differences between TypeScript and assembly scripts where they differ. I'm not going to spend too much time on these because we're not really going to get into them today.

[00:01:32]
But it's good to know like things like triple equals are not the same. in JavaScript those checking those checking for, object to quality or type of quality. Yeah, for whereas in assembly script, it has to be the exact same objects versus in JavaScript, you can have string this as Hello, you have no string says Hello.

[00:01:53]
Are they equivalent? Yes. In assembly script, those would not be equivalent because they're two different objects. There. Entirely different, I'll skip knowability checks, they're not as important, I've mentioned this before, but the tree shaking part, so if you create a function in assembly scripts, and you don't actually use it.

[00:02:14]
It will not get compiled, because it does what's called tree shaking with essentially cutting out dead part of the code that aren't being used for efficiency sake. So if you see that issue like I did earlier, it's probably because you didn't export something if you don't see that function availability, but I like the questions.

[00:02:34]
Any other questions so far before we move on? The question was, I mentioned before that you shouldn't where is that file? There we go. You shouldn't serve from the default root directory you shouldn't serve everything out. In reality if I was doing it, some production code, I would have a slash lasme endpoint that points specifically to my lasme directory where I would fetch those files out.

[00:03:01]
And, in general, anything about web security, you want to be as specific as possible. It's really easy It's simpler, it's for us web developers and say like, yeah, we'll just serve out everything like, I don't have any secrets here, but you may have secrets, you may have like configuration files, or you may just have underlying implementations that you don't want people necessarily to know about and exposed to the public.

[00:03:23]
So if we were doing some production, I would just have a dedicated Jasmine point that only turned out last summer. But good question. We try to try to do some best practices but sometimes we cut corners.
>> Why is the response bad magic number in the western response?

[00:03:42]
>> You're getting bad magic number. I ran into this before. I so though lasme. Binary code itself the file has what is known as a magic number. It's a set of X values that correspond to numbers that just says like, Hey, I'm a lasme file. You know what to do next so that way the, the compiler engine that is running our lasme code in the browser Notice that it's a valid lasme file and it checks for it.

[00:04:15]
I don't know why you're getting that I ran into it before and I can't duplicate it. Otherwise I would. I do like making errors just because you're gonna run into them. Usually when that happens, it means that the file that when you call web assembly dot instantiate or instantiate streaming The file you're trying to pull in is not a lasme file.

[00:04:35]
And generally, you're probably pulling in you might be pulling in like index dot HTML or something like that. So in that case, it's going to complain that it's a bad. It's a bad magic number because it checks that header first of the ;lasme file to make sure it's valid web assembly before continuous compiling And I during our next break, maybe whoever's having an issue, we can share screens because I would like to replicate this because I do like running into issues just so we can solve them for everybody.

[00:05:05]
Yeah, I went on and on about how we shouldn't serve static files from the root directory. And one of the questions that was asked was well, how do we serve? What is the best way to serve lasme files? That's gonna depend a lot on your situation, your server, what type of language you're running.

[00:05:23]
But I'll say in the Express case, let's see if we can whip this up in my server js. So instead of doing other. use with no with no default path. I think we're just going to serve up a regular. We're just going to start with that specific directory.

[00:05:47]
So I. So in Express, I can say other use. And I'll say, /wisdom. Then I can see express static And then I'm only gonna serve from my build directory. So if you're using express that is the that seems to be the best way of doing it. Let me just double check that checking the docs right now.

[00:06:20]
Yes. So if you were going to use if you did want to just serve this specifically, we just served directly from the build directory. And of course in this case, the build directory component contains our source maps as well. For the intrepid people that noticed, and we really do want these source maps because they'll make debugging so much easier.

[00:06:42]
One of the questions asked during the break was when we what happens to the actual opcode that we're using. So in this case, i32 multiplier. So all opcodes inherently when they perform the operation, push the value onto the stack. Actually, let's just pull this up in web assembly studio switch over here, watts.

[00:07:05]
In this case it's an add function, that's fine. So get local I it's pushing that left hand side operator or operators zero. Onto the stack, get local, the next one is pushing the next parameter onto the stack. I32 add is going to pop both values off the stack, add them together, and then return that, and by return I mean it pushes that value onto the stack.

[00:07:32]
So now inherently if we return, and when we return, it's just going to return whatever the value on the stack is. But if we wanted to continue to do operations on in this module, we can say I 32. We'll say const 1. So we'll add 1 and then I can say I32 add.

[00:07:52]
And what this is going to do is it's now popping. It's either this operation is now popping the results of this add operator and this constant so it's going to add one to whatever the value is have. We added four and that's one of the things that makes working web assembly tricky if you're writing it by hand, is you have to remember exactly what is on the stack at a given time.

[00:08:19]
You don't save them as variables necessarily like you would in another language. Thus, we generally try to keep our operations pretty simple whenever we're writing in watt files and web assembly by hand