> Everyone thought WASM would enable developers to write code in any language they wanted (with type checking and higher performance) and deploy it on the web.

https://developer.mozilla.org/en-US/docs/WebAssembly/Concept...

> WebAssembly is a different language from JavaScript, but it is not intended as a replacement. Instead, it is designed to complement and work alongside JavaScript, allowing web developers to take advantage of both languages' strong points

"Not intended as a replacement"

WASM is a math coprocessor for JS. WASM can't even talk to the DOM API directly (which is the API you use to build web pages in JS); you have to write JavaScript glue code for any/all I/O in WASM.

> WASM can't even talk to the DOM API directly

For now. It's planned.

For existing code bases that don’t already do DOM manipulation (so, all of them) other parts of the Web API might be more useful, like the canvas, the video API, the RTC API etc.

The issue in general is how to bridge these JS OOP APIs to something that's basically assembler.

If WASM gains a foreign object model calling convention or whatever, we're in game.

Wasm is not basically assembler, it's (going to be) very high level:

- https://github.com/WebAssembly/reference-types

- https://github.com/webassembly/threads

- https://github.com/WebAssembly/exception-handling

- https://github.com/WebAssembly/function-references

- https://github.com/WebAssembly/gc

Though it is true that the original MVP was very barebone and could be compared to assembler. However, the reference types proposal has been shipped in all major browsers and is considered "finished".

That was the idea, the world decided otherwise based on the Flash and Silverlight experience versus clunky Web.

https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor

https://platform.uno/

https://leaningtech.com/

https://flutter.dev/

https://wiki.qt.io/Qt_for_WebAssembly

>JS Developers come in: so we can compile node.js to WASM and run that in the browser?! Yay!! Now we can have backend JS running in the browser alongside browser JS!

I remember back when SOAP still had the upperhand against REST but just barely the W3C published a document where they showed how you could implement HTTP over SOAP to basically mass ridicule. Unfortunately can't find it anymore, but it was pretty funny.

searching "HTTP over SOAP" finds a few leads:

Tim Bray, 2004, "HTTP over SOAP!?!?!?": https://www.tbray.org/ongoing/When/200x/2004/05/01/SRRH

Erik Wilde, 2008, "HTTP over SOAP over HTTP": https://dret.typepad.com/dretblog/2008/11/http-over-soap-ove...

William Vambenepe, 2008, "WS Resource Access working group starting at W3C": http://stage.vambenepe.com/archives/436

Here are some of the specs:

Web Services Transfer (WS-Transfer). This specification describes a general SOAP-based protocol for accessing XML representations of Web service-based resources. https://www.w3.org/Submission/WS-Transfer/

Web Services Resource Transfer (WS-RT). This specification defines extensions to WS-Transfer. While its initial design focuses on management resource access its use is not necessarily limited to those situations. https://www.w3.org/Submission/WSRT/

it was the document referred to by Tim Bray, 2004, "HTTP over SOAP!?!?!?", I also remember the Tim Bray article as one of the top pieces of ridicule.

Typically when you see stuff like this be Chromium-only, it's because Chromium has a bunch of non-standard/one-vendor-only stuff enabled in production builds and neither Firefox or Safari have it enabled (or implemented at all). A few examples include Bluetooth, MIDI and USB.

I don't understand why you are downvoted. Filesystem access is another big one! Chrome has the technological advantage and sports an enormous kitchen sink of features. One has to make the hard decision, work on a concept that will work only on one browser, try to cut corners with graceful (or crippling) degradation, or wait potentially a long time until a spec is standardized and implemented. The latter may result in others hitting the market sooner, so it is understandable why we end up with web-apps that function in a single browser only. Hopefully this improves in the future.

The down side is that some of these technologies never get standardised and eventually get dropped. Like NaCl and PNaCl.

Or for an example that caused a lot more havoc comparatively: WebSQL.

Browser Javascript suffers from not producing a single "binary" as its build system output. You do get one bundle, but none of the parts know anything about each other, and it limits the ability to optimize. (It is a lot more like the C preprocessor, rather than a C compiler.) Methods that can't possibly ever be called end up being sent to each user, for no reason other than "well someone could write an eval() that needs that". (I was surprised how poorly tree-shaking works in practice, and how even "light" frameworks like Svelte ship a huge runtime to every user, unrelated to what features the code actually uses.)

Meanwhile, WebAssembly suffers from there not being a good programming language that compiles to it natively. I think the Go support is great, but there's no library support for building the webapps that people get paid to build (React, Apollo, etc. all exist for a reason, however much you hate that reason). AssemblyScript was supposed to be this language, but it's just a Typescript-inspired programming language, it's not Typescript and the npm ecosystem.

I don't know what the details of this implementation are, but the direction I'd like to see web development move is having a statically typed language that compiles to VM bytecode. This sounds like the first step for removing Javascript as a Typescript intermediary. Once that happens, then modern programming language features can be bolted on, people can add good compiler optimizations that result in minimal bytes output for users to download, the module system can be made stricter (like "go mod"), etc. Javascript is just a little bit more dynamic than anyone really wants, and it makes the build/deployment tooling complicated and, frankly, kind of bad.

Tree shaking works poorly, but is also thankfully not that important, unless you're terrible with managing dependencies.

Why? Because the initial parser is relatively cheap. This makes all of the code available, even if a stray eval() calls something unexpected.

The real resource expense comes when it's time to JIT a hotspot. But a hotspot is by definition code you use for sure. And code you use a lot.

JS engines use tracing JIT. Tracing allows JIT compilers to see how code runs in practice, and compile THAT to machine language. How it's organized on the file system etc is entirely irrelevant.

So basically in a trace JIT system, code that isn't hot is interpreted, and code that is hot is JIT-ted (and code that's very hot, gets JIT-ted with higher optimization).

Interpreting is the new "tree shaking". It saves the compiler a lot of work, but also it won't crash your app (unlike bad tree shaking).

> the direction I'd like to see web development move is having a statically typed language that compiles to VM bytecode.

Java… you want Java. And so the cycle continues!

You could add some kind of security manager to sand box it and have little apps running in the browser. Maybe call them "applets".

That sounds amazing! What if they came with some kind of built-in canvas?

That's a really good point. What we wanted all along was the JVM with a DOM API.

We started with Java. It didn't gain any traction for browser scripting. They took "Java" out and called it JavaScript. Now we take the "script" out and call it WebAssembly. If someone in 1995 made Java a DOM-editing thing instead of an applet thing, we could have saved 25 years of running around in circles :)

(Going back even further, we all connected to a mainframe with a dumb terminal. The desktop revolution happened... and now we're back to dumb terminals attached to a mainframe. But we call it "The Cloud" instead, and the dumb terminal fits in your pocket.)

Maybe the past wasn't as dumb as we think it was. We just weren't smart enough to understand it at the time.

Hey applets could manipulate JavaScript data/the DOM. There is a bit of bark to the 'Java script' bite. It was very slow, though, sending through the JVM process and to the browser process each time you read or wrote a value (and the plugin that did this I think was in its own process - memory is hazy there).

Overall it's hard to say how Sun could have won here, perhaps acquiring macromedia and using Flash technology to make a browser that ran those cool portals out of the box, and hey scripted first-class in Java too btw ;-)

And we’ve increased latency an order of magnitude each time. We have computers that are orders of magnitude faster, yet using a spreadsheet in a browser today is less responsive than it was in DOS decades ago. But the developer experience is so much better now, so it’s worth it?

What I’ve always wanted is scheme in the browser.

There was a fork in the road of history, where that could have been the future we live in..

> In 1995, Netscape hired Brendan Eich with the promise of letting him implement Scheme (a Lisp dialect) in the browser.

How JavaScript Was Created - http://speakingjs.com/es5/ch04.html

---

> Whether that language should be Scheme was an open question, but Scheme was the bait I went for in joining Netscape. Previously, at SGI, Nick Thompson had turned me on to SICP.

> ..The diktat from upper engineering management was that the language must “look like Java”. That ruled out Perl, Python, and Tcl, along with Scheme.

https://brendaneich.com/2008/04/popularity/

Yeah, I know this history well.

Like this? https://github.com/biwascheme/biwascheme

No, like

    <script type=“text/scheme”>

I also wish browsers had built out the ability to plug-in interpreters for processing script tags.

Here, https://github.com/google/schism

The past was pretty dumb, because it wasn't an open standard based on interoperability.

Or preferably, F#.

> WebAssembly suffers from there not being a good programming language that compiles to it natively

Is Grain insufficient for some reason?

I think the issue isn't with Wasm support, it's the filesystem API. They could've included a polyfill though... But as that API is new it might not be available yet.

It's the "File System Access API," the one that allows the browser to read/write files on your actual computer. It's an I/O feature, impossible to polyfill.

The similarly named "FileSystem API" gives you access to a sandboxed "virtual drive" in the browser. Firefox has supported that for years, and polyfills are possible, but it's irrelevant in this case.

https://caniuse.com/?search=file%20system

I believe it still counts as a polyfill, even if it doesn't do what it says on the can (but it has compatible interface, so your app runs).

I wonder if this would work in electron?