Au contraire: if people can ship WASM to the browser to do what they’re currently doing with JS, but it’s faster, in nearly whatever language they like and just as nice/if not nicer, then they’ll stop writing JS.
I’ve long maintained that the reason that JS is so prelevant and popular is the result of it exclusively being the only language allowed in the browser.
Mozilla has already proven that a Rust WASM can take in the DOM, do all the necessary transformations and hand back the final result faster than JS can transform it. Host binding protocols are the first step in negating the necessity of JS. Once a direct DOM <-> WASM API comes along (and it will), JS will be as good as deprecated.
You're forgetting two relative benefits to JS - it can be written in a text editor and it doesn't require knowledge of a second language, toolchain and compiler. A lot of javascript is still hand written.
Also, deprecating JS would mean deprecating functionality most of the web itself. No one is going to rewrite all existing javascript in Rust or C or whatever and compile it to WASM.
Like it or not, as long as the web exists, javascript has to exist, browsers have to support it.
Are there programming languages that we don’t use as targets that can’t be written in a text editor? I’m not sure what you mean here. I can write Rust, C, C++, Python, Swift, .Net, etc etc in a text editor with no more difficulty than JS?
> it doesn't require knowledge of a second language, toolchain and compiler. A lot of javascript is still hand written.
Have you not seen the borderline arcane processes and quantity of tooling involved in “compiling” and bundling JS applications? It’s nightmarish and far more convoluted than literally any other language I’ve dealt with.
> Also, deprecating JS would mean deprecating functionality most of the web itself.
Oh no, what a pity, large chunks of bloated websites will go away. I’m sure we’ll all miss them greatly, they made such a great difference to our lives. /s
> No one is going to rewrite all existing javascript in Rust or C or whatever and compile it to WASM.
You don’t have to write it in whatever low-level language, I’m sure any number of higher level languages will get support. Also, we dropped flash pretty hard and fast, and I distinctly, distinctly remember a huge number of websites being entirely flash.
It’s maybe not going to go away entirely, but it will hopefully cease to become as popular as it is now.
> Oh no, what a pity, large chunks of bloated websites will go away. I’m sure we’ll all miss them greatly, they made such a great difference to our lives. /s
I don't even know how to answer this... You are proposing to partition the web into a past and future version where almost no site of commercial interest has any incentive to leave the old internet.
Do you seriously believe that a browser without javascript (not a "noscript" addon, just no javascript) could be successful in any way? or say, more than elinks?
> Also, we dropped flash pretty hard and fast, and I distinctly, distinctly remember a huge number of websites being entirely flash.
And some sites still requires it. It is one of the reason I still keep chrome on my computers
He took the risk of creating a botched experience on his platform first. He did not fail and other followed. He was maybe not the single reason why flash declined, but for sure is the one that initiated it.
There is no issue rewriting JS. People do it anyway every year. I.e new frameworks, new tools etc. JS won't be deprecated. It will just cease to be used (i.e like COBOL)
> if people can ship WASM to the browser to do what they’re currently doing with JS
If if if.... That is not what WASM is or whats to be.
> I’ve long maintained that the reason that JS is so prelevant and popular is the result of it exclusively being the only language allowed in the browser.
People who hate JavaScript have long maintained that, without evidence. I can remember writing JavaScript long before it became popular and was still everywhere.
> WASM API comes along (and it will), JS will be as good as deprecated.
A DOM interop spec is underway, which will allow access into the WASM target from JavaScript. It will not allow access from WASM to the DOM, because that is insecure.
I believe you are over thinking this bullet point:
> Ergonomics - Allow WebAssembly modules to create, pass around, call, and manipulate JavaScript + DOM objects
That would allow WASM functionality similar to behavior already present in the browser, but that page does not say where that behavior will occur. Given this is an update to WASM it will likely occur against WASM artifacts. An example would be allowing a WASM application instance to create JavaScript event bindings and DOM artifacts on an internal DOM tree.
It is wishful thinking that an update to WASM would modify the web environment outside of WASM.
I think I’m just really confused as to what you’re saying. In the browser, you will be able to manipulate the browser DOM directly from wasm. That’s all I’m saying. I don’t think I understand what you mean in this reply.
So currently there is demand for a DOM interface in WASM and WASM has none. I have seen several WASM applications that ship markup and then fabricate their own DOM-like instance to accompany that markup to allow web-like behaviors to the WASM application instance. That is a significant amount of overhead. If WASM had access to a DOM interface applications could be written in any language that execute DOM methods on accompanying markup without need for JavaScript. You get the benefits of a self-contained event-driven UI environment with minimal overhead and without need for JavaScript, but just because WASM ships with support for DOM method execution does not necessarily mean that execution reflects a state or environment outside the WASM sandbox.
> A DOM interop spec is underway, which will allow access into the WASM target from JavaScript. It will not allow access from WASM to the DOM, because that is insecure.
More insecure than allowing arbitrary JS like we do now? I wouldn’t be surprised if we do get a WASM DOM API, maybe it won’t start as an official spec, but it’ll eventually happen.
a DOM API for wasm is planned, but IIRC before that people need to standardize the whole concept of external references/GC, so it might be still quite far away.
I’ve long maintained that the reason that JS is so prelevant and popular is the result of it exclusively being the only language allowed in the browser.
Mozilla has already proven that a Rust WASM can take in the DOM, do all the necessary transformations and hand back the final result faster than JS can transform it. Host binding protocols are the first step in negating the necessity of JS. Once a direct DOM <-> WASM API comes along (and it will), JS will be as good as deprecated.