Are they here yet? No. Are they performant yet? No idea because they don’t exist.
They’re always brought up by WASM advocates like they solve anything. But they don’t... because the problem isn’t accessing the DOM - it’s doing it performantly in your code and there’s nothing about host bindings that hint they’ll solve that problem any better than JS. So far the signs aren’t positive.
> Are they here yet? No. Are they performant yet? No idea because they don’t exist.
Right, they're not here yet, so you don't know.
> because the problem isn’t accessing the DOM - it’s doing it performantly in your code and there’s nothing about host bindings that hint they’ll solve that problem any better than JS.
WASM solves the problem of allowing languages with different semantics, strong type systems, different paradigms etc. that JS doesn't provide. Some of us care about the language we program in because we want to have somewhat enjoyable experience while doing it and for some JS does not provide that. That is the problem WASM solves. Whether host bindings would give us sufficiently fast access to the DOM isn't clear yet, as you yourself admitted, but I don't see why not and I certainly don't see what you're arguing about here - the problem WASM solves is, again, primarily not about DOM access that is somehow faster than JS, people are even expecting a bit of a penalty, at least initially, but as long as we can get rid of JS monopoly on the front-end, I think WASM achieved its goal.
And neither does anyone posting dumb links to Reddit posts about them or mentioning them like they’re a solution.
Because they aren’t. They might be, but they aren’t yet. Yet WASM advocates like yourself treat them as fully formed solutions to criticism.
Which you kind of have to I suppose: without them WASM is a cool but extraordinarily limited and mostly pointless, outside of some specialized use cases, toy.
Until they are released AND up to par with perf & features (inc accessibility) WASM hasn’t achieved much at all. It certainly hasn’t got rid “of the JS monopoly”. No more than VBScript or Flash did.
> And neither does anyone posting dumb links to Reddit posts
As far as I can see, the person who posted the Reddit link just responded to the claim that there's no way to manipulate the DOM as a way of saying that it is known and being worked on. You seem like a bit of an extremist by saying that anyone is claiming it is the solution. It is a potential solution, that's all.
You were the first one to assert what problem WASM supposedly tries to solve, even as not everyone agrees with your assertions. You basically set up a strawman and then shot it down.
> Yet WASM advocates like yourself treat them as fully formed solutions
I, in fact nobody here apart from yourself, has said that they're fully formed solutions, not even close. They're in development, this is not being denied.
I am also not an "advocate" for WASM, I made a post explaining why I think it makes sense, that's all. When somebody tells you they like rain, do you respond with "So are you advocating for floods"?
> Until they are released AND up to par with perf & features (inc accessibility) WASM hasn’t achieved much at all. It certainly hasn’t got rid “of the JS monopoly”.
No one is saying it ALREADY DID, we're saying this would be a success, if it did. This is really not that hard to understand. Honestly, I am not sure it's the Reddit posts that are the problem here.
WASM is treated like this God like abilities. I’ve spent time playing with it on and off every couple of months.
Sure you,ll be able to port different languages to the web but at what cost? The JavaScript library gives a ton of things out of the box. In WASM land one will probably have to compile their standard library of features and send it to browser. So space wise it’s going to be more.
Then you have the debugging problem, browser venders are doing some improvements in this space but seeing how quirky being able to debug minified code is, WASM debuggers will be interesting and that story is weak.
The reason why JS ecosystem is vast is because frontend development is vast. Creating UIs involves a lot of things. Add different browsers to the mix and you get this complexity because different versions of browsers support different things.
To this day you can always create something in Vanilla js. A single .html file with js and css embedded in it. Nothing stopping you. You need nicer tools and libraries when you want to scale the development. This is true for any language.
JQuery - started out as a way to abstract our browser backwards complexity and give standard api. It essentially is a polyfill library with a nicer syntax.
Angular - A nicer way to compose dynamic apps. They piggy back on html syntax and bring templating to it. Same with Backbone and Mustache. Just other libraries.
React/Vdom - View is a function of state. Another way to think about UIs. They bring html to JS with h(tag, attrs, children) calls. This makes building big dynamic UIs easier.
Babel/Typescript - Some browsers support new things, older browsers don’t. A tool to let you write in newer flavor of JS that down compiles to an older flavor depending on what you want to target. Typescript is a way to get more strictness in your code (like a linter). Sure we can get into a way on how Javascript is an aweful language but there are some things it does really well. I love 2018 JS.
Webpack/Rollup - you can ship a giant .js file with all things concatenated but that’s not optimum. You want things to load fast and this means less bytes on the network. Webpack allows you to write code as small modules that depend on each other. Then you give a starting module and it builds you a js and css file with things you need. You can control how things get bundled e.t.c. This is like creating an installer for your app.
In essence, web ecosystem of libraries is vast because the web ecosystem itself is vast. Little libraries let you pick and choose how you want to stack things up to build for your needs.
WASM is a small part of this vast ecosystem solving a specific kind of problem. We’ll still have those 99 other problems.
Are they here yet? No. Are they performant yet? No idea because they don’t exist.
They’re always brought up by WASM advocates like they solve anything. But they don’t... because the problem isn’t accessing the DOM - it’s doing it performantly in your code and there’s nothing about host bindings that hint they’ll solve that problem any better than JS. So far the signs aren’t positive.