Yes! Wasm builds on top of 20 years of experience and improvements of JVM, CLR. There are a few key differences, but one important one is the universal adoption by the industry (no ActiveX vs Applets war, .NET vs Java) with companies as varied as Google, Apple, Amazon, Microsoft actively cooperating on moving the standard forward. I have never seen anything like that and I hope it continues for as long as possible!
> > One of the exciting things in Visual Studio .NET is its language agnosticism. If a vendor has written a .NET-compliant language, you can use it in Visual Studio .NET. It'll work just as well as C# or C++ or Visual Basic. This isn't just a future feature-in-planning. There are already nearly two dozen languages being developed for Visual Studio .NET: Visual Basic, C#, C++, JScript, APL, Cobol, Eiffel, Fortran, Pascal, Perl, Python, RPG, Smalltalk, Oberon, Component Pascal, Haskell/Mondrian, Scheme, Mercury, Alice, and even the Java language.
Not sure what the point is here, but that reality for .NET never really came to fruition. Now only C# and a tiny sliver of F# really dominate most of development on .NET.
Well, Microsoft has always been about "our stuff is first class citizen, everything else is second class citizen". You could see that in the 2000s when Microsoft claimed Windows 2003 to be multiplatform because it could run binaries from windows 95, windows 98, windows 2000 and windows xp.
What happened with .net is that C# is first class, F# is second class, and everything else is third class citizen at best (when not directly attacked via patent litigation).
Regardless of its technical merits, .NET was never adopted universally, WebAssembly is on the path to do so. It is also not exclusive: Blazor is a successful Microsoft product implementing WebAssembly leveraging .NET
The VM part of WASM is not per se the interesting part. The really interesting part is having a VM that is not able to access the system besides what it's being explicitly allowed to by the host. This is an extremely useful security tool.
The component-model proposal makes this statement even more interesting. It will allow to set capabilities to the libraries that your Wasm module uses. For me, this is critical as in most language ecosystems, libraries gets the same permissions as the main application.
Java tried that and it is an ongoing disaster that is itself the source of security bugs.
Library boundaries are not often so rigidly clear cut as to be a security boundary, ignoring also the performance & compatibility issues that come with such a thing.
Agree 100%. Also, as it came from the browser developers, so not only it is OSS but it can be relied to already be there, not a plugin your users have to install (I don't miss at all the days of ActiveX, Java Applets, Flash, etc ...)