It was always the goal for WebAssembly code living in the browser to have some form of object model/DOM integration, and interaction with JavaScript objects. What form it would take exactly wasn't clear. But that was never a goal for the original 1.0 specification (MVP), and not even in spec for the current 2.0 draft -- which mostly add a bunch more useful instructions and features, but nothing earth shattering.

The reality is that whatever solution gets accepted has to be supported and continue working for what is effectively ~infinite time, in multiple major browser engines. For custom runtimes it's sort of "whatever", but webpages can live forever so it's taking a lot of time to get right. But there was clearly a lot of value to be had without that, hence 1.0 was the "MVP."

I think a lot of people want it to be a replacement for JavaScript. And I think that makes sense, if for no other reason than learning JavaScript is a hassle. Lots of folks think of themselves as a C# developer, or a Python developer or whatever. A lot of developers would rather make websites in their language of choice than learn JavaScript. (And who can blame them?). Webassembly (with GC bindings) should be able to make that possible.

And, while more of a personal opinion, JavaScript is not a well designed language - permanently shackling the web to it prevents progress forward.

There’s a balance between disruptive change and keeping these folks on board. Get it wrong and you’ll end up with it strangled in its cradle.

My own take is that low-code platforms will continue aggressively moving into this space, especially in the enterprise space. They come with their own problems and are often aggressively overhyped, but they will put pressure on “traditional” developers to move faster and look for better solutions.

I do not see a problem here. The idea is not to replace js (not realistic anyway), but to have a full working alternative to not have to use js anymore, so in the end you can really choose how to build for the web.

I also invested heavily into js ... but I am really looking forward to the day, I can use something sane again.

Personally I’m quite happy to blame them. If I want to do ML I use Python, if I do statistics I use R, for messing with Windows I use C#, for using databases I use SQL and for the web I use JavaScript. I think that refusing to learn other languages is a foolish consistency.

Also TIMI on IBM i, language environments on z/OS, among other examples.

> More than 20 programming tools vendors offer some 26 programming languages — including C++, Perl, Python, Java, COBOL, RPG and Haskell — on .NET.

Taken from https://news.microsoft.com/2001/10/22/massive-industry-and-d...

In 2001.

At first it seems like an impressive list of languages! But upon closer inspection, over half of them are either abandoned or are commercial products that have been coasting mostly unmaintained for a decade... By now even the JVM ecosystem is a lot healthier.

With WebAssembly, all languages[1] supported by LLVM can be compiled with no custom compiler nonsense. AND we get all the languages[2] that depend on those languages for free as well! The entire burden is on LLVM (and soon GCC) with everything benefiting downstream, surely you can see how it's different from CLI/JVM?

This time the compile-once-run-everywhere promise might actually be true.

1. C, C++, Zig, Rust, etc 2. Python, Perl, PHP, Lua, we can even do some inception with webassembly runtimes.

Or the money from all those VC firms betting the farm on Webassembly startups will dry out.

Until someone comes up with yet another bytecode format, claiming yet again to be UNCOL from 1958.

https://en.wikipedia.org/wiki/UNCOL

You can do that without WASM. This really reinforces the authors point.

https://dotnet.microsoft.com/en-us/apps/aspnet/web-apps/blaz...

Blazor lets you build web apps using C#. It achieves that by running C# inside WebAssembly.

With wasm-GC, blazor should get way faster and smaller. And the blazor-(JS & DOM) bridge can be massively simplified too. I don't see any good reason for blazor apps to be any larger than the equivalent react app. And that will make it a much more viable platform.

It may get there eventually, but as with most C# things these days, it’s mostly meant to sell other Microsoft products to the horde of developers who view themselves as single language developers. The real risk isn’t so much in the technology, however, it’s in whether or not Microsoft abandons it before it’s good like they have with their previous GUI frameworks going all the way back to ASP classic. I know that angular made a big leap from JS to TS, but aside from that, your major JS frameworks have been fairly stable in the same time frame that Microsoft has gone through web forms, mvc, razor, whatever the hell the web-api bundled with X period was and now Blazor, and what is the most telling of all is how virtually every Microsoft Office365 product is written in JS. Would you really bet on a semi-shitty technology that doesn’t even see adoption within the company that makes it? Well, I guess you do considering you’re using C#.

People who think learning JavaScript is a hassle aren't serious programmers, because what they've actually decided is that learning is a hassle, which is a terrible dead-end anti-intellectual attitude, and they've just decided to blame their learning disability on JavaScript. Real programmers learn new things throughout their entire careers.

Yes JavaScript has flaws. But learnability isn't one of them. And WebAssembly certainly isn't any easier to learn or program in than JavaScript. The problem isn't JavaScript, it's uneducable conservative luddites who refuse to learn anything new (or even as old as JavaScript), who think they know it all already and nothing's ever going to change.

So-called programmers who think they never need to learn any other languages or anything new have much worse flaws than the languages and tools they refuse to learn.

Its much easier to make wasm good. Let Go programmers use go to make websites. Why not? If its any consolation, they'll still need to learn HTML and CSS in the process. Javascript isn't going anywhere if they want to make the switch later.

ChatGPT is not just useful for banging out boilerplate code, it's much more useful for teaching programmers who are willing to learn new apis and how to code in new languages and better in the languages they already know.

And that opportunity is missed on monolinguistic coders who refuse to learn or even read the fucking manual, and just see AI as a replacement for posting "just give me the codes" and copying and pasting from Stack Overflow.

Real programmers aren't going to be replaced by AI. Programmers who refuse to use AI and refuse to learn are going to be replaced by AI and programmers who are capable and enthusiastic about learning.

And according to my experience, WebAssembly is not a game changer: it does not provide extra performance here, neither does it allow to get smaller binaries. I'm a developer of another Java-to-JavaScript compiler, TeaVM. I recently compared performance of JavaScript and WebAssembly targets, and in one particular case WebAssembly is slower: https://teavm.hashnode.dev/comparing-teavm-with-kotlinjs-pef.... There's another example where WebAssembly is only slighly better: https://teavm.org/gallery/jbox2d/index.html. In both cases WebAssembly binary is huge compared to JavaScript. On one hand this can be because of I don't target Wasm GC, so binaries get bloated because of need to maintain shadow stack. On another hand, there's Google Closure Compiler, which produces Wasm GC binaries, and from what I heard of it, WebAssembly binaries still don't win in their size.

That's the underlying messy API it's built on. There are specs to make the API more standardized like https://github.com/WebAssembly/WASI

But overall, yeah, it feels like a shiny new toy everyone is excited about and wants to use. Some toys can be fun to play with, but it doesn't mean we have to rewrite production systems in it. Sometimes, or most of the time, toys don't become useful tools.

https://forum.unity.com/threads/return-flash-deployment-back...

>Flash was not discontinued "because it couldn't provide good graphics". It was discontinued, because we no longer believe that Flash as a platform has any future. That has not changed.

Here are some of my favorite examples:

Figma

Google Earth

Photoshop Web

Any Unity games you've played on the web: WebAssembly.

Everything built using the Blazor framework in C#: runs on WebAssembly on the web.

I really don't think all of those sites are using WebAssembly because it's a cool new toy. They're using it because it's actually pretty useful technology that enables you to build really powerful software that runs on the web browser without being limited to JavaScript.

The Spritely folks are doing DOM manipulation from Scheme in Wasm, is there something beyond this that you're referring to? https://spritely.institute/news/building-interactive-web-pag...

  Scheme.load_main("hello.wasm", {}, {
    document: {
      body() { return document.body; },
      createTextNode: Document.prototype.createTextNode.bind(document)

It's not even that slow to interface with JS from WASM if you do it right (i.e. you aren't passing strings back and forth).

Javascript, on the other hand, is a loose standard that different companies kinda sorta adhere to. It was a rushed one man project put out to compete with Java back in the 90s, then every browser tried to do their own somewhat compatible implementation. Javascript became the lowest common denominator, winning out not because it was better than say Java or ActiveX or Flash or whatever. It was just commonly available.

Fast forward a couple decades, the situation is both better and worse. We at least have ECMAScript now, and the core language has certainly gotten better and more dev-friendly.

Unfortunately, what ECMAScript covers is so limited and the standard lib is still so poor that lodash and similar are common just for basic data manipulation, not to mention the hundred DOM abstractions like React or Vue or Svelte, and occasionally Angular. And client-side state is its own nightmare, and then persisting things into cookies/localstorage/indexedDB is a whole other can of worms, along with different ways to do pub sub. Being tethered to file-based HTTP and HTML means that even basic routing is a hack on top of a hack.

There is no standard package manager, and npm is a third party project, which can't agree on which module format to use. Libs from like 2 or 3 years ago will often be incompatible with new code.

And that's just assuming you're using a browser. Outside of that there's not even a standard runtime, between Node, Deno, Bun, etc.

Typescript is yet another third party add on, not something baked into the language.

Eslint, prettier, etc. are all third party things.

In the old days a lot of this used to just be baked into the language itself, or at least an official IDE . If you ever had a chance to use Visual Studio (Not VSCode) in the old days, everything was so well designed and integrated, from code organization to the standard libs to the UI editor.

Nowadays there's 300 ways from 200 companies to do anything in Javascript, none of it particularly good or secure or performant or easy to read.

In a way it's natural selection, I guess, with different implementations all competing for supremacy, but it definitely is messy. Every time I use JS (which is every workday) I can't help but wish some other, more coherent, language won out.

JavaScript does incredibly well for the constraints it operates within. The fact that Node and Deno etc even exist is pretty remarkable given the primary purpose of JS.

The fact we even have ES modules is in large part because the third party NPM worked so well. Things start out messy then they gain traction and get standardised. JS isn't a loose standard at all, it's incredibly well defined, and few of its original Netscape origins really remain.

You have a bit of a point about TypeScript. It'd definitely be nicer if this was part of the language and didn't require so much third party tooling. It seems plausible that this too might happen in a few years. Perhaps browsers will gain first class support for it.

- JS as a three week project is amazing

- JS as a lingua franca for web is a disaster in the same league as null pointers. It is like if backend had decided to standardize on PHP early on (if you disagree, try to mention one thing except syntax that isn't as bad in JS as in PHP, and the syntax is actually a blessing in disguise, if JS had looked like PHP it wouldn't had become a standard)

- The fact that people has made a very productive ecosystem on top of the collection of footguns that is Javascript is of course equally impressive if not more

Please note that this post praises both the inventor of JS as well as the JS ecosystem.

But that does not mean that Javascript is a good language.

Benevolent dictatorship has it's advantages. The JavaScript ecosystem is messy -- exactly why is up for debate and whether that's good, bad, or unimportant is also up for debate.

You know, I never really thought about it that way, but I think you're right!

<lazy dev hat>That WOULD be nice! A standard way to do anything, no need for unnecessary reinventions of the wheel... progress would slow down a bit, sure, but that's OK, nobody can keep peace with this lightning-fast explosion anyway, and slow and steady is more sustainable than volatile bubbles everywhere anyway. I think I would enjoy working in such a system...</lazy hat off>

<open source hat on>Unfortunately, that'd also mean a closed ecosystem and we probably wouldn't have had the amateur dev boom that HTML/JS/CSS and its visible source gave us. I hate the messiness of that ecosystem, but I can't deny that the openness gave a boatload more people opportunities than the closed platforms. Maybe that's just the price we have to pay =/ </hats away>

> Perhaps Swift is where you would like to be?

I never tried. Is it nice? As a user I find iOS quite obnoxious, but maybe developing for it is different...?

The browser APIs are specced by W3C and WHATWG. For newer APIs there are usually differences in browser implementations, but these tend to get ironed out quite fast.

I've been writing JS since its invention, initially just using it (as a kid) for silly Geocities gimmicks and infinite window.alert() loops. I still remember how back in the day no two browsers had a totally compatible JS implementation (especially when Microsoft was busy trying to embrace-extend-extinguish), some things would be subtly different (like datetime handling, or window vs document, whatever)... it wasn't just me either, there used to be a lot of articles that discussed things like that. Here's one: https://burningbird.net/netscape-navigators-javascript-1-1-v...

In my memory, nobody really discussed ECMAscript back in those days. It was more about Netscape/Mozilla vs IE vs Phoenix's JS engines (can't remember if Phoenix used the same JS engine as Netscape), and then different versions of jQuery or early Angular, browser prefixes, early polyfills that you copied and pasted manually, etc. Even up till a few years ago, it was still quite common to have to check CanIUse to make sure a method was supported everywhere.

It was ES6 that really brought ECMAscript into popularity... this Google Trends graph shows the correlation somewhat, though both are totally dwarfed by "Javascript": https://trends.google.com/trends/explore?date=2004-01-01%202... (and it doesn't go back to the 90s, only 2004).

And the ECMAscript core definition is very narrow, only dealing with core language features and not the greater JS ecosystem, which is how we end up with a bazillion runtimes, TypeScript, third-party libs for everything from components to deep copies to state and routing and testing etc. ECMAscript by itself is super barebones, maybe enough to make a simple serverless func with, but hard to write an entire app in without third party frameworks and libs.

I can't speak to C++ (never worked enough in it), but even PHP by comparison had a wonderful standard library, and de-facto standards in the form of Symfony and Laravel that provided most of the missing use cases. In the JS world it wasn't until AngularJS that we really had something like that (but nobody wanted to use it), and now finally Next.js (which is thankfully super popular). Even then, you had to supplement those on the HTML side with something like Bootstrap, and on the CSS side with something like SASS or LESS. (Thankfully, CSS itself is also getting better these days.)

---------

I don't know that this anecdote really disproves anything you're saying (and it's not meant to), just illustrating that even when standards exist on paper, the ecosystem is of a language is more defined by its real-world usages. And for both JS and its siblings (HTML, CSS, SVG, Canvas)... the journey to get to where we are today was very, very messy and full of a million incompatibilities.

This is a relatively recent development in programming languages. For example, your next sentence:

> Javascript, on the other hand, is a loose standard that different companies kinda sorta adhere to.

This could also describe the history of C. For example, let's look at the rationale document for the first standardization of C: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n802.pdf

I apologize in advance for quoting at length, but I could not decide what should be cut.

---------------------

The X3J11 Committee represents a cross-section of the C community: it consists of about fifty active members representing hardware manufacturers, vendors of compilers and other software development 10 tools, software designers, consultants, academics, authors, applications programmers, and others.

<snip>

The Committee’s overall goal was to develop a clear, consistent, and unambiguous Standard for the C programming language which codifies the common, existing definition of C and which promotes the portability of user programs across C language environments.

The X3J11 charter clearly mandates the Committee to codify common existing practice. The Committee has held fast to precedent wherever this was clear and unambiguous. The vast majority of the language defined by the Standard is precisely the same as is defined in Appendix A of The C Programming Language by Brian Kernighan and Dennis Ritchie, and as is implemented in almost all C translators. (This document is hereinafter referred to as K&R.)

K&R is not the only source of “existing practice.” Much work has been done over the years to improve the C language by addressing its weaknesses. The Committee has formalized enhancements of proven value which have become part of the various dialects of C. Existing practice, however, has not always been consistent. Various dialects of C have approached problems in different and sometimes diametrically opposed ways. This divergence has happened for several reasons. First, K&R, which has served as the language specification for almost all C translators, is imprecise in some areas (thereby allowing divergent interpretations), and it does not address some issues (such as a complete specification of a library) important for code portability. Second, as the language has matured over the years, various extensions have been added in different dialects to address limitations and weaknesses of the language; these extensions have not been consistent across dialects.

One of the Committee's goals was to consider such areas of divergence and to establish a set of clear, unambiguous rules consistent with the rest of the language. This effort included the consideration of extensions made in various C dialects, the specification of a complete set of required library functions, and the development of a complete, correct syntax for C.

The work of the Committee was in large part a balancing act. The Committee has tried to improve portability while retaining the definition of certain features of C as machine-dependent. It attempted to incorporate valuable new ideas without disrupting the basic structure and fabric of the language. It tried to develop a clear and consistent language without invalidating existing programs. All of the goals were important and each decision was weighed in the light of sometimes contradictory requirements in an attempt to reach a workable compromise.

---------------------

In general, standards that follow this path, codifying existing practice, that serve to coordinate interest between various actors, tend to work better than specifications that are written up-front and then followed by implementation. You can see this operating in a smaller way within current standards bodies and organizations, as you yourself alluded to with "relatively centralized."

> Javascript became the lowest common denominator, winning out not because it was better than say Java or ActiveX or Flash or whatever. It was just commonly available.

This statement is shockingly similar to what people say about C, as opposed to various other languages that were in the same space around the same time.

Nothing's more standard than Javascript these days. Not even close. It runs the same way on billions of devices across virtually all existing architectures.

    [] + [] = ''
    [] + {} = '[object Object]'
    {} + [] = 0
    {} + {} = NaN
    Array(16).join('wat' - 1) + ' Batman' = 'NaNNaNNaNNaNNaNNaNNaNNaNNaNNaNNaNNaNNaNNaNNaN Batman'

WebAssembly component-model is being developed to allow referring to and passing complex objects between different modules and the outside world, by establishing WebAssembly Interface Types (WIT). It's basically a ABI layer for wasm. This is a pre-requisite for host-object bridging, bringing in things like DOM elements.

Long running effort, but it's hard work and there's just not that many hands available for this deep work. Some assorted links with more: https://github.com/WebAssembly/component-model https://www.fermyon.com/blog/webassembly-component-model https://thenewstack.io/can-webassembly-get-its-act-together-...

A preview-2 should be arriving sometime somewhat soon.

It's just hard work. It's happening. And I think the advantages Andy talks to here illuminate very real reasons why this tech can be useful broadly. The ability to have plugins to a system that can be safely sandboxed is a huge win. That it's in any language allows much wider ecosystem of interests to participate, versus everyone interested in extending your work also having to be a java or c++ or rust developer.

Edit: is this it? https://www.spritely.institute/news/building-interactive-web...

Edit again: apparently I had seen this before, since I upvoted its HN submission. Oops! https://news.ycombinator.com/item?id=38477602

TypeError: WebAssembly objects are opaque

When trying to read/write WASM-GC objects in JS.

What I personally find annoying is the debate-bro attitude that expects every statement anyone makes that you disagree with to be made with an entire supporting argument with multiple examples or citations, especially when the general reasons someone might believe that statement are pretty well known. And expressing their opinion on thr quality of JS wasn't unnecessary, it was literally necessary to explain why they are excited for the potential of WebAssembly.

> contempt culture

Oh that essay. Thinking a technology is bad and stating so, even making fun of it a bit, is not inherently mocking or degrading the skills or legitimacy of the people that use it. The author of that essay was right we shouldn't mock or degrade the skills (or other aspects) of anyone, but they can't seem to realize that making fun of a language isn't tantamount to mocking the people that use it, and if someone feels that's the case, maybe they should learn to separate their ego / sense of self worth from the tool they use, so we avoid language or editor flame wars by way of greater maturity, instead of by way of walking in eggshells. Especially since languages can be better or worse. Seeking a kinder, more inclusively spirited community is commendable, but expecting every opinion about language quality to be either kept in or perfectly sourced is a blind and misplaced excess of enthusiasm in that direction. And I say this as someone who supports things like DEI and CoCs.

For myself, I think JavaScript has a lot of warts, but not really any more than a lot of popular languages, and the core of it is very well designed indeed, but I just personally don't prefer to use it. Just in case you were going to assume I'm responding this way because I want to be able to make fun of JS. I don't. I just find this style of thinking annoying.

That's very tempting, but you lose a lot if you do that, especially around text:

* Accessibility for screen readers, etc.

* The easy ability to select text, copy/paste between other apps, etc.

* Line splitting

* Support for multiple languages, RTL, and all their other rendering quirks.

Canvas has some text APIs, but they are fairly rudimentary. It's a hard problem.

That's an understatement for sure. `measureText` is not even close to feature parity with where windows apis were 25 years ago.

Or something like text underlines has to be done entirely manually.

It requires a lot of extra work, but real world apps like Figma [0] are rendering directly to the canvas, and frameworks like Flutter offer support for canvas rendering (via Skia's CanvasKit) [1] [2].

I guess my point is that if someone is using WASM to ditch JavaScript, why stop there? Ditch the DOM and CSS too! Render all of the graphics with OpenGl or WebGPU!

There is a class of applications that I want to explore that would be better suited to by doing just that. I don't believe every app should do that, just that for what I want to build, that's where I'm looking at going (hence my "if it were up to me" comment above).

[0] https://www.figma.com/blog/building-a-professional-design-to...

[1] https://docs.flutter.dev/platform-integration/web/renderers

[2] https://skia.org/docs/user/modules/canvaskit/

We tried this with flash already. It has the same issues. Browsers provide _a lot more_ than just rendering your html+css. There are cases where it makes sense, but generally, it's a terrible idea. It will be like trying to make a visual novel using youtube in-video links.

well_thats_your_opinion.jpeg

Javascript is great and the web became what it is today because of it, not in spite of it.

The biggest thing is some kind of graphics capability.

What I think happened, if you look at the web assembly design discussions, is that they made the initially correct decision to limit the scope to be more manageable, but then over the years that decision became something of a religion and even a strange badge of honor.

"Web assembly is not meant to replace JavaScript". It certainly is challenging to try to standardized on anything like device input or graphics APIs, but after say three years, competent and sane designers obviously should have been working on that.

Maybe I am a conspiracy theorist (I am) but I sometimes suspect that Google has deliberately limited the scope of web assembly in order to maintain the control that the dominance of Chrome provides them. Because if things like keyboard/mouse and graphics had some type of web assembly standard, then it would be easy for different runtimes to support them. Then before you know it, you don't need the browser for most things, you can just use your favorite web assembly runtime.

I will go so far as to suggest that this is an antitrust issue and that a technically competent government (of which maybe non exist so far) would have somehow forced the development of an evolvable shared standard like web assembly that is not missing important pieces like graphics.

I see web assembly as the obvious successor to Java. It's been held back by some strange psychology and maybe even intentional sabotage.

For some reason browsers didn't want to "balkanize the web" for the really good reason of supporting multiple languages, they wanted to do it for very petty reasons like WebMIDI or wildly differing implementations of LocalStorage (e.g. how much you can put in there), or non-overlapping support for video codecs, etc etc etc.

Sure, for applications that really need to strip the overhead of a scripting language, it is very welcome. But for the average website? Not sure about it...

And security is another matter, there is a reason the WebAssembly sandbox is so restrictive.

Webassembly is awesome, but the solution needs to fit the problem.