Top Languages for WebAssembly Development: Rust, C++, Blazor, Go - and JavaScript? (visualstudiomagazine.com) 49
This year's "State of WebAssembly" report has been published by Colin Eberhardt (CTO at the U.K.-based software consultancy Scott Logic). Hundreds of people were surveyed for the report, notes this article by Visual Studio Magazine.
Published by B2B media company 1105 Media, the magazine notes that Eberhardt's survey included some good news for Rust — and for Microsoft's free open source framework Blazor (for building web apps using C# and HTML): This year, like last year, Rust was found to be the most frequently used and most desired programming language for WebAssembly development.... "Rust once again comes out on top, with 45 percent saying they use it frequently or sometimes," Eberhardt said. "WebAssembly and Rust do have quite a close relationship, most WebAssembly runtimes are written in Rust, as are the various platforms based on wasm. It also enjoys some of the best tooling, so this result doesn't come as a big surprise."
While Rust usage and desirability has continued to climb, the Blazor web-dev framework is coming on strong in the report, which treats Blazor as a programming language, though it's not. On that desirability scale, Blazor climbed from sixth spot in 2021 to fourth this year among seven "programming languages" [based on] percentage of respondents who use a given language 'frequently,' or 'sometimes' [for WebAssembly development] compared to last year. Eberhardt said, "Rust has had a modest rise in desirability, but the biggest climber is Blazor, with Go following just behind."
Commenting on another graphic that shows which language people most want to use for WebAssembly development, Eberhardt said, "This shows that Rust usage has climbed steadily, but the biggest climbers are Blazor and Python.
While you can now compile WebAssembly from a variety of languages (including C, #C, and C++), the report also found that JavaScript has somehow become a viable WebAssembly language — sort of, and even though JavaScript itself can't be compiled to WebAssembly... There's a cunning workaround for this challenge; rather than compiling JS to Wasm, you can instead compile a JavaScript engine to WebAssembly then use that to execute your code.
This is actually much more practical than you might think.
Published by B2B media company 1105 Media, the magazine notes that Eberhardt's survey included some good news for Rust — and for Microsoft's free open source framework Blazor (for building web apps using C# and HTML): This year, like last year, Rust was found to be the most frequently used and most desired programming language for WebAssembly development.... "Rust once again comes out on top, with 45 percent saying they use it frequently or sometimes," Eberhardt said. "WebAssembly and Rust do have quite a close relationship, most WebAssembly runtimes are written in Rust, as are the various platforms based on wasm. It also enjoys some of the best tooling, so this result doesn't come as a big surprise."
While Rust usage and desirability has continued to climb, the Blazor web-dev framework is coming on strong in the report, which treats Blazor as a programming language, though it's not. On that desirability scale, Blazor climbed from sixth spot in 2021 to fourth this year among seven "programming languages" [based on] percentage of respondents who use a given language 'frequently,' or 'sometimes' [for WebAssembly development] compared to last year. Eberhardt said, "Rust has had a modest rise in desirability, but the biggest climber is Blazor, with Go following just behind."
Commenting on another graphic that shows which language people most want to use for WebAssembly development, Eberhardt said, "This shows that Rust usage has climbed steadily, but the biggest climbers are Blazor and Python.
While you can now compile WebAssembly from a variety of languages (including C, #C, and C++), the report also found that JavaScript has somehow become a viable WebAssembly language — sort of, and even though JavaScript itself can't be compiled to WebAssembly... There's a cunning workaround for this challenge; rather than compiling JS to Wasm, you can instead compile a JavaScript engine to WebAssembly then use that to execute your code.
This is actually much more practical than you might think.
The rustiest excuse (Score:3, Interesting)
But the rust propaganda certainly is strong in this one.
Re: (Score:1)
Scott Logic is a tiny little irrelevant consultancy that largely just picks up the dregs in the regions they operate due to being both entirely uncompetitive in their package, and having some of the dodgiest recruitment practices I've ever encountered that'll ring alarm bells for anyone half way competent - they pay for lots of different recruitment agencies to find people for them, reject the candidates via the agency, then track the candidates down with their own internal recruiters for example on LinkedI
Re: (Score:2)
OK, clearly you've got some strong (and negative) opinions about Scott Logic, and you are of course entitled to them. But I do want to at least address the facts.
> Scott Logic is a tiny little irrelevant consultancy
462 people, doesn't seem tiny or irrelevant.
> that largely just picks up the dregs in the regions they operate
Far from it, we hire the best we can find. Also, we're not elitest, we pride ourselves on hiring junior folk and training them up.
> they pay for lots of different recruitment age
Ooh, I'm at the Top Again! (Score:2)
O.M.G. (Score:2)
Are you sure "suicide is not an option"??
Re: (Score:2)
Don't worry, the most popular option is C#.
Yeah, I know, here's your cyanide pill.
Re: (Score:2)
Re: (Score:1)
C# is a fine language. Using it outside of the Microsoft environment is a pain, though (that includes mssql).
Re: O.M.G. (Score:3)
A place I worked deployed Unity (the game engine) on Linux via Mono fire some multiplayer game servers and it worked well. (I'd characterize them as "medium-light duty": multiplayer, but not FPS / moba event rate or latency requirements.)
This was already oh 5+ years ago. (they did have to patch since networking stuff for better performance/ stability, but that was more Unity than mono iirc). Dev was on windows.
Re: (Score:2)
Sounds like Unity did the hard work there.
Re:O.M.G. (Score:4, Informative)
Absolute and utter bullshit.
My team is responsible for building, maintaining and running a couple of fairly large applications (as in, hundreds of thousands of daily users) that use a .Net C# backend.
We develop on MacOS.
We build (CI/CD) on Linux.
We deploy on Amazon AWS using Linux containers.
We pay Microsoft nothing - we use Jetbrains Rider for the IDE just fine, the .Net SDK and runtimes are free, we use a variety of databases for storage (none of which are MSSQL).
We have absolutely no problems doing the above - stop propagating the bullshit myth that .Net is difficult on anything but a Microsoft platform. It is in-fact a dream to use.
Re: (Score:2)
How is the LINQ integration?
Re: (Score:2)
That depends on the provider and backend you want to use - there are plenty to choose from out there for various databases and storage systems, but this is an area I haven't really delved into for over a decade anyway as I dont use LINQ for data storage access.
Do you want to ask a more specific question?
Re: (Score:2)
It doesn't work great.
Re: (Score:2)
Well thats a pointless generic-ism, and as such can be disregarded as a weak attempt at trolling.
Re: (Score:2)
Non-sequitur.
Re: (Score:2)
Your comment is nonsense but,
You really need to skill up and stop embarrassing yourself.
I'm glad to hear someone from the C# community talking like this. Normally you hear them saying stuff like, "The benefit of C# is you don't have to know the hard stuff to use it."
Re: (Score:1)
I love C#
Re: (Score:2)
That is wonderful.
Re: (Score:1)
Thank you!
Interesting, but ... (Score:2)
I'll still keep WebAssembly disabled ... don't want/need this.
Re: (Score:2)
I'll still keep WebAssembly disabled ... don't want/need this.
It is unfortunate that, out of all the browsers, the only one that makes this easy to do is Firefox.
Re: (Score:3)
I'll still keep WebAssembly disabled ... don't want/need this.
It is unfortunate that, out of all the browsers, the only one that makes this easy to do is Firefox.
Yup (below). Fortunately for me, Firefox is my usual browser.
javascript.options.wasm = false
This is a little outdated but may offer some useful info: How to Disable WebAssembly [github.com]
I think the "Edge" referenced is the older, non-chrome-based version. The current version of Edge should be configurable like Chrome.
Re: (Score:2)
It's mine as well, despite what sometimes seems like Mozilla's best efforts to drive me away. But the configurability, confined with the excellent cookie management options, just can't be replicated with Safari (or Chrome, for that matter - but, for me, Chrome is a non-starter anyway).
Re: (Score:2)
Re: (Score:2)
Somebody's probably working on a gcc plugin to remedy that, just because.
Just great (Score:5, Informative)
There's a cunning workaround for this challenge; rather than compiling JS to Wasm, you can instead compile a JavaScript engine to WebAssembly then use that to execute your code. ... This is actually much more practical than you might think.
So also running *another* JS engine with its own set of issues and vulnerabilities -- nice. Much more practical. /sarcasm
Too bad (Score:2)
The point (As far as I can remember) was not to replace JavaScript the language, but JavaScript the runtime. If JavaScript the language cannot run on it, it is completely idiotic as 100% of web devs today do JavaScript (or TypeScript which is JavaScript). Way to go to exclude 100% of your userbase.
Re: (Score:2)
Re: (Score:3)
I *like* JavaScript, but I don't trust it. It depends too much on insecure remote packages.
Re: (Score:1)
If only MS would stick with something longer than 2 years... they've made me second guess myself with every iteration of their... everything.
Re: Too bad (Score:2)
Re: (Score:2)
The point (As far as I can remember) was not to replace JavaScript the language, but JavaScript the runtime.
Some of the webassembly alternatives had that goal (asm.js if I remember correctly started with that approach), and V8 from Google is a lot faster.
WebAssembly itself from the beginning had the goal to be like a bytecode that any language can compile to. And it's finally reaching that goal.
Re: Too bad (Score:3)
So IOW the Kool Kids have simply reinvented java craplets from the 90s. And in another 10 years the next gen will realise why they were crap, get rid of wasm and so the wheel revolves.
Re: (Score:3)
And in another 10 years the next gen will realise why they were crap,
Unlikely. They've gotten rid of the main reasons people didn't like java applets (mainly that plugins were awkward).
Nah, the benefits without the crap (Score:4, Interesting)
Nah, the wasm folks understand *exactly* why Java applets and ActiveX sucked. The also understand why people used applets despite the suckage, what the benefit was.
It designed specifically to not suck in the same ways that Java applets suck. It may suck in different ways.
Oracle doesn't own ECMAScript or WASM (Score:3)
So IOW the Kool Kids have simply reinvented java craplets from the 90s.
Just without the threat of legal action by One Rich American Called Larry Ellison.
blazor (Score:2)
Re: (Score:2)
Blazor is... Not very good. The fact it's better than the non existent integration between C# and JS isn't exactly a high bar to reach :D
Re: (Score:2)
Re: (Score:2)
What struck me about Blazor is how *simple* it really is. MS had a pre-existing template engine Razor, and Blazor is almost just the shadow-DOM layer on top. It compares the current rendering to the shadow DOM and updates the DOM with the changes (Blazor Webassembly), or ships the diff to the client (Blazor Server).
They added some support for state (like cascading properties, event binding and expression binding) and that almost it!
To make it work they had to compile the .NET base class library to webassemb
If I need blazing fast speed on the client (Score:3)
If I need blazing fast speed on the client, then I'll program a thick client where I can have better control of how it connects to other systems. This just seems like another silver bullet looking for a werewolf to shoot at. And neither silver bullets or werewolves actually exist in the real world. This makes Wile E Coyotes Acme Portable (security) Holes look more likely.
Re: (Score:2)
If I need blazing fast speed on the client, then I'll program a thick client where I can have better control of how it connects to other systems.
That's easier said than done when you don't know what operating system the user of your thick client uses. Not every user users Windows on x86-64.
JavaScript? Yeah, JavaScript! (Score:2)
Being surprised by this means someone doesn't understand what WebAssembly is.
PyScript / Pyodide (Score:2)