And how should I at compile-time know how many CPU cores will be available at runtime? It would be better if I could spawn as many threads as there are CPU cores on the actual machine running the wasm module and utilize them optimally. By forcing us to specify the number of threads at compile time will simply make our apps either too slow on modern desktop machines due to underuse of available CPU cores, and too heavy for mobile devices with only a single or two cores...
Sounds great on paper, but if I launch a pthread from my wasm code, it crashes the main thread, even in a trivial code sample. Also, it fails if I have dynamic linkin enabled, or if shared memory is disabled in the browser, which is disabled by default.
btw I just (two weeks after this is uploaded) ran GoogleEarth in Firefox, and it asks me to download Chrome in order to start. Misleading presentation is misleading.
It is almost as if someone is insisting that all web-based code MUST be subservient to JavaScript. I can't wait to someone releases a web browser that will run webassembly "natively," in that the WASM code can be launched directly by the browser, WASM can access and modify the DOM directly, and threading and garbage collection are handled directly by the WASM VM that is a bit-in part of the browser. Then, move that WASM VM to the OS as WASI. FINALLY, build WASM/WASI coprocessors in hardware, just like GPUs.
what's the benefit of wasm over a traditional assembly language at that point? also, it's not that wasm is subservient to js. the model starts with an html document which contains script and css tags to embed other langauges. the alternative would be having a wasm tag that contains a link to a wasm file. also, wasm was implemented before wasi and before wasm code could manipulate dom, so you'd need js to do anything useful from wasm anyway. this is good because it allows us to make incremental progress on an api that'll be around for decades. in the context of things, i think the wasm spec is actually pretty good. webcomponents on the other hand do depend on js for no good reason and are poorly designed.
"Liftoff", the "shuttle icon", and the "Turbofan" have so little in common, that it boggles my mind, why would anyone design a system around these 3 metaphors...
It is not a language, rather a virtual machine supporting wasm binary files. Something like JVM and .NET. And that is why I guess Google love it, to replace the whole JVM with it and getting rid of Oracle problems. But the question is then what do you do when all people start to use web apps written in web assembly instead of installing native apps where Google get a piece of the money? There would be almost no difference in performance. Interesting to see how this develops.
That's funny. We have very different definitions of "almost no difference." Also, google doesn't care if you install or not, as long as they get to serve you some ads beforehand. If anything, focusing on web delivery will enable more ads.
Very useful this presentation in the manner of style programming. I start with javascript but ... anyway. If you want my opinion one great subject can be "what is bad into programming language". Starting with rules of ""bad syntax" and "why the new programming languages have many bugs". I used assembly, PHP, Java, Python, javascript, Golang, C# for little projects with Windows and Linux like freelancer.
No thanks. Just give me the native threads in wasm directly. Web Workers have too high overheads, require JS, and do not allow to use modern hardware features, like atomic operations, transactional semantic, etc. Sure, it is enough in some apps, but definitively not good enough for a lot of other stuff. I am fine with Web Workers as a temporary solution, or a better isolation (could help with some bugs, including some security related ones), but not the end goal.
A re-invention of Java Applets in a sense. A binary runtime standard that gets JITed at execution time. WebAssembly validates the maxim of the computer industry that technologies get re-invented every 20 years. The latest "inventors" are so proud of themselves for thinking what they have done is new and shiny to the industry.
Good for mainstream products and "intranet" products. Im expecting insecurity on closed source on small sites, just like ad abuse but worse like crypto mining, or other thirdy party sales of energy. A request to the user to use more processors must be good.
Well, just watch your task manager and don't keep tabs infinitly open, if you don't trust the website. CPU isn't the problem nonetheless, WebGL would be the problem (better for mining). For example, telegraph.co.uk when I visit Telegraph, my GPU starts fanning immediately. No clue what they are doing.
Computing resources, both gpu and cpu need to have a limit for "standard web pages", if needs more then the user should be notified (and optionally asked permission) in a clear fashion.
A request to use just one processor excessively would be good. If a page is using 100% of a single core continuously after the initial page load, then something is clearly wrong. It may be a legitimate use case that's just bugged out, I may still want to use the page, in which case I'd like a notification to limit it to 25% core usage or something.
@@emilemil1 Currently, if there is long running JS code, you get a notification to kill it. Since WebAssembly is in the same security context, I would assume that something similar would happen for WebAssembly. But, I do like the idea of having threasholds and allowing the user to agree to change those threasholds, on a site by site basis.
WebAssembly is highly entangled with the JavaScript v8 engine and is used for all the configuration and providing memory array buffers etc. Only using WebAssembly is retarded nonetheless, because you would loose all the F12/DevTools for introspection, which makes browser scripting so powerful. Static compiled languages are like autists, good in one thing, but can't do any meaningful REPL etc.
I'm ok with that, RUST all the way... but there is a little problem... WebAssembly hasn't the access to DOM and typescript is really great for web apps. Which means we need an Angular/React/Vue framework in webassembly. Angular is there since 2 years, going from version 2 to version 7. So you can wait at least that time after DOM is accessible from Web Assembly to have a pure WebAssembly app framework. After take into consideration the updates of web browsers to have the access to DOM, which means you can wait minimum 3 years before web assembly is ready for production. So I downvoted your comment because you seem to not have a true overview about the subject.
As kung foo man said, you can't use a REPL with WASM. Debugging tools might get better in the future, but it might also be harder to do on-the-fly changes to the source, though one day live compilation/updating will probably work well. Don't forget that the DOM manipulation APIs and WebGL APIs aren't available to WASM yet either. It is very likely that the web will continue to be JS at the top level, but more of the backend will get replaced with WASM as time goes on and more APIs get exposed to WASM. It will also take time for the debugging tools to improve.
And how should I at compile-time know how many CPU cores will be available at runtime? It would be better if I could spawn as many threads as there are CPU cores on the actual machine running the wasm module and utilize them optimally. By forcing us to specify the number of threads at compile time will simply make our apps either too slow on modern desktop machines due to underuse of available CPU cores, and too heavy for mobile devices with only a single or two cores...
Sounds great on paper, but if I launch a pthread from my wasm code, it crashes the main thread, even in a trivial code sample.
Also, it fails if I have dynamic linkin enabled, or if shared memory is disabled in the browser, which is disabled by default.
That's what I really want!!!!
BLAZOR ❤️
btw I just (two weeks after this is uploaded) ran GoogleEarth in Firefox, and it asks me to download Chrome in order to start. Misleading presentation is misleading.
Maybe it requires some specific chrome apis
this is fantastic !
is it can useful way to implement VR web application?
Absolutely! You can do it right now, use WebGL or the upcoming WebGPU.
It is almost as if someone is insisting that all web-based code MUST be subservient to JavaScript. I can't wait to someone releases a web browser that will run webassembly "natively," in that the WASM code can be launched directly by the browser, WASM can access and modify the DOM directly, and threading and garbage collection are handled directly by the WASM VM that is a bit-in part of the browser. Then, move that WASM VM to the OS as WASI. FINALLY, build WASM/WASI coprocessors in hardware, just like GPUs.
what's the benefit of wasm over a traditional assembly language at that point?
also, it's not that wasm is subservient to js. the model starts with an html document which contains script and css tags to embed other langauges. the alternative would be having a wasm tag that contains a link to a wasm file. also, wasm was implemented before wasi and before wasm code could manipulate dom, so you'd need js to do anything useful from wasm anyway. this is good because it allows us to make incremental progress on an api that'll be around for decades. in the context of things, i think the wasm spec is actually pretty good.
webcomponents on the other hand do depend on js for no good reason and are poorly designed.
"Liftoff", the "shuttle icon", and the "Turbofan" have so little in common, that it boggles my mind, why would anyone design a system around these 3 metaphors...
It is not a language, rather a virtual machine supporting wasm binary files. Something like JVM and .NET. And that is why I guess Google love it, to replace the whole JVM with it and getting rid of Oracle problems. But the question is then what do you do when all people start to use web apps written in web assembly instead of installing native apps where Google get a piece of the money? There would be almost no difference in performance. Interesting to see how this develops.
I hope there wouldn't have any difference in performance too, but this wouldn't happened.
That's funny. We have very different definitions of "almost no difference." Also, google doesn't care if you install or not, as long as they get to serve you some ads beforehand. If anything, focusing on web delivery will enable more ads.
@@noxabellus you have good point, but they will lose the income from play store. But this will take some years.
@@noxabellus how would they differ? I might be wrong.
@@noxabellus wouldn't the only performance difference be only at the beginning? that is when it compiles from wasm to executable machine code.
Very useful this presentation in the manner of style programming. I start with javascript but ... anyway. If you want my opinion one great subject can be "what is bad into programming language". Starting with rules of ""bad syntax" and "why the new programming languages have many bugs". I used assembly, PHP, Java, Python, javascript, Golang, C# for little projects with Windows and Linux like freelancer.
No thanks. Just give me the native threads in wasm directly. Web Workers have too high overheads, require JS, and do not allow to use modern hardware features, like atomic operations, transactional semantic, etc. Sure, it is enough in some apps, but definitively not good enough for a lot of other stuff. I am fine with Web Workers as a temporary solution, or a better isolation (could help with some bugs, including some security related ones), but not the end goal.
A re-invention of Java Applets in a sense. A binary runtime standard that gets JITed at execution time. WebAssembly validates the maxim of the computer industry that technologies get re-invented every 20 years. The latest "inventors" are so proud of themselves for thinking what they have done is new and shiny to the industry.
Except Java Applets had many issues. Anyways, so what do you suggest as a better alternative to improve app performance and efficiency on the web?
Not even close. WebAssembly allows you to run existing C/C++ code, so you don't have to deal with a monstrosity like Java.
@@gnagyusa I'm sure you can compile c/c++ to jvm bytecode.
Good for mainstream products and "intranet" products. Im expecting insecurity on closed source on small sites, just like ad abuse but worse like crypto mining, or other thirdy party sales of energy. A request to the user to use more processors must be good.
Well, just watch your task manager and don't keep tabs infinitly open, if you don't trust the website. CPU isn't the problem nonetheless, WebGL would be the problem (better for mining). For example, telegraph.co.uk when I visit Telegraph, my GPU starts fanning immediately. No clue what they are doing.
Computing resources, both gpu and cpu need to have a limit for "standard web pages", if needs more then the user should be notified (and optionally asked permission) in a clear fashion.
Webassembly exists in the same sandbox as JS, so they share the same security profile.
A request to use just one processor excessively would be good. If a page is using 100% of a single core continuously after the initial page load, then something is clearly wrong. It may be a legitimate use case that's just bugged out, I may still want to use the page, in which case I'd like a notification to limit it to 25% core usage or something.
@@emilemil1 Currently, if there is long running JS code, you get a notification to kill it. Since WebAssembly is in the same security context, I would assume that something similar would happen for WebAssembly. But, I do like the idea of having threasholds and allowing the user to agree to change those threasholds, on a site by site basis.
Thank you
But I can not understand.
why? why wasn't wasm designed to replace js? and all you guys present this as a great feature. we want js dead asap!
Just replace js with webassembly and move on
WebAssembly is highly entangled with the JavaScript v8 engine and is used for all the configuration and providing memory array buffers etc. Only using WebAssembly is retarded nonetheless, because you would loose all the F12/DevTools for introspection, which makes browser scripting so powerful. Static compiled languages are like autists, good in one thing, but can't do any meaningful REPL etc.
I'm ok with that, RUST all the way... but there is a little problem... WebAssembly hasn't the access to DOM and typescript is really great for web apps. Which means we need an Angular/React/Vue framework in webassembly. Angular is there since 2 years, going from version 2 to version 7. So you can wait at least that time after DOM is accessible from Web Assembly to have a pure WebAssembly app framework. After take into consideration the updates of web browsers to have the access to DOM, which means you can wait minimum 3 years before web assembly is ready for production. So I downvoted your comment because you seem to not have a true overview about the subject.
kung foo man Webassembly is an executable platform, nothing to do with JS. It sits beside it.
As kung foo man said, you can't use a REPL with WASM. Debugging tools might get better in the future, but it might also be harder to do on-the-fly changes to the source, though one day live compilation/updating will probably work well. Don't forget that the DOM manipulation APIs and WebGL APIs aren't available to WASM yet either. It is very likely that the web will continue to be JS at the top level, but more of the backend will get replaced with WASM as time goes on and more APIs get exposed to WASM. It will also take time for the debugging tools to improve.
@@kungfooman nonsense. This is 2018., static compiled languages have good REPLs. Java's had it since 2015, Haskell had it since forever, etc.
10:50 Why use a bleeding-edge tech while you have C++ that's been out there for decades? CMON. We don't need anything else.
they should call it Chrome Dome OS
Websites are already too big and slow and janky. Large-scale use of web assembly will make it even worse.
WeBassembly generates much smaller downloads than the current Web languages, so it should actually make things better.