@Shamsad Zaman Fragmentation meaning developers will have to compile different .wasm modules to support different browser features because there's now no one target for feature support. Chrome, Safari, and Firefox developer teams *really* need to support *one* target on a yearly basis. Supporting testing features is fine in beta or testing builds, but it's soon to be a mess if Chrome supports X feature, but Firefox and Safari don't support it, while Y is supported by Safari but not FF or Chrome, etc. It'll become a nightmare for developers.
@Shamsad Zaman The problem is that there *is* standardization between all the major powers, but Google already is trying to bully folks to their alpha/beta features or at least custom building .wasm modules with compiler flags which would (might) be incompatible with other browser WA engines. The evidence is right here in this video.
@Shamsad Zaman It's worse than that. With CSS I could still use the same file for every browser, but I can just add -moz-* -webkit-* -ms-* lines to compensate. The way this video is presented each WebAssembly will have to be a completely separate .wasm build and loaded at runtime depending on which features you want to support. #notcool Now for 90% of us this may not be an issue, but if I were to (for example) port a cool 3d engine to .wasm the feature creep and fracturing of compiler options I'd have to build 2 (maybe 3) .wasm modules for the engine.
Not a big problem as long as everyone follows the wasm specification. As soon as some browsers add non-specified functionality, or implement a functionality not according to spec, then we'll be back to where we are now. It's not a problem if some browsers are just ahead of the class.
Same thing was true for JS, no? Browser fragmentation was always a problem in web development. I didn't follow web dev for this reason, so that night not be true anymore with JQuery and whatever else has happened.
It feels like Web Assembly won't take off until it enables developers to replace JS with other languages like Python. Compiling C++ and Rust is nice and all, but most Web Developers don't need system level programming language features, performance, not to mention their learning curve. From what I understand from another presentation on Mozilla Hacks, WASM is not there yet if we want to use garbage collected languages so until it gets there, it's use will be limited to niche needs.
There are many system level engineers and it's not a niche. About python - bringing a GC along with you (the developer) for every web page you visit isn't a "good idea". Even with better network (4G to 5G) downloading data when you could have not, is bad, any day. The current phase of evolution of wasm is because it's building the architect for many system level functionalities (like threads and SIMD) that a system architect expects. So development of the ecosystem is going hand in hand with the development of applications of the technology. People aren't pushing stuff everyday because it's not ready yet
@@clamentjohn There are many system level engineers, but there are way fewer system level engineers that need/want to target the browser as a compilation target. Don't get me wrong, there are bound to be many use cases (including new things that people could come up with) but whatever they are, they are a small subset of what these languages are normally used for. Maybe we'll see one of the Rust Web development frameworks like Yew or Rocket take off (ba-doom-tsss) and these languages become part of many web developer's toolbox, but at this point in time it does look like it has niche use cases (to me at least).
Have you thought about it not being created to serve "web developers" - what ever that should mean - but to serve the market, dominantly a future market and it's customers? BTW a major plus of using C++ is your freedom to go with it's standard and highly efficient and deterministic garbage collector: the closing curly brace. Doing Python via WASM will likely be a performance and memory bloat fiasco that will surely annoy users. I rather think what you call "web developers" will be driven into a niche in their frontend, where the GC bloat and inefficiencies are still tolerable.
@@voidmind the idea is that the internet will help us grow beyond an operation system. Every app will be available over the web. Even Photoshop (check out figma), games (stadia, also many ports of games for the web written in Rust/Cpp). Python will surely boost the number of developers who can get involved. Let's just hope they figure out how to provide a GC over the web
Opening lines of most WebAssembly talks "it's not meant to replace Javascript. " What most developers are thinking, It better get that capability one day otherwise we're not interested.
Man, if you look at their(google) discussion at GitHub regarding webassembly you may see that they trying hard to target different audience - an embedded developers who never had experience with JavaScript and which aren't happy of javascript. They trying to appeal to this audience most likely because a lot of people who wants to try to do something for web but have problems with js. Also attracting embed would mean that Google wants long term products for their technology. If you look about all of it you would see that js developers aren't needed here at all.
It will do, I've been developing long enough to remember when JavaScript first came out with Netscape (I'm that old!) and it took YEARS for JavaScript to take off. There was a huge adoption lag, and it's really only the last 10-15 years or so that JS has got good enough to be used so widely. When JS first came out the actual preffered way of including some embedded logic on the way was through what were called Java Applets. Which at the time were reasonably quick to load (especially with dialup) were platform independent and were in many ways superior. WASM paradoxically plugs the flaws in java applets but finishes the mission of finally creating a compilation target for the web. I think what you'll find is that this will do well, there will be adoption lag, but it will be much quicker to win than javascript was. The interesting thing with WASM is it's available in every browser now, it's already baked in. JS took a long time to get a standards compliant spec to be baked into all the browsers, also people forget that (particularly microsoft) was involved with trying to create proprietary formats and for a while in the late 90s/early 00s looked like they were going to win with things like ActiveX and Jscript (not really javascript but their own proprietary rip off)
Not really, this is the fast development phase of a new standard, so some of do more pre-alpha features are rushed to competing browsers. This is a common procedure C++ is fragmented among vendors until they all get their code bases in order and meet the up and coming standard. So nothing to worry about.
Ughhh, I just started javascript in about 8months now you talk about Wasm is not the replacement of javascript, Should i continue learning javascript or should i learn WASM and Golang for server???
JavaScript like java isn't going anywhere soon, so you can feel free to continue with it. WASM іs just a beginning of the story. But yes you can start looking at wasm with interest
Thats what I hear every time I hear that statement. I think it's basically become dogma because so many people have invested in Javascript and JS frameworks, even at the server level now with Node etc, that they don't want to alienate people. So they are trying to tip toe around it. I've heard Mozilla who created Rust say that it's really designed to be used for pieces of your web app where its the best option, like a cog in a machine. The fact is though that WA does what JS does but better, as it can work with V8 and JS engines by cutting out a lot of many steps required by the interpreter. I think the fact is it could and over time *will* replace JS, they just don't want to be brazen about it.
Dave B that’s not technically accurate. Wasm is faster and more efficient at anything JavaScript can do. Anything that involves a frame rate is much better. And the learning curve to get good at rust I would argue is about the same at learning JavaScript both OO and functional. Then a bunch of ever changing frameworks. Then node too for server side. I think learning one language with multiple targets in the case of rust that can go as deep as systems level I think is way better. And as I say as a straight replacement it’s better than JavaScript in terms of performance. Better for lower powered pcs as it gets closer to the metal. And of course it’s compiled so no jank. Which is the bane of every JS developers life. The reason why wasm isn’t more popular is because of adoption lag and tooling. And those things will change. Javascript was born in the 1990s it took at least ten years to get decent and really twenty to get as good as it is now. The same will happen with wasm.
Javascript is getting a fresh new air with the new runtime environment Deno. It will be able to code quick scripts very easily and very safely. I don't think Rust is able to compete with that, because you spend a lot of time fighting the borrow checker. Rust is very good for everything else, though.
@America Project "Emscripten is as simple and straightforward as using LLVM/Clang" Exactly. not simple or straightforward at all. archaic c++ compilers
Be aware of C++ being 1000x more popular than rust, which greatly affects tooling, libraries, reusable code and available engineers. Look up on Github how much of Firefox is Rust. Rust or anything else simply can't be that valuable to warrant abandoning all the established, esp. as C++ evolved so much since C++ 11..20.
@@raymundhofmann7661 'Rust or anything else simply can't be that valuable to warrant abandoning all the established, ' No one will abandon C/C++. But their use will decrease. Memory safety and Data races are very big problems. And Rust will remedy them and those safety features are valuable.
@@metaphorpritam Possibly the total cost of what you claim can be mitigated by using Rust could be lower when adapting/evolving C++, usage and tooling/IDEs. Doesn't look like Rust is the holy grail for your "Memory safety and Data races" either.
