It's a shame that many developers don't want to learn both a language like JavaScript and one like C++. Personally knowing both has been quite the learning experience and helped me become a better developer. Overall they are not that difficult to learn once you get a general understanding of many programming concepts.
The context switch from a dynamically typed, garbage collected language to a statically typed, manually managed language is the key issue here. C++ and JS share a lot of syntax, yet switching between them is much harder than JS Ruby or C++ Rust. Both can be learned but being productive in both, at the same time, is another matter.
Personally, I find that JS and C/C++ share too much, so they collide in my muscle memory and I end up with other issues. On the other hand, Rust and TypeScript have both enough difference and enough similarities that I can write in both without... writing both in. Using both Rust and TypeScript alleviates some common issues, but not all. Having only experience in JS causes issues, as does having only experience in Rust or C++. All of them follow their own information, but not all of them have all of that information available right away.
Sometimes the gap between is more distracting than compressing the information via playback speed. I recommend for smoother comprehension playing at 1.5 or 1.75 for optimal gap filling. Your most likely able to hear the whole more clearly
Once GC is supported and WASM supports web api natively, that makes writing web apps in languages othert than js possible, that means someday in the future, devs might write web pages in C/c++, in rust, in go, in python, in java, even php if it supports full type system. Good Job
One of the things I was excited about with WebAssembly was the ability to share code across desktop/mobile in a more performant manner. Having used javascript across platforms it just isn't performant to go back/forth between mobile platforms and javascript. React native may help alleviate some of these concerns, but the situation remains that we don't have a common language across all platforms native to that platform. WebAssembly seemed like it could bridge that concern, but I'm not sure if that is a target use case?
I think your use-case fits the goals of WebAssembly, although I agree that it wasn’t the most _prominent_ use-case. Seeing how people are now building desktop runtime and even entire OS’es with WebAssembly, the portability aspect is definitely getting more traction than before.
Because of statically typed language, we created a dynamic scripting language so that we could write and make UI more interactive and now we are moving again back to staticly typed language but how feasible it is to manipulate DOM using web assembly tech. I hope there will be a bridge for JS dev like us who don't know c/c++/Rust and still can take advantage of web assembly.
I mean, that is _literally_ what my entire talk was about. If you don’t want to learn another language, take a look at AssemblyScript, which allows you to use WebAssembly by writing TypeScript. I also mention that both Emscripten and Rust do API tunneling to expose browser APIs in WebAssembly. If you want to see an example, take a look at the Rust ecosystem, where you can manage the entire DOM in Rust: rustwasm.github.io/docs/wasm-bindgen/examples/dom.html
Hi, Thanks for the reply. since we use web assembly to directly execute without the other intermediate process, can't we do this same with JS? I mean since JS goes through parsing and interpretation and another optmization process like Ignition/Turbo things so what if chrome/v8 could give us that optimized byte codes and we send those byte codes to users instead of raw unparsed javascript which eventually goes through the same process on all the machines. Sorry if i asked wrong question, just was my curosity
I've seen many times people say that wasm runs at near native speed of languages like C. So, the peak performance of JavaScript is also near the native speed of C?
Only the Optimized JS code CAN be as fast as C. Interpreted is always slower, but it gets optimized to machine code. And C is not faster than machine code.
Reality is that a lot of devs will use Web Assembly to escape JavaScript hell. They WANT to use (for example) Rust instead of JavaScript! Not to mention that people want to reduce the number of languages they use, not to add one more.
Can you back up that claim that “a lot of devs” want to do that? I know there is a vocal group of people that say that, but my impression is that most _web_ developers don’t even know much about WebAssembly yet (hence me giving this talk) and are quite comfortable and happy with JavaScript. Again, to me it’s a symbiotic relationship, not adversarial.
@@dassurma I feel like you underestimate the amount of people whom misuse technology that is made available... As an example, Rusts' wasm-bindgen allows the use of document selectors in rust. Is it actually useful? Perhaps. Is there any reason in it? Perhaps not. So saying that "a lot of devs" want to do that is in poor taste, but if the statistics of webassembly calling DOM APIs in some way comes out (eg in HTTP Archive), you might see /some/ use of it. Not necessarily a lot, but it will be a thing that is used to some degree. There may be people who use it to call things directly. It's not exactly that difficult to say that,
I am not so sure, maybe for a dialect of TS that has benefits when compiled to WASM. You would have to either disallow dynamic code and data so you don't need a JIT/Interpreter inside the TS compiled to WASM module or somehow have this handled by the Browser JS runtime which then also needs to effectively communicate with the compiled into WASM TS module. Maybe this is what it will converge to: WASM having a standardized and fine grained interface to the JS runtime all of its objects/DOM within the Browser to avoid duplication and waste in the WASM module. This challenge here is to not compromise the achieved security with the JS runtime in the Browser and still keep it effectively communicating with potentially buggy / malicious WASM modules.
Wait, are you saying that AssemblyScript _interprets_ TypeScript via WebAssembly? Because that is _not_ the case. AssemblyScript actually compiles a TypeScript-like language to WebAssembly. And data-passing between JS and Wasm already is extremely efficient, so I am not quite sure what you are saying.
@@dassurma exactly) I meant the TypeScript language, not the TypeScript compiler. Certain types available and the overall platform might be different, but the language itself is definitely robust enough.
I think Webassembly is just a cool experiment. I think it would be better to let the optimizer compiler do it's work. Maybe adding optional static typing or "pragma" to JS would help the optimizer !? Even today JavaScript is on pair with Wasm when it comes to performance. Maybe if you are very good at handwriting assembly you can beat the optimizer compiler.
You are right, as I said very clearly in the talk: JavaScript and WebAssembly have the same peak performance. But the entire first half of the talk was about the fact that WebAssembly is not (just) about performance, but also to allow the web to run existing code from other languages. Using JavaScript as a compile target has been tried (asm.js) and didn’t work out too well, amongst other things because parsing and compiling JavaScript is quite expensive. WebAssembly on the other hand was designed to fill that niche.
I think this video confirms that for the average JS/Web developer WASM is going to be way beyond them and is really only for advanced developers. I almost spat my coffee out when I saw memory.allocate/free. I don't know many web (or even C#) developers that have any real understanding of garbage collection and the issues around languages like C++ which require you to manually allocate and free memory. That aside it certainly looks like an interesting technology.
dwhxyz I think you’re underestimating the ability of web developers. Sure we’ll have to learn some new things but I really don’t understand how that is a barrier? Did the programmers not learn a new language and syntax in the first place?
You are right, if you come from C# or JS, you probably haven’t been confronted with manual memory management. But to assume that these developers are incapable of learning is a pretty drastic generalization. And as I mentioned: Native garbage collection is coming to WebAssembly, making these languages a much more natural fit for WebAssembly. We are just at the beginning of WebAssembly, so currently it’s certainly only for bleeding-edge lovers. But I don’t think it will necessarily stay that way :)
Learn rust. You essentially get free garbage collection via the compiler without having to think about allocation/deallocation of heap memory too much (in most application cases). Also you can use smart pointers in c++ to avoid too much manual allocation/deallocation
She seems to imply 'threads' and SIMD are for WebAssembly only, but work in Javascript too. Also From the Mozilla developer site: Note that SharedArrayBuffer was disabled by default in all major browsers on 5 January, 2018 in response to Spectre. Chrome re-enabled it in v67 on platforms where its site-isolation feature is enabled to protect against Spectre-style vulnerabilities.
My take is: For heavy lifting like calculations for reporting, multithread it with webassembly. For the normaly dynamic stuff that C is just very poo at, like dom manipulation, get the results and build an intercactive report with the output from webassembly code... however... since WEbassembly compiles at the beginning... maybe just webworkers are needed for things like reporting over lots of tables and data as this wont be something that can be done upfront.
I was super excited about WASM until I realized there is no direct access to Canvas and pixel data. You have to double copy data. C'mon give us pixel level access.
Cool thing! I hope wasm does not go the way Java applets went! I would be happy with whatever that replaces Javascript and I see a potential in wasm! Javascript and recently Typescript is something that I cannot tolerate! Hope wasm picks up!
13:54 these commands for compiling code for web assembly look completely awful and make me feel that it will be quite painful when you need to implement advanced features like supporting subprocess hierarchies which do not always work well even with existing translators
Serial port is one of the last missing APIs on the web for security reasons. WebUSB gets you access to most modern devices. Web Serial is in the works, but not there yet, sadly :(
Just like any other API, you can if it exists in the context, but it leaves much to the JS bindings (imports). WebAssembly is unlikely to ever have direct access to APIs, as there are basically no APIs that get used directly. If some means of doing so were available (eg document.querySelector, TextEncoder/TextDecoder) it would have to be either using only top-level data (such as the self or window contexts) or using something such as a with statement to be semantic (eg import './k.wasm' with {data(a, b) {return a + b;}}) rather than other means. Of course, there are issues with that, but it stands to reason that the web would be capable of adapting.
Well Golang is not a system programming language, unlike c, c++ and rust, it is still a high level language. As long as they dont have an implementation for garbage collection and runtimes that high level languages rely on it order to run, they can not include any high level language, but as they said, they are working on it, so Golang and co will come sooner or later anyway. But since google is heavly invested in wasm, Golang will prop come sooner rather than later.
At the moment compiling go to wasm will also ship go's garbage collector and this results in large file sizes. Once wasm makes use of the browser's native garbage collector Go and many other languages will become viable options.
You don’t really learn WebAssembly, but rather a language that compiles to WebAssembly. Rust has an excellent Getting Started guide for WebAssembly! rustwasm.github.io/docs/wasm-bindgen/
Qt devs pronounce it as kju-teeeee, second syllable stressed, or just as "cute", just in case. Nice job with the talk and comments section patrol, best of luck :)
It might actually not be _impossible_, but it’s definitely hard. WebAssembly heavily relies on type information (as do most compilers) and you don’t have any types in JavaScript in the _written_ form of JavaScript. So you can’t really compile it. You can try to infer a lot (which TypeScript tries to do!), but it’s much more reliable and easy to have the developer annotate types.
@@dassurma lol.. even though it's boring to see Squoosh since I/O 18 Squoosh is actually a bunch of good JS technology cramped into one app. There is preact, WASM, Service Worker, and many more and it actually deserves to be a role model for how a Web App should be developed these days.
Can an offline App be fully nativized with access to things like the vulcan graphics system and still all be written once as a Unisystem coding scheme. If so wouldn't using sandboxed native code alongside WASM work more efficiently on android than either working via a virtual machine or only compiling on the fly as currently wasm does.
It is bytecode....Assembly language varies with Operating system, Processor, etc. Just as Java is compiled to bytecode which is then interpreted by Java Virtual Machine.
Maybe WebAssembly should be renamed at this point since it's not just for the web. How about OSContainers, or something like that? This could be a real first opportunity to virtualize the OS itself. with names like Virtual Machines, we thinking the OS has already been virtualized, but that's the hardware. This is the first OS virtualization - removing the concept of an operating system from the codebase used inside the app. Never checking windows, mac, linux, other - just program against a virtual OS. Would be a big big win for developers - that's for damn sure.
I can't work with the dependency hell that js is if you can fix that i'm onto it but sadly it's still very slow. Don't get me wrong npm has a lots of packages but those tend to break and then… More predictable and also faster JavaScript didn't even reach on of the levels that webassembly engines had. And when do we get the DOM so that i never need to use JS because i don't like non statically typed languages they tend to not scale for my way of development.
I feel like you misunderstood my point. I show data how JavaScript and WebAssembly have the same peak performance. It’s not just a random claim - it’s based on measurements. And you can use the DOM in WebAssembly, you just need to expose it. Take a look at wasm-bindgen: rustwasm.github.io/docs/wasm-bindgen/examples/dom.html
Second half of the talk is really not adding on to the first half. Lots of compiler/memory jargons!! Could have introduced the topics one by one instead of 10 by 10. :)
Why i think that Google would prefer to not talk about WebAssembly? Only purely theoretic talks about things that 99% of the developers will never need. There are frameworks like blazor and platform uno that actually use WebAssembly for things developers actually need. Not even a whisper about them
Blazor is pretty bleeding edge and doesn’t actually produce high-quality output yet. The hello world demo is 1.3 mb in wasm dependencies. I decided to focus on WebAssembly fundamentals so that developers can learn and appreciate how much work those kind of frameworks do for you and also to have a _choice_ whether to take matters into their own hands. My talk was already pretty tight, so some things had to be left on the cutting room floor.
@@dassurma Don't get me wrong. Your talk was high quality and Enlightening about WebAssembly. But if a web developer watched your talk, I think that leaving the room, will have a taste of WebAssembly being something strange and deep that has nothing to do with him, which is wrong. WebAssembly, as i am sure you know, is the promise of unified binary format across platforms, including the browser. And that is a really big change, a revolution actually, maybe even bigger than the browser as an application platform. This is my point of view and to be honest, from the few people that do low level stuff, almost nobody do them on the browser.
@@dassurma Great talk! I believe you could have put a conceptual diagram with at least (Blazor) .NET called out as an experiment that Microsoft is researching. And maybe call out the universal programming promise next time. One language/runtime of choice other than JavaScript/V8 for both browser as well as server.
Webassembly is a spectacular technology, is my favorite technology. thanks to all who collaborate in this amazing project.
It's a shame that many developers don't want to learn both a language like JavaScript and one like C++. Personally knowing both has been quite the learning experience and helped me become a better developer. Overall they are not that difficult to learn once you get a general understanding of many programming concepts.
Yeaah true. Struggle makes us better. I know how you feel
The context switch from a dynamically typed, garbage collected language to a statically typed, manually managed language is the key issue here. C++ and JS share a lot of syntax, yet switching between them is much harder than JS Ruby or C++ Rust.
Both can be learned but being productive in both, at the same time, is another matter.
Personally, I find that JS and C/C++ share too much, so they collide in my muscle memory and I end up with other issues.
On the other hand, Rust and TypeScript have both enough difference and enough similarities that I can write in both without... writing both in.
Using both Rust and TypeScript alleviates some common issues, but not all. Having only experience in JS causes issues, as does having only experience in Rust or C++. All of them follow their own information, but not all of them have all of that information available right away.
As a web developer, I'd rather stick with js than having to learn another language like c++.
Couldn't agree more, I code in c, c++, python, JavaScript and kotlin.
At Deepti's speech I had to reduce the playback speed to be able to think of all the details.
Yeah, in Surma I had on 1.5, when she got on stage I had to reduce to 1,25, but I didn't pay too attetion.
Sometimes the gap between is more distracting than compressing the information via playback speed. I recommend for smoother comprehension playing at 1.5 or 1.75 for optimal gap filling. Your most likely able to hear the whole more clearly
Once GC is supported and WASM supports web api natively, that makes writing web apps in languages othert than js possible, that means someday in the future, devs might write web pages in C/c++, in rust, in go, in python, in java, even php if it supports full type system. Good Job
This is actually insane thank you
@@yixe2253 Maybe to you but I used the word to mean something incredible or really good. Nothing negative here.
This is the work of a madman. I can't imagine what the hackers would be able to do with this much power.
nothing but disassemble the web haha!
You should dig more, it's sandboxed :)
Can't do that much in a sandbox.
One of the things I was excited about with WebAssembly was the ability to share code across desktop/mobile in a more performant manner. Having used javascript across platforms it just isn't performant to go back/forth between mobile platforms and javascript. React native may help alleviate some of these concerns, but the situation remains that we don't have a common language across all platforms native to that platform. WebAssembly seemed like it could bridge that concern, but I'm not sure if that is a target use case?
use react for everything haha
I think your use-case fits the goals of WebAssembly, although I agree that it wasn’t the most _prominent_ use-case. Seeing how people are now building desktop runtime and even entire OS’es with WebAssembly, the portability aspect is definitely getting more traction than before.
@@dassurma OS's? with WebAssembly? WoW!
@@dassurma what os?
7:11 ......Surma Surma ?
Das Surma Surma ?
El Das Surma Surma ?
Something's not right
Surma Surma Surma Surma.
@@dassurma Reminds me of when I'm escaping backslashes for the RegExp constructor...
Surma etc.
Surma Bhopali
Deepti , just breath .. you are good !
Someone had to say it.
8:26 - Python developer had seen JS first time
As a developer this is how I see typescript
It works the other way too
I'm a C++ dev and that was my reaction. I spent weeks talking about how bad it was to my work colleagues and then it magically clicked.
Because of statically typed language, we created a dynamic scripting language so that we could write and make UI more interactive and now we are moving again back to staticly typed language but how feasible it is to manipulate DOM using web assembly tech. I hope there will be a bridge for JS dev like us who don't know c/c++/Rust and still can take advantage of web assembly.
I mean, that is _literally_ what my entire talk was about. If you don’t want to learn another language, take a look at AssemblyScript, which allows you to use WebAssembly by writing TypeScript. I also mention that both Emscripten and Rust do API tunneling to expose browser APIs in WebAssembly. If you want to see an example, take a look at the Rust ecosystem, where you can manage the entire DOM in Rust: rustwasm.github.io/docs/wasm-bindgen/examples/dom.html
Hi,
Thanks for the reply.
since we use web assembly to directly execute without the other intermediate process,
can't we do this same with JS?
I mean since JS goes through parsing and interpretation and another optmization process like
Ignition/Turbo things so what if chrome/v8 could give us that optimized byte codes and
we send those byte codes to users instead of raw unparsed javascript which eventually goes
through the same process on all the machines.
Sorry if i asked wrong question, just was my curosity
Slide: WebAssembly != C++
Peoples: make photo of this slide on phones
Will big games playable in your browser be the future for desktop gaming?
I've seen many times people say that wasm runs at near native speed of languages like C. So, the peak performance of JavaScript is also near the native speed of C?
Only the Optimized JS code CAN be as fast as C. Interpreted is always slower, but it gets optimized to machine code. And C is not faster than machine code.
C like the speed of light? Nah son
@@undeaddutch underrated comment :D
Reality is that a lot of devs will use Web Assembly to escape JavaScript hell. They WANT to use (for example) Rust instead of JavaScript! Not to mention that people want to reduce the number of languages they use, not to add one more.
Can you back up that claim that “a lot of devs” want to do that? I know there is a vocal group of people that say that, but my impression is that most _web_ developers don’t even know much about WebAssembly yet (hence me giving this talk) and are quite comfortable and happy with JavaScript. Again, to me it’s a symbiotic relationship, not adversarial.
@@dassurma I feel like you underestimate the amount of people whom misuse technology that is made available...
As an example, Rusts' wasm-bindgen allows the use of document selectors in rust. Is it actually useful? Perhaps. Is there any reason in it? Perhaps not.
So saying that "a lot of devs" want to do that is in poor taste, but if the statistics of webassembly calling DOM APIs in some way comes out (eg in HTTP Archive), you might see /some/ use of it. Not necessarily a lot, but it will be a thing that is used to some degree.
There may be people who use it to call things directly. It's not exactly that difficult to say that,
i have yet to meet a person both claiming js to be a hell and knowing js beyond jquery.
I liked the way Surma puts his id card. Me starting today.. 😂
finally a cool use for typescript
I am not so sure, maybe for a dialect of TS that has benefits when compiled to WASM.
You would have to either disallow dynamic code and data so you don't need a JIT/Interpreter inside the TS compiled to WASM module or somehow have this handled by the Browser JS runtime which then also needs to effectively communicate with the compiled into WASM TS module.
Maybe this is what it will converge to: WASM having a standardized and fine grained interface to the JS runtime all of its objects/DOM within the Browser to avoid duplication and waste in the WASM module.
This challenge here is to not compromise the achieved security with the JS runtime in the Browser and still keep it effectively communicating with potentially buggy / malicious WASM modules.
Wait, are you saying that AssemblyScript _interprets_ TypeScript via WebAssembly? Because that is _not_ the case. AssemblyScript actually compiles a TypeScript-like language to WebAssembly. And data-passing between JS and Wasm already is extremely efficient, so I am not quite sure what you are saying.
@@dassurma exactly) I meant the TypeScript language, not the TypeScript compiler. Certain types available and the overall platform might be different, but the language itself is definitely robust enough.
I think Webassembly is just a cool experiment. I think it would be better to let the optimizer compiler do it's work. Maybe adding optional static typing or "pragma" to JS would help the optimizer !?
Even today JavaScript is on pair with Wasm when it comes to performance. Maybe if you are very good at handwriting assembly you can beat the optimizer compiler.
You are right, as I said very clearly in the talk: JavaScript and WebAssembly have the same peak performance. But the entire first half of the talk was about the fact that WebAssembly is not (just) about performance, but also to allow the web to run existing code from other languages. Using JavaScript as a compile target has been tried (asm.js) and didn’t work out too well, amongst other things because parsing and compiling JavaScript is quite expensive. WebAssembly on the other hand was designed to fill that niche.
I think this video confirms that for the average JS/Web developer WASM is going to be way beyond them and is really only for advanced developers. I almost spat my coffee out when I saw memory.allocate/free. I don't know many web (or even C#) developers that have any real understanding of garbage collection and the issues around languages like C++ which require you to manually allocate and free memory. That aside it certainly looks like an interesting technology.
dwhxyz I think you’re underestimating the ability of web developers. Sure we’ll have to learn some new things but I really don’t understand how that is a barrier? Did the programmers not learn a new language and syntax in the first place?
You are right, if you come from C# or JS, you probably haven’t been confronted with manual memory management. But to assume that these developers are incapable of learning is a pretty drastic generalization. And as I mentioned: Native garbage collection is coming to WebAssembly, making these languages a much more natural fit for WebAssembly. We are just at the beginning of WebAssembly, so currently it’s certainly only for bleeding-edge lovers. But I don’t think it will necessarily stay that way :)
Learn rust. You essentially get free garbage collection via the compiler without having to think about allocation/deallocation of heap memory too much (in most application cases).
Also you can use smart pointers in c++ to avoid too much manual allocation/deallocation
Just what I was looking for :)
Surma Surma
Surma
It's a cool name.
the problem with wasm until now, is that it's still used indirectly along JS.
SURMAAA
You rang?
Thank you.
She seems to imply 'threads' and SIMD are for WebAssembly only, but work in Javascript too.
Also From the Mozilla developer site:
Note that SharedArrayBuffer was disabled by default in all major browsers on 5 January, 2018 in response to Spectre. Chrome re-enabled it in v67 on platforms where its site-isolation feature is enabled to protect against Spectre-style vulnerabilities.
My take is: For heavy lifting like calculations for reporting, multithread it with webassembly. For the normaly dynamic stuff that C is just very poo at, like dom manipulation, get the results and build an intercactive report with the output from webassembly code... however... since WEbassembly compiles at the beginning... maybe just webworkers are needed for things like reporting over lots of tables and data as this wont be something that can be done upfront.
Why does the time of compilation have anything to do with what WebAssembly can do?
Great talk imo
What an awesome talk! I'm really excited to learn more about the possibilities of developing for the web with wasm :D
visualization at 21:04 is perfect for conveying the data.
Shoutout to Nick Fitzgerald from Mozilla’s Rust team.
I was super excited about WASM until I realized there is no direct access to Canvas and pixel data. You have to double copy data. C'mon give us pixel level access.
Thank you so much !)
Does really this guy is named Surma Surma?! I mean... dang.
I heard it many times, but didn't know/notice both of his names are Surma :D
Cool thing! I hope wasm does not go the way Java applets went! I would be happy with whatever that replaces Javascript and I see a potential in wasm! Javascript and recently Typescript is something that I cannot tolerate! Hope wasm picks up!
WASM will never replace JavaScript!
13:54 these commands for compiling code for web assembly look completely awful and make me feel that it will be quite painful when you need to implement advanced features like supporting subprocess hierarchies which do not always work well even with existing translators
Can we access serial port yet with web assembly?
Serial port is one of the last missing APIs on the web for security reasons. WebUSB gets you access to most modern devices. Web Serial is in the works, but not there yet, sadly :(
Just like any other API, you can if it exists in the context, but it leaves much to the JS bindings (imports).
WebAssembly is unlikely to ever have direct access to APIs, as there are basically no APIs that get used directly. If some means of doing so were available (eg document.querySelector, TextEncoder/TextDecoder) it would have to be either using only top-level data (such as the self or window contexts) or using something such as a with statement to be semantic (eg import './k.wasm' with {data(a, b) {return a + b;}}) rather than other means.
Of course, there are issues with that, but it stands to reason that the web would be capable of adapting.
Great stuff .
great video! where can i get the slide?
I thought Golang could be used for wasm 😕
Well Golang is not a system programming language, unlike c, c++ and rust, it is still a high level language. As long as they dont have an implementation for garbage collection and runtimes that high level languages rely on it order to run, they can not include any high level language, but as they said, they are working on it, so Golang and co will come sooner or later anyway. But since google is heavly invested in wasm, Golang will prop come sooner rather than later.
At the moment compiling go to wasm will also ship go's garbage collector and this results in large file sizes. Once wasm makes use of the browser's native garbage collector Go and many other languages will become viable options.
It can.
It can but its still in early stages: github.com/golang/go/wiki/WebAssembly
It can. The entire point of WASM is you can use ANY language.
Where can I learn web assembly? Code Academy, w3schools or coursera? Can I read the white pages?
You don’t really learn WebAssembly, but rather a language that compiles to WebAssembly. Rust has an excellent Getting Started guide for WebAssembly! rustwasm.github.io/docs/wasm-bindgen/
Here is also a link for learning Webassembly with C++ from WebAssembly's website: webassembly.org/docs/c-and-c++/
Qt devs pronounce it as kju-teeeee, second syllable stressed, or just as "cute", just in case. Nice job with the talk and comments section patrol, best of luck :)
Thank you for the video. Why it is impossible to compile JavaScript into WebAssembel?
Because wasm is strictly typed and js is dynamically typed and jit interpreted rather than compiled
WASM is meant to run other languages in the browser, it would be pointless to compile JS to WASAM, JS already works natively in the browser.
Probably because its mot typed. U can compile typescript into assembly using assemblyscript
What's the point of using wasm anymore if you want to write JavaScript? Why not simply run that JS on the main thread.
It might actually not be _impossible_, but it’s definitely hard. WebAssembly heavily relies on type information (as do most compilers) and you don’t have any types in JavaScript in the _written_ form of JavaScript. So you can’t really compile it. You can try to infer a lot (which TypeScript tries to do!), but it’s much more reliable and easy to have the developer annotate types.
i hope this is the last time we see squoosh /s
NEVER.
@@dassurma lol.. even though it's boring to see Squoosh since I/O 18 Squoosh is actually a bunch of good JS technology cramped into one app. There is preact, WASM, Service Worker, and many more and it actually deserves to be a role model for how a Web App should be developed these days.
22:00 Let me guess...
1) Chrome
2) Firefox
3) IE
4) Safari
Surma must be sponsored by allsaints
Is this a kinda of modern JAR, .class applet file coming back to life?
Sort of, without the typical shitty java performance
Can an offline App be fully nativized with access to things like the vulcan graphics system and still all be written once as a Unisystem coding scheme. If so wouldn't using sandboxed native code alongside WASM work more efficiently on android than either working via a virtual machine or only compiling on the fly as currently wasm does.
Super!
So its actually not assembly for the web? Oh well. maybe in 20 years.
It is bytecode....Assembly language varies with Operating system, Processor, etc.
Just as Java is compiled to bytecode which is then interpreted by Java Virtual Machine.
what about file reading from disk?
bright the future
Protip for getting an overview quickliy: 2x Speed
no just put it in WASM
Maybe WebAssembly should be renamed at this point since it's not just for the web. How about OSContainers, or something like that? This could be a real first opportunity to virtualize the OS itself. with names like Virtual Machines, we thinking the OS has already been virtualized, but that's the hardware. This is the first OS virtualization - removing the concept of an operating system from the codebase used inside the app. Never checking windows, mac, linux, other - just program against a virtual OS. Would be a big big win for developers - that's for damn sure.
I can't work with the dependency hell that js is if you can fix that i'm onto it but sadly it's still very slow.
Don't get me wrong npm has a lots of packages but those tend to break and then…
More predictable and also faster JavaScript didn't even reach on of the levels that webassembly engines had.
And when do we get the DOM so that i never need to use JS because i don't like non statically typed languages they tend to not scale for my way of development.
I feel like you misunderstood my point. I show data how JavaScript and WebAssembly have the same peak performance. It’s not just a random claim - it’s based on measurements. And you can use the DOM in WebAssembly, you just need to expose it. Take a look at wasm-bindgen: rustwasm.github.io/docs/wasm-bindgen/examples/dom.html
Need DOM access.
Just build it! The Rust team already did it! rustwasm.github.io/docs/wasm-bindgen/examples/dom.html
Doesn't web assembly have native multithreaded support?
Only in chrome behind a flag atm, it will eventually be enabled by default in all browsers.
webassembly, looks like this tool will split up the market of js
Browser 4 is Chrome. "usually fast" Hahaha
Maybe it is Chrome. Maybe it’s not.
@@dassurma or maybe I was saying it was chrome. to make a joke. as they are hiding the name.
It's not. You'll find out in @Surma's and Jake's (@jaffathecakeuk) podcast... I'll leave you cliff-hanging though 😛
Neat
Where r u
Second half of the talk is really not adding on to the first half. Lots of compiler/memory jargons!! Could have introduced the topics one by one instead of 10 by 10. :)
It's reminds me of Firefox OS
Android new swipe back and forth with all old and new
BETAAA
Now are you talking about me or the software?
Why i think that Google would prefer to not talk about WebAssembly? Only purely theoretic talks about things that 99% of the developers will never need. There are frameworks like blazor and platform uno that actually use WebAssembly for things developers actually need. Not even a whisper about them
Blazor is pretty bleeding edge and doesn’t actually produce high-quality output yet. The hello world demo is 1.3 mb in wasm dependencies. I decided to focus on WebAssembly fundamentals so that developers can learn and appreciate how much work those kind of frameworks do for you and also to have a _choice_ whether to take matters into their own hands. My talk was already pretty tight, so some things had to be left on the cutting room floor.
@@dassurma Don't get me wrong. Your talk was high quality and Enlightening about WebAssembly. But if a web developer watched your talk, I think that leaving the room, will have a taste of WebAssembly being something strange and deep that has nothing to do with him, which is wrong. WebAssembly, as i am sure you know, is the promise of unified binary format across platforms, including the browser. And that is a really big change, a revolution actually, maybe even bigger than the browser as an application platform. This is my point of view and to be honest, from the few people that do low level stuff, almost nobody do them on the browser.
@@dassurma Great talk! I believe you could have put a conceptual diagram with at least (Blazor) .NET called out as an experiment that Microsoft is researching. And maybe call out the universal programming promise next time. One language/runtime of choice other than JavaScript/V8 for both browser as well as server.
Java Applets revisited
A little bit. Not really. More generic, more secure and completely standardized through the W3C.
moo