So, I'm gonna be honest with you folks. I do a terrible job of staying up to date on the latest tech. I see things come up on Twitter, I see people...
For further actions, you may consider blocking this person and/or reporting abuse
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.
Thanks for this post. This is the most straightforward article I've read about Web Assembly.
I think people haven't really started playing with because it involves the browser but it's supposed to be used for tasks that are typically run in the back end. We haven't yet broken through that mentality of having things happen where we expect them to.
Nailed it, it requires a (big) shift in mentality.
Some are still trying to understand how to use web workers effectively or edge computing.
By adding WebAssembly (which is getting multi threading) to the mix we'll be able to efficiently run web apps using the CPU of the client instead of running jobs on the server and then delivering the result to the client.
There are technologies now that allow develoeprs to write
TypeScriptand compile it to Web Assembly. The technology is calledAssemblyScript.I have written an article about it here.
Also, I'm really glad to see Web Assembly catching so much interest! It's going to make a lot of waves in the Web Development community for years to come.
One of the big downside of the current node/npm ecosystem is maintainability.
Don't touch at a frontend SPA project for 6 months and I dare you to be able to make it build again.
Even if you have a package lock file, it will just not build nor run anymore.
Same thing about upgrading, there is no elegant way to upgrade the dependencies without breaking everything.
The lack of a really standard library like you could find in Golang gave place to thousands of "< 100 lines of code" libraries of very heterogeneous quality.
Even a quite small frontend project ends up with a thousand dependencies with almost the same amount of different authors and with NPM telling you some of them have critical security.
Golang or C++ project I wrote 3 years ago still compile and run as intended.
If I can write a web app in Go, using something like Vugu (vugu.org), I won't hesitate for a second.
I don't foresee myself using WebAssembly so much as using things that make use of WebAssembly. I've been tracking WebAssembly for a while as reason to keep leaning in on the browser as a platform.
Support for WebAssembly is surprisingly far along:
Yeah. This was one of the things that impressed me too. Multiple browser engines hopping in to support the technology this early in seems like a really good sign.
One interesting case I've read into a bit, but I'll admit I've stayed pretty surface level with is Dropbox developing client-side compression which would be fairly infeasible with JavaScript:
blogs.dropbox.com/tech/2018/06/bui...
It pushes client-side computing way further than ever possible before in the browser.
Client-side compression is a great use case, I didn't even think about that.
If a user wants to take a photo on their phone and post it to a website, they'll upload it in the default maximum resolution and then the server will have to compress it. With wasm the resizing could be done in browser and save bandwidth/data plus server resources.
I like Web Assembly due to it allows ppl to use different languages for Web development and the only company that I know of that has fully adopted it is Figma.
Which I'm one of the developer in my company that uses that design tool in a web browser on Linux machine.
Actually pretty no one is talking about WebAssembly, compared to Blockchain or IoT is still an obscure technology.
Like PWA they need a wide adoption first, and to solve a business need.
It's possible that there is a decent amount of "talk" in terms of podcasts, conference talks, etc. But Google trends probably is more reflective of what problems people are solving on a day-to-day basis. I doubt Webassembly is ever going to be the actual concern of that many developers, even if it gains popularity. But idk.
I think blockchain is a huge outlier in its capacity to gain mainstream traction. Even when Webassembly is well-established, I doubt the news will report on it.
There is support for direct C++ to JavaScript function calls using something called "embind" (feature of the emsdk). At work we use I to wrap our C++ API in a js-friendly API. So fast & easy compared to how it used to work where you could only communicate with JSON.stringify or synchronizing state with SharedArrayBuffer.
I think embind might be experimental. At work we have not used it with production code but I can't wait until we do.
It's kind of that idea of a universal binary. If your computer can run a browser, it can run a WASM binary file. The coolest part is that it can be distributed just by visiting a website. I think getting webapps even closer to performance parity with native apps is still the goal. Allowing any language to compile to WASM is kind of a nice side-effect of having it running in a browser-based virtual machine.
Great article! I have been keeping up on the general development of Web Assembly ever since it was asm.js and it's really cool to think that soon you could write your software once and have it run on every platform that has a browser. Also if you interested this talk from 2014 is great...
[destroyallsoftware.com/talks/the-b...]
So the use case (for now, maybe there's more) is (1) speed, (2) wrote your client side apps in languages other than Javascript? This is a technology that I might be following "from the sidelines" but not spend time on to actively pursue until there are compelling use cases.
IMO, it's to balance resources not simply use them in one area. You're essentially looking at Parkinson's Law moving the processing burden back and forth as technology improves in different areas.
Nice article btw!
Completely agree with the article.
I'm working with my team at Wasmer to move WebAssembly server-side because of all the nice properties it have to run any kind of software in an universal way (mainly because of it's sandbox design and it's almost native speeds!)
Precisely my question : it can be used only with language where you have a way of creating a C binary, am I right ?
(Because the article spoke of "any language", but then spoke of creating a C binary.)
I haven’t followed WASM closely over the past year but to my knowledge, none of the threats I’ve identified have been addressed as of yet. github.com/stevespringett/disable-... identifies some security concerns to be aware of. There may be more. Like I said, I’ve stayed away and haven’t kept to to date.
My view of WebAssembly is that it's a much-needed compilation target in the browser that allows you to write client-side applications in languages other than JavaScript. It's basically democratizing the front-end language space, resulting in more choice for everyone in what language you want to use for web applications. This is a good thing. Different languages have different strengths and WebAssembly allows you to make use of 'the right tool for the right job' philosophy.
You mention that there's a whole new asset, the Wasm binary, that needs to be sent to the browser. Is this also not the case with JavaScript? The JS script source has to be sent to the browser yes? Isn't the only difference in the source code format, namely text vs binary? Or do I have this wrong? I'm a relative newcomer to web development so I may well be mistaken :)
Not just that. WASM is binary and already compiled to there's no parsing nor interpretation nor compilation steps to be had.
Except for Game engines, WebAssembly is pretty much pointless, given the peer W3C standards.
And then, even for game programming, no AAA-rated game targets WebAssembly. So, unless you are an indie who is using some OSS like Unity for game development, WebAssembly is pretty much useless in business environments.
Not to mention the architectural anti-patterns of mixing the business layer with the presentation layer, which goes back to the same problems of WCF and Java on Web.
To summarize, its pretty much hard to find a genuine real-world business use-case for WebAssembly. It is better to stick to other W3C standards.
Companies tried to kill Javascript years ago, with plug-ins, applets, activeX, but they affected battery life on mobile devices and raised security concerns, so the industry moved back and revived JavaScript.
JavaScript recently has become a big mess with so many frameworks and incompatibility so, it looks like WebAssembly is the new thing, supported by all major modern browsers, to write code not using JavaScript. Currently you have to write code in TypeScript or something else that gets transpiled to plain old JavaScript, so it would be great to write in any other language of choice and deploy your app to the cloud.
Microsoft for example provides the open source Blazor, that also looks promising, using C# or any other .NET Core language.
Will see if it gets adopted by the industry. Will be great to have native compiled code running on the browser and move away once and for all from JavaScript
Thanks for this post @captainsafia . As a systems engineer, the options provided by WASM becomes very useful as we move into a world where humans begin to interact &/or augment with machines more often. Plus in cases where a machine interacts w/ other machine(s), we need something more native to how they are build and operated. You might find this website also useful: wasi.dev/
With what a terrible state of software we must be living...
harmful.cat-v.org/software/
Thanks for the article. Any information about using WebAssembly with the actual web frameworks?
One person has been working on eliminating the Javascript to use D.
Utilizing Webassembly from D
Jesse Phillips
Ok. Thank you very much for the answer.