Build the future of the web with WebAssembly and more (Google I/O '18)



This talk will cover how to use the most advanced modern web technologies to build experiences that were never possible on the web before. WebAssembly is enabling the browsers to expose lower-level primitives that can be built on by developers to create performance demanding functionality, like real time media processing, without having to wait for it to be standardized and implemented. See some of the amazing experiences that have already been built and learn how to apply them to today.

Rate this session by signing-in on the I/O website here → https://goo.gl/BMNf9D

Watch more Chrome and Web sessions from I/O ’18 here → https://goo.gl/5fgXhX
See all the sessions from Google I/O ’18 here → https://goo.gl/q1Tr8x

Subscribe to the Chrome Developers channel → http://goo.gl/LLLNvf

#io18

30 thoughts on “Build the future of the web with WebAssembly and more (Google I/O '18)”

  1. Screen-rendering "open-GL"-style might be interesting for high-performance DOMs. If it is, i'm gonna go for Mono and C#, I've grown tired of Oracle and their Java license versioning-nonsense. .Net Core is too tempting to not deserve a good try.

    Reply
  2. I dont think it's gonna change anything for developers, even now as we speak people use different stacks for web developing:js, php, ruby etc. And there are jobs for all of them 😀 also since WA is not a language itself and other languages have to be compiled to WA, who says u cant write JS codes and compile them into WA which itself has to be compile into real assembly 😀

    Reply
  3. It's not actual Assembly since it's not being assembled into machine code. The browser still has to compile WA into real Assembly per-platform, in which case, why is this better than JavaScript?

    Reply
  4. Wouldn't it be simpler just to release a new JS version with static typed functions (and variables) ? This way the VM could compile the function you need to be fast to native code…

    Reply
  5. Awesome but its one step closer to server based os's and software that you "rent" monthly and don't ever own. The "money grab" implications of this are huge. Its also a way to end software piracy which is a good thing but I can see the big software corps bleeding the users dry as well.

    Reply
  6. I'll make a tour tomorrow as things change fast in 6 months . But this video made me sad when dealing with that enscriptem stuff. I'll jump on the train when go or another pleasant functional language has full support and the binary has better access to the Dom. Right now I feel it has very limited uses, I'm even surprised about the perf gain with all the bloating.

    Reply
  7. WebAssembly is promising, but it is still not good. It is still slower than JVM or .NET VM (i.e. Mono), and slower than native C++. It lacks optimizations, good in browser optimizing compiler, very low overhead memory operations, SIMD and multithreading. There are many benchmarks on the web where WebAssembly is still 30 times slower than native C++ app, even if the app is mostly CPU bound (no io, no syscalls, no javascript calls, etc).

    It still bad.

    Reply
  8. Everybody speaks about Web AssIembly, but its C++/rust which is promoted. Well, would be cool to compile JS in to Wasp 😉 (since everybody knows JS, right?)

    Reply
  9. Unless they come up with something that directly manipulates DOM, js will still rule. Blazor has a js interop. This is not great. Why not let a strongly typed language like C#, that compiles natively, directly interacts with DOM and runs in the browser replace js completely. Anything else is a half-baked solution, not worth wasting time over.

    Reply
  10. Microsoft is leveraging Web Assembly to run a Mono based C# web framework in the browser. The project is called "Blazor". It's really cool, you should all check out their Github.

    Reply
  11. 14:13 "You can now write the javascript that you know and love while staying in that same c++ file."
    ….
    ……..
    Ok, I'm going to say this slowly and try to be as concise as possible.
    1. The less mandatory javascript in the pipeline, the better. Ideally none. If JS doesn't need to be intimately linked with wasm, why is it? I understand where you are coming from with calling C/C++ code from javascript, not a bad idea, a page out of python's playbook, and a wise decision if you want to keep JS healthy for the foreseeable future. Personally I don't really want to deal with JS any more than I have to.
    2. The garbage collector, my gut says keep it out of the wasm spec entirely. I know you will likely include one that you think will work great for your purposes but I guarantee that some other lang/langs compiling to wasm will have a different way of thinking about memory management and they will have to include their own anyway. Perhaps people will want to choose to use a different garbage collector algorithm when they compile because of how their particular program performs with one over another.
    3. If you don't go through with #2 and do include a GC, let me turn it off, or at the very least don't turn it on unless I request to use it. I don't want some GC running in the background checking to see if it can free memory that I am managing manually.

    I am very much pro choice when it comes to what languages people decide to use. I know your attitude is that "WASM will not replace JS", but can we not have a choice of what language we use in our tool chain? Is it really necessary that javascript be in the equation at all to get the wasm into the browser? (In short, I do not see wasm and JS inter-operation as a positive, or at least I am highly skeptical that it will not result in a negative.)

    I do know javascript, however, if given a choice between the words "love" and "loath" to describe my feelings for the language, the point on that line would lay far far closer to the latter than the former. I am clearly biased, make no mistake about it. And I will say it again like thus: javascript killed a part of my soul, and I would not hesitate to throw the power switch on the world's last NodeJS deployment.
    I am clearly not your intended audience. Oh well.. take it or leave it. I do know many that would hold similar sentiment though. I am not too terribly broken, my faith in web standards was never strong to begin with.

    Reply
  12. WA is super awesome. Closing the gap between native… Nice! Not too long into the future before we run AAA 3d games at 120fps in a browser 😉 Wishful thinking?

    Reply

Leave a Comment