18 thoughts on “Using WebAssembly and Threads (Chrome Dev Summit 2018)

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. Google Earth on FireFox say to download Google Chrome >.>
    https://www.google.pl/intl/en/earth/ "Google Chrome is required to run the new Google Earth. Please try this link in Chrome. Learn more."

  6. 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.

  7. 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.

  8. 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…

  9. 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.

  10. why? why wasn't wasm designed to replace js? and all you guys present this as a great feature. we want js dead asap!

Leave a Reply

Your email address will not be published. Required fields are marked *