I think WebAssembly will have more value for developers who aren't using Javascript for the back-end. Like, um, me. As a C# developer, being able to re-use C# code client side will have a significant impact on how I work. I can't wait until Blazor is mature enough to be used.
I'm a member of the strongly-typed church. I prefer to catch errors at build time instead of runtime. And one of the things I like about C# and Visual Studio (not VS Code, actual VS) is being able to easily rename properties or methods and have that change automatically done through the entire codebase. It's also nice to be able to quickly and easily see what code is referring to what and where.
This breaks down at the Javascript/C# barrier. As one example, when I'm dealing with json responses to ajax requests, I usually create a class in C# for containing the data which then gets serialized into json. I then have to very wary of changing that class because it could then break the javascript that consumes it. And identifying what may be using that json in the javascript code can be a challenge.
Typescript would help with this but brings some of it's own challenges. WebAssembly would remove the C#/Javascript barrier and let me use C# on both sides. To more specifically answer your question, at a minimum, some of the Javascript code that I would convert to C# would be the code that handles the json responses from the server since I could then have that code use the exact same class used by the server.
Hi Tim, you might want to look into a validator for your JSON. I've never used any of them but you can find some here
WebAssembly, at least for now, it's not going to help much in that, unless you write the entire app in C# with WebAssembly. The thing is that JS and WASM need to continuosly serialize and deserialize data coming from one to the other back and forth. So, if you write the JSON parser/validator in C# it would mean that each time you have to go from JavaScript (used to issue the HTTP call) to C# (to parse and validate the data) to JS (to use such data). That part of WebAssembly is still quite slow.
There a few proposals around to help with that but I think WebAssembly will truly excel for CPU heavy computations or when a lot of concurrency is involved (because they are adding threads to it).
I think WebAssembly will have more value for developers who aren't using Javascript for the back-end. Like, um, me. As a C# developer, being able to re-use C# code client side will have a significant impact on how I work. I can't wait until Blazor is mature enough to be used.
I see. Do you know which parts of your codebase you'd compile to WebAssembly assuming all the tooling and such is mature?
I'm a member of the strongly-typed church. I prefer to catch errors at build time instead of runtime. And one of the things I like about C# and Visual Studio (not VS Code, actual VS) is being able to easily rename properties or methods and have that change automatically done through the entire codebase. It's also nice to be able to quickly and easily see what code is referring to what and where.
This breaks down at the Javascript/C# barrier. As one example, when I'm dealing with json responses to ajax requests, I usually create a class in C# for containing the data which then gets serialized into json. I then have to very wary of changing that class because it could then break the javascript that consumes it. And identifying what may be using that json in the javascript code can be a challenge.
Typescript would help with this but brings some of it's own challenges. WebAssembly would remove the C#/Javascript barrier and let me use C# on both sides. To more specifically answer your question, at a minimum, some of the Javascript code that I would convert to C# would be the code that handles the json responses from the server since I could then have that code use the exact same class used by the server.
Hi Tim, you might want to look into a validator for your JSON. I've never used any of them but you can find some here
WebAssembly, at least for now, it's not going to help much in that, unless you write the entire app in C# with WebAssembly. The thing is that JS and WASM need to continuosly serialize and deserialize data coming from one to the other back and forth. So, if you write the JSON parser/validator in C# it would mean that each time you have to go from JavaScript (used to issue the HTTP call) to C# (to parse and validate the data) to JS (to use such data). That part of WebAssembly is still quite slow.
There a few proposals around to help with that but I think WebAssembly will truly excel for CPU heavy computations or when a lot of concurrency is involved (because they are adding threads to it).
I would use HttpClient in Blazor. But I agree that the interop between Javascript and C# could become an issue.