AssemblyScript - HTTP 203
ฝัง
- เผยแพร่เมื่อ 15 ก.ย. 2024
- Surma gives Jakes a quick-start to AssemblyScript, a TypeScript-like language that compiles to WebAssembly. Is it faster? Smaller? Better? Will it kill JavaScript? All that and more in this video. Maybe. I don’t want to over-promise. Managing expectations is important, you know. Still reading this? Wow you are committed! Leave a comment containing “🐿” so we know that you are a dedicated video description reader!
Get started with AssemblyScript → goo.gle/assembl...
Other videos in the series → goo.gle/HTTP203
Subscribe to Google Chrome Developers here → goo.gle/Chrome...
Also, if you enjoyed this, you might like the HTTP203 podcast! → goo.gle/HTTP20...
#HTTP203 #ChromeDeveloper #WebDev
v=WebAssembly.instantiateStreaming(fetch("data:application/wasm;base64,AGFzbQEAAAABCAJgAABgAX8AAgcBAWEBYQABAwIBAAUDAQABBxICBXN0YXJ0AAEGbWVtb3J5AgAIAQEKCQEHAEGgCBAACwszAgBBjAgLATwAQZgICyUBAAAAJAAAAHMAdQBiAHMAYwByAGkAYgBlACwAIABwAGwAegA/"),{a:{a(A){v.then(({instance:i}) => alert([...new Uint16Array(i.exports.memory.buffer,A,15)].map(A=>String.fromCharCode(A)).join("")))}}});
convinced.
NOICE!
I am
But but I'm already subscribed tho lol
Are we nerds?
Now web assembly is back in the top 100 things I need to learn this year! Great video! 🐿
Vision: Deno supports writing applications with TypeScript and AssemblyScript files, interoperable via ES modules, and the Deno toolchain handles the rest. The result is a great developer experience when writing apps that make appropriate use of Wasm and JS.
Would even make more sense on serverless like fastly terrarium
18 minute is very important. It’s historical moment in web and more than web
Shout out to jake for being a good sport. Played along on take 3 like a champ
I"m not totally nuts 🐿about AssemblyScript but I like the Typescript like syntax. It will be interesting to see how it's used in the future. Thanks for the video.
Great video! I just couldn't decide which one I like more, WebAssembly or that bobby pin holding Surma's microphone in place :D
Not those eyebrows?
Wow, I'm really interested to see where this goes 🐿! Do you know if this will have any possibility of future use with WebXR? I could see how that may be a performance-sensitive application on the web.
If its not typescript to wasm why are the file extensions named as .ts?? This would simply confuse people!
so how much overhead does the *glue* code introduce? Are there cases where just JavaScript is faster?
Thanks Devlopmen
Devlopmen devlopmen devlop devlop devlop men men
@@jakearchibald stuck in a devloop?
@@jakearchibald Devlopman Devlopman does whatever a Devlop can
I do, as I am told 🐿”
There's also Kotlin/Native and Kotlin/WASM (in progress) which uses automatic reference counting to basically not need a garbage collector. Kotlin itself is a language that resembles both Java and TS and has definitely been inspired by both and so it could be interesting to check out. I'd actually be very interested to see if you guys could make a Kotlin episode once just exploring it a bit since it is even heavily-backed by Google
Most all GC languages also use ref counting. But all still do need GC because of cyclic dependency. Ref counting is but a optimization to ye olde GC, can’t get rid of it unless you manually deal with cyclic refs like swift make you do
@@cat-.- well my comment is now a bit outdated because Kotlin native is getting a new GC based memory model. However, they used to have automatic reference counting like I said with also a circular reference breaker that would work at runtime, but would not function as a GC
Strait assembly script is really nice. Just like ts but strict
assembly script is awesome. but it would be more awesome if it moves a little on the functional part of the programming too
Interesting! Thanks for sharing! 🐿
Please do an episode on Rust!
Spring is coming, squirrels are waking up 🐿
Learned something quite useful as always 😊. How does web assembly compare in terms of performance with typescript assuming all types are well defined? I’m trying to understand when to consider web assembly for better performance, when starting a new project
Well, this was interesting 🐿
Btw. wouldn't WASM's perfomance be (potentially) much better than JS because the compiler can actually optimize before running in the browser?
It can get to higher performance _quicker_ because the code can be optimized before running. But they both can be equally optimized to the same machine code (I am oversimplifying a bit here).
Generally speaking do different binary toolchains perform differently? I.e. would a WASM binary compiled from C/Emscripten outperform from Assembly Script? Or does it not matter once it’s compiled to WASM?
🐿️
I read descriptions
Thanks for another great video great video guys.
For the benefit of others that might be following along and encountering problems, here are a few observations. I am using VSCode (and specifically vscode-live-server).
1) There is an outstanding issue with vscode-live-server (#202 Please fixe content-type for .wasm) where using WebAssembly.instantiateStreaming causes the fault:
"Uncaught TypeError: Failed to execute 'compile' on 'WebAssembly': Incorrect response MIME type. Expected 'application/wasm'."
This is because the wasm file is not "... returned with an application/wasm MIME type by the server." as instructed by the MDN documentation. A work around is to replace the instantiateStreaming with instantiate on the fetched arrayBuffer, as follows (thanks to Lucio Paiva at stackoverflow.com/questions/50589083)
async function fetchAndInstantiate() {
const response = await fetch("./main.wasm");
const buffer = await response.arrayBuffer();
const { instance } = await WebAssembly.instantiate(buffer);
console.log(instance.exports.main());
}
fetchAndInstantiate();
2) I also encountered an issue with importing the @assemblyscript/loader using the simple call:
import { instantiate } from "@assemblyscript/loader";
After installing the loader from npm I found I had to use the following to get it working (almost.)
import { instantiate } from "./node_modules/@assemblyscript/loader/index.js";
I also tried importing it directly or from a CDN, but the above was the only way I could get it working. However, it can be copied up out of the node_modules folder.
3) I could not get the fourth example (alert string) working at all. I confirmed the wasm was including extra (runtime) code but execution refused to find the __newString or __getString functions. Inspecting the instance object in the browser confirmed the object's exports property did not include these additional functions.
Found the issue.
Instead of:
const { instance } = await instantiate... it should be,
const { instance, exports } = await instantiate
and instead of:
instance.exports.main(instance.exports.__newString("World"));
it should be,
instance.exports.main(exports.__newString("World"));
using the export returned by the instantiate call.
Amazing video y'all! 👏😊🎉
Very nice. 🐿
🐿️thank you as usual ☺️
🐿️
🐿 awesome stuff
"Its not gonna work like you'd expect typescript to work"
Haha, no one knows how typescript will work because we don't have current version of typescript specification!
Nice cup, Jake!
Excellent job explaining what WASM is all about. But if the main point is using existing code that run better in typed languages, then there's little point to AssemblyScript. Nothing is written in it and it's very unlikely that anyone will need to reinvent the wheel where there are libraries doing the job already.
If only someone made a video explaining why something like AssemblyScript might still be useful...
@@dassurma I might have missed that point from your video. But the fact that there are plenty of dialects to develop from doesn't solve any real problem. Nobody invented C# because Java couldn't get the job done already. And nothing in functional programming solves something that hasn't been dealt with a zillion times in OOP. Learning a new dialect with very little base makes a very poor business case. If you'd like a high performance library, you'd stick with a high performance language with as many existing solutions already (and many skilled programmers). I myself am a TypeScript guy. I am fascinated by the fact that I can get something done with WA without learning a new language. But for the life of me I still can't figure out what, that I haven't seen been solved in plain old JS already. Would I like a client-side video renderer? Sure, why not. Would I want to write it from scratch and in AS? Of course not. That would be madness. C/C++ has already got that covered. It would be easier to learn C/C++ and work with their libraries instead. You'd have an easier time hiring lower-level language programmers to any job done, than to teach high level coders to do something they never ever tackled. Does it mean that nobody should invent anything? No, but the use case needs to be there upfront, solving a real problem, not just a potential on a whim.
@@MrGilsteiner AssemblyScript is quite practical, but main usage currently is outside of the browser. Most of the existing languages such as C/C++ or Rust were created for native targets and this imposed certain issues - a POSIX-compatible standard library, LLVM which has low compilation speed even without optimizations, its own ecosystem and tools. Basically that C++ needs Emscripten and Binaryen (part of emscripten). Rust, in turn, needs wasm-pack (also use Binaryen internally) in order to get a satisfactory size of wasm-modules should suggest that not everything is so smooth. AssemblyScript does not require any additional work or extra compile stage / toolkit because AssemblyScript designed for WebAssembly in mind. You don't need to learn a new language, new ecosystem, everything is installed through npm and even compiles in the browser. A very compact standard library and builtin Binaryen into compiler produce one of the smallest wasm modules. Regarding the fact that a lot of modules have already been written in JavaScript. Yes it is, but no one is forcing them to rewrite to AS. Unless if you are not satisfied with their performance =)
@@MrGilsteiner Another misconception is that any C ++ project or Rust project can be compiled to WebAssembly without any changes. By the way, this is not entirely true
what is squush thing?
squoosh.app is a website you can use to compress images and convert them into various formats
7:27 - last i check there is no GA in WebAssembly
Hi there
🐿
Ahem.....c# too
🐿 , read somewhere that web assembly runs in its own sandbox environment, does that technically mean we’re introducing a bit of concurrency by using both web assembly and JavaScript?
No, it runs on the same thread as the thread it is invoked on, but it is sandboxed in terms of memory and APIs it has access to.
very cool. Would it be possible for a javascript library to use WebAssembly without me including anything in my html file?
Depends what you mean by 'anything'. If the response has no body, how would it know which script to run? That would depend on a way to load and execute JavaScript using an HTTP header, and I'm not aware of a way to do that, or what the benefit would be.
@@jakearchibald I was thinking that the author of an image transformation library could use WebAssembly to optimize their library without me even knowing about it. Maybe this is already being done idk 😅
@@Manivelarino they can already do this by fetching the wasm from their JS
🐿🐿🐿
Wow
“🐿”
Jake can replace Sheldon in BBT.
You guys make awesome videos.
Ban javascript! Rust should be the default source for WASM!
TL;DR : we need to copy the types from TypeScript in to JavaScript, so V8 can make it as fast as WebAssembly.
That is not at all what is being said in this video.
@@dassurma I do actually wonder if it'll be possible to somehow encode type information into JS (maybe as a new standard) so that then V8 or any other engine can read that type info (that gets generated by ts but can also be generated by any other language that transpiles to JS ) and trust it maybe or at least use it as a hint as to how it can optimize the code right away
@@dassurma well you start saying that the only reason to use WebAssembly is speed because JavaScript don't got types, and to get the speed you need to use this big thing that force you to use types. so if the reason is speed and we can get the speed if JavaScript has types(with a flag?) what did i miss @Surma ??
@@voidspawn2351 you missed the slide with 4 different reasons to use WebAssembly. Performance is just one of them.
@@dassurma well, as you said there is no existing code base for assemblyScript, and then it is speed and more speed, and the binary size thing, and the binary thing is a bad thing, the way most JS dev has learn JS is by peeking in to the source at other websites, as i see it binary is a way to close the web, so again there is speed and more speed left, i am really trying here ... i don't see what is wrong with the first comment, the existing code is only c/rust, and it is slow to connect to/from WebAssembly to JS.
🐿