Build the future of the web with WebAssembly and more (Google I/O '18)
Vložit
- čas přidán 8. 05. 2018
- 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 → goo.gl/BMNf9D
Watch more Chrome and Web sessions from I/O '18 here → goo.gl/5fgXhX
See all the sessions from Google I/O '18 here → goo.gl/q1Tr8x
Subscribe to the Chrome Developers channel → goo.gl/LLLNvf
#io18 event: Google I/O 2018; re_ty: Publish; product: Chrome - General; fullname: Thomas Nattestad; event: Google I/O 2018; - Věda a technologie
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.
I have checked that out. It's is really Cool. It enables you to run .NET on the browser which no one could have ever thought of. I believe, "Blazer" is the beginning of the end of JavaScript monopoly on the browser.
@@harisrg92 My friend, mkol, made it possible to run arbitrary .NET applications in the web browser about 8 years ago, the project is named il2js.
Unity Tech's been doing something similar for a while with WebGL builds for video games. In the past, they'd compile IL to C++, and then compile the C++ to compiled JS via emscripten, but now that we've got web assembly, they can just compile to that, which is pretty neat!
got any Blazor project links, similar in capability to the apps from the video?
@@404Assassin Blazor is more of a single page application alternative to things like Angular and React.
With Blazor, you can use the same objects on both front end and back end. The main point is to be able to use C# (which is an amazing language) to handle front end logic. You can still interact with JavaScript from the C# too.
how about old c++ games? curious to see in detail how easy was it to port autocad
Now... What if I DON'T want to write javascript to draw stuff on the screen...?
Use sdl and webgl. You can write code with egl and it will get compiled to webgl. Sdl is already natively supported and it is a commandline option for emscripten.
So exciting!
Very cool... I'd like to know that does webassembly supports C++14 (or later)?
Amazing!! Wasm looks very promising... During the the wohle talk I had the feeling that Java was left out on purpose. C++, Rust, Kotlin... no word about Java ;-)
C, C++ byte code can be run natively with java you need JVM
kotlin has its kotlin native subproject which targets llvm, and they kinda get wasm for free. for java there would be whole another story
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?
Uhh.. no, it's pointless. Why should we need the browser if it's compiled code running opengl and stuff? The DOM, page rendering and javascript become quite useless, the only reason to use the browser for them is for cross-compatibility...? Nah
Just a thought. Why not allow/upgrade the JS compilers(V8) to output a binary file of the parsed js. Then one would get the load time speed benefits out the box, with out many hurdles, implement another extension, or just have a new global function that if called, assumes the remain file is all binary. Would be nice to be able to have different file extension, so one can hot compile the parse stage on the server to the required browser v8 versions and then cache the output. In the same way http request headers, specify the accepted transfer support encoding, one add the v8 engine supported version in the request. One could actually use the request headers only and not even need to implement a new file extension. This then also would work well with edge compute, were the edge nodes would perform the caching and compiling of parsed v8 resources. The main end point, need only server js and not have to worry about handling the load when their updates to v8 engine, browsers. Maintain of all front-end(endpoint) js code, would be done by all the caching servers, simplifying deployment, as one no longer need to deploy all versions of binary formate to the support the role out of ever green browsers, or wait for mass role out of compiler updates to browsers, before worth update the server frontend, endpoints. The only complexity that is going to arise probably is from tree shaking and shared code, in which case a backwards compatible loader function from js would be need to bind and pass information about memory spaces allocations. Still end up with on ambiquitius language then, but don't loose all compiler optermization for hot code.
Wesley Oliver because JS is not suitable for that, being a prototype oriented loosely typed language has many disadvantages, including that one
WA makes browser a new OS.
And slides?
So existing!
Nice ❤️
How long before multi-thread support of WebAssembly could become mature ?
3 years
it has alr been done eady, us it right ing now
Web assembly doesn't need multi threading. We can make use of webworkers, JavaScript and webassembly to have multi core execution. JavaScript and webassembly are complementary :)
Yes, I need that too! Parallel graph algorithms at native speed in the browser - hello applications of the 2020s ;)
It's being worked on in this repo: github.com/WebAssembly/threads/blob/master/proposals/threads/Overview.md
Is there a php to web assembly prospect?
nice!
As a c++ dinosaur its awesome
Great AutoCAD example of the feature! Now, bring me Maya, please.
I'd accept Blender as well.
And Go supports it too (to some extent).
Flutter's HummingBird with Web Assembly???
The "#include " is still C and not C++, the "#include " should be used when you're talking about C++.
What makes this code be C++ is compiler that takes it as C++ input probably because of "cpp" extension.
No. The extension doesn't matter actually. #include , is still C++. You can include C code in C++.
Compiler knows which one to use based on invocation, i.e. emcc, em++. similar to clang++ and clang, and gcc and g++. It switches to default different language, enabled different linker library and stuff.
They could have helped alot if they accomodated php since it sat on C.
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.
Coding Starts @ 9:20
nice
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?
wasm is assembly just not an assembly that any physical CPU could execute without a virtual machine. Web Assembly is a much lower level language than javascript and is consequently faster than javascript. I would not say either is "better" because they are used in conjunction with each other. Also unless I'm mistaken, a browser does not actually compile any asm it is just a program that follows a protocol given plain text. Fact check me as I am shaky on that last bit.
I always knew Agent Smith was a Google operative.
If Apple and Microsoft abandoned WebAssembly that will be the time I start using all Google products.
Blazor (C# and HTML) for WebAssembly
Can I use WebAssembly with NodeJS?
Yes
新语言新特性 真是灰常的棒棒
c,c++,Rust,哪里新了?
He's Dwight Schrute from The Office!
Btw, very interesting video!
I always think that why is it so hard for Google to create simple solutions..it is always simple things done most complicated way.
Maybe there is just too many smart people competing these things..
Two years later.... -> WebBinary : The revolutionary future of the web (Yes, we still can make it more complicated :))
This is really promissing...
Hagrid says: "Viruses, Harry, viruses everywhere"...
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?)
Xwayangkyu lit
How did we go from "the future of technology" to "Autocad"?
Webassembely.
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.
What the Emscripten toolchain should really do is just to add DOM manipulation functions to C/C++/Rust and keep it at that and just leave in-line JS out of it all.
That way you get the benefits of the in-line JS shown without the drawbacks of _actually_ having to write JS
I don't think javascript is the problem. Designin UI's is the problem. These are a lot more complicated than typical web backend stuff. And generally the languages aren't fit to do UI's efficiently, that is, syntax is not favorable. Although we might as well javascriptify some of the languages. Imagine doing UI's without spread operator. Have fun.
Modern javascript is actually very good to write when using Typescript, not vanilla JS. The problem is at the low level how it hits a limit of optimisation which WASM is improving. I use to write C# for a few years and now I realise with typescript, you can write code in a more functional way where functions are first class citizens with very small and succinct code that is easily testable. It works very well with UI frameworks like React. If you don't believe me, here is the actual code in 2019 to create a simple toggle UI using react.
const MyToggleUI = () => {
const [ on, toggler ] = useToggle();
if(on) return Turn Off
return Turn On
}
How short and easy is that compared to C#?
learn C/C++, Rust...
JavaScript is awesome but isn't meant to do what the developers these days are pushing it to do that's why you see browsers using so much resources it's mostly JavaScript codes i would love to see JavaScript keep growing but only in what it was meant to simple interactivity and not building an entire 3d video game based on it or whatever some crazy developers are doing these days
ASMA
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 :D 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 :D
JS says you can’t compile JS to WA
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.
please throw JavaScript into the center of the sun and never speak of it again
For Years I repeat the same HTML, CSS, JavaScript should die !
Is this secure? Really??
Yep, it's sand-boxed by the browser.
Hahahaha! The Web is going back to C and C++?????? Please, LOL!
Not really, use Rust or Go, C/C++ is just a pile of legacy.
@randomguy8196 Not dynamic languages. The result is something much slower than current javascript. Not much can be done about it either. So no Ruby / Python. For the likes like PHP, they don't really care to begin with.
Rust is the best language for WebAssembly at the current day. You may try Go but they are only experimenting. And probably the end result will be nowhere as efficient as with Rust. Although it's super easy to set up. They might optimize it with new versions of Go. (current day is 1.11)
@@romanscharkov C/C++ still have their place in the world. C is still the most popular systems development language, and with projects like CertikOS I don't see that changing. C++ is very popular for game development, about as popular as C# actually.
Compiled Languages will be dominant in the future.
I have few points to flag:
Web assembly is not faster because it is complied from non-JS languages. its faster because its more low level
And, If JavaScript is able to scale from simple text based apps of late 90s to complex apps of now a days, I dont think we need new technology. The language is successful in handling anything. Mark my words, 20 years down the line, you will use JS...
And, I am sure some day people would prefer to compile WebAssembly from JS ....
I believe the main point is that existing smart compilers such gcc could do real magic to create optimized assembly code, so why not just translate the produced assembly from the gcc to web assembly? So in order to write transform javascript to wasm then we need to create a really smart compiler.. but isn't a waste of time?.
Maybe JS can do it all, for your personal (current) use case and dev needs. But, as Autodesk clearly demonstrates, WebAssembly is giving the web new capabilities, for which traditional JS just doesn't cut it. JS might still survive for a long time, but not with the monopoly it had so far. Probably not even remaining the dominant web programming language.
So CS is dead BS up
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.