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

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

Danny Hutson

15 thoughts on “Build the future of the web with WebAssembly and more (Google I/O ’18)

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

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

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

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

  5. I love the idea of WA it is gonna really change the game for the web and it will make progressive web apps even more powerful

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

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

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

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

Leave a Reply

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