Pushing compute to the client is the whole point, and is often a major improvement for the end user, especially in the era in which phones are faster than the supercomputers of the 90s.
And otherwise, WASM is different in two ways.
For one, browsers have gotten pretty good at running untrusted 3rd party code safely, which Flash or the JVM or IE or.NET were never even slightly adequate for.
The other difference is that WASM is designed to allow you to take a program in any language and run it in the user's browser. The techs you mention were all available for a single language, so if you already had a program in, say, Python, you'd have to re-write it in Java or C#, or maybe Scala or F#, to run it as an applet or Silverlight program.
It's not the same thing though. All of these languages have specific constructs for integrating with the CLR, the CLR is not just a compilation target like WASM is. C++/CLR even has a fourth kind of variable compared to base C++ (^, managed references of a type, in addition to the base type, * pointers to the type, and & references to the type). IronPython has not had a GIL since its early days. I'm sure the others have significant differences, but I am less aware of them.
Are there any examples of how, say, C++ compiled for WASM is different from native C++, or Python on WASM vs CPython? I haven't really used or cared about WASM, so I'm happy to learn, I don't have some agenda here.
And otherwise, WASM is different in two ways.
For one, browsers have gotten pretty good at running untrusted 3rd party code safely, which Flash or the JVM or IE or.NET were never even slightly adequate for.
The other difference is that WASM is designed to allow you to take a program in any language and run it in the user's browser. The techs you mention were all available for a single language, so if you already had a program in, say, Python, you'd have to re-write it in Java or C#, or maybe Scala or F#, to run it as an applet or Silverlight program.