It doesn’t touch the DOM and there’s a VERY good reason for that.
To which most advocates end up saying that’s because the DOM is bad and should be scrapped. Maybe, but now we have put the cart firmly so far in front of the horse that’s is a few days ride away.
Yes, because they haven't gotten to it yet and wanted to release the MVP without that functionality. But that feature is coming (hint: it's called host bindings), so implying that there's some other reason why DOM access from WASM wasn't added is pretty disingenuous. Once that feature and garbage collection arrive in WASM, there will be almost no reason why JS needs to be used on the front end.
Which it will anyway so WASM devs will end up having to be just as careful as JS devs about DOM & UI manipulations or run into the exact same problems.
At which point (the the same problems and issues) there’s really no reason to use anything other than JS for that portion of the application.
WASM is great, but it’s going to be for the parts of the web that JS is not good at dealing with - and that’s less than the crowd here on HN would like to believe.
Err...actually, the theory is hard, and that is a practical problem, because the WASM people actually wanted to have a formal semantics for WASM from the get-go.
That's why they're moving slowly, only releasing what they can specify formally.
Then there is also the issue of the proliferation of substandard JS programmers, a lot of them knowing nothing about basic CS principles, that are viewed as "necessary evil" today. Opening up that space to better programming languages will be a net gain on many fronts.
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.
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.
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.
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.
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.