I thinking realistically about this JS alternatives: it's never gonna happen, that W3C will pick up another language for a browser standard, never, ever. So, do you want a NPAPI solution like what Java did in the last decades? That was great, isn't it? Especially if you are a sysadmin, managing 20+ workstations in a company with different OS + different governmental webapps which requires different java versions to run, with different settings? Feel the pain that sysadmins feel, I also lived in this hell. Upps, luckily that's not possible anymore, because every major browsers, including Firefox, Chrome, Opera, Edge are blocked NPAPI execution and not just that, they removed it from their browsers, so in the last couple of months NOT possible to run Java on the browser anymore. Because, you know, many viruses downloaded into the computers by Java. It was the hacker heavon to have an user installed execution environment on lots of enterprise PCs (JS runs in the browser VM), where you can send any payload you want, after the user accepted the execution. Good bye Java, we will never mis you. But what the government did in this case? Nothing! We run all of these important apps for work in Internet Explorer 11. :) What will happen if Microsoft will release an update to Windows 10, for remove NPAPI support from IE11 as well? Well, probably in this case, every mayor office or government institution, including police, hospitals, army, etc. won't be allowed to update their windows, until not comes a webapp rewrite (which is possible within 2-3 years, in the hurry they work...). Nice, new world isn't it? Thanks to Java and it's never-becoming-a-real-standard execution model. :) Alternative solution is to use an old Firefox/Chrome version as well (I use Firefox 52 ESR in one case, with turned off updating), but luckily, some government java program won't run any other browser, only IE11...
I would be the happiest person if I can program client-side apps using Go (natively integrated into the browser), but as far as Google can implement in Chrome, this still not become a standard by W3C, so it's not worth bothering. Eventually we will have a Webassembly compiler for most of the languages, but at it's current state, without active projects / frameworks, no one using it for everyday tasks, like a client-side rendering library (and I think that's not even possible right now).
The main reason would be to use webassembly for me on the client-side is to protect the source code. If you not program in 3D and you only want to write a client-side 2D apps (like with React, Vue), execution performance is really not that important for companies, instead what is important is product to market ratio. The payload size also important, but I don't believe that an extensive framework (which we didn't saw yet), will be much smaller size in binary then a minified Preact project.
But now they can go and use Elm, Purescript, ReasonML... or maybe something else.
Actually, there's somewhere a Flow library (sorry, I forget the name), which compiles to client side as well, to not strip out the type checking on the client side (I don't know unfortunately, Elm, Purescript or ReasonML have such feature).
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.