There is an interesting discussion going on here, and I'd like to share a few more thoughts for clarification.
There is a TL/DR at the bottom.
---
My main point is that we should see openness as a primary goal in the design of the web platform, alongside other primary goals such as performance and safety.
What do I mean by openness?
A web app is open, when I, a developer interested in how that app is implemented, can look at its code, and say "hey, this code handles that video, these functions manage those audio nodes that make the sounds I'm hearing, and this code decides what happens when someone clicks on that button," as opposed to "these are some ones and zeroes and I don't know what they do." [1]
What's the benefit of this openness?
I think the benefits are obvious, but for starters, when web apps are open, everyone can learn from everyone else's work. And they can build on each other's work. Web content evolves faster. And all of this is there by design. Authors don't have to opt into it. It's there and it's ubiquitous and it's just how things are. [2]
How does WASM endanger this openness?
WASM doesn't necessarily endanger anything. It's good. It allows devs to make faster apps, experiment with different semantics, and discover better ways to define the higher-level features of the web (as per the extensible web manifesto).
But it could also be bad. Here is a hypothetical example:
Imagine someone writes a graphics library for their app. It doesn't have the bloat of DOM. It's fast. And it allows him to make really cool apps.
But it's in WASM. It's not really a web app. Sure it has a URL and can't hijack your computer. But it's not HTML; others can't read it. It's not hackable. It's not mixable. It's not even indexable. Adblock can't tell its content from its ads. It's just a portable black box with a URL.
And devs have many incentives to write apps this way. Not all apps need to be indexed. And everyone could use the better performance.
So imagine a future where most web apps are made this way, each using a different rendering engine, written in a different language. I think it's clear why that could be bad. (Tell me if it's not.)
So, what do I propose?
I don't propose that we ditch ASM or WASM. These are steps in the right direction.
But we need to recognize that while safety/perf/better semantics are natural needs that drive the design of WASM, openness is not a natural need and it won't naturally affect WASM's design. Let me explain:
People need web apps to be safe; if web apps aren't safe, people won't open their browsers. People need web apps to be fast; if not, they'll have a reason to prefer native apps.
So, we have strong natural incentives to make the web safer/faster/etc. But we don't have any strong natural incentive to make it "open." So "openness," naturally, won't get enough attention.
But if we think that this openness should be a feature of the web, then we should treat it as a first-class feature, among the other features like perf and safety. Meaning that when making a decision about adding a functionality to the web platform, we should not only consider how it affects the web's safety and performance, but also what it does to the web's openness.
And we should communicate that to the community, especially when news like this come out. So that readers just don't assume that the web is only gonna get faster, but that it's openness is still gonna be a goal. This will also help create momentum and community feedback for this goal.
What does having openness as a goal mean in practice?
It probably means that committees would constantly look at what devs do in WASM land, and create standardized, high-level versions of them to be used by all developers [3], and also couple these features with great tooling and other benefits that are hard to replicate for WASM. [4]
This makes sure that developers have all the incentives to try to remain within high-level APIs and standard structures as much as possible (thus, keeping web apps readable/interoperable/etc), and only venture into WASM land when they absolutely need to.
I should conclude by saying that I realize this is probably what WASM's authors intend to do. But imho, it is just not being communicated very well. Many people don't notice that openness is a goal, some don't see its benefits. That's why we should communicate openness as a primary goal and write it in our documents, in huge black letters :)
>> TL/DR: Openness is important. There isn't much community momentum behind it (unlike perf and better semantics). There aren't natural incentives to focus on openness, so it might become an afterthought. Web apps might turn into high-performing black boxes. The black box part is bad. To prevent that, we should take openness as a primary goal, and communicate that with the community.
---
[1] WASM is more high-level than ones and zeros, but you get the point.
[2] Today's web apps aren't really open, per my duck-typed definition of "open." They're only open to some extent. It takes a significant amount of time and patience to understand how a certain feature is implemented in a typical web app. And I believe there is an opportunity to make that much easier.
[3] This is to some extent covered in the extensible web manifesto.
[4] It doesn't mean we should deliberately limit WASM's capabilities though. Let me know if I should explain better.
ps. I use compile-to-js languages exclusively. This discussion is definitely not a matter of taste or resistance to having to learn something new :)
There is a TL/DR at the bottom.
---
My main point is that we should see openness as a primary goal in the design of the web platform, alongside other primary goals such as performance and safety.
What do I mean by openness?
A web app is open, when I, a developer interested in how that app is implemented, can look at its code, and say "hey, this code handles that video, these functions manage those audio nodes that make the sounds I'm hearing, and this code decides what happens when someone clicks on that button," as opposed to "these are some ones and zeroes and I don't know what they do." [1]
What's the benefit of this openness?
I think the benefits are obvious, but for starters, when web apps are open, everyone can learn from everyone else's work. And they can build on each other's work. Web content evolves faster. And all of this is there by design. Authors don't have to opt into it. It's there and it's ubiquitous and it's just how things are. [2]
How does WASM endanger this openness?
WASM doesn't necessarily endanger anything. It's good. It allows devs to make faster apps, experiment with different semantics, and discover better ways to define the higher-level features of the web (as per the extensible web manifesto).
But it could also be bad. Here is a hypothetical example:
Imagine someone writes a graphics library for their app. It doesn't have the bloat of DOM. It's fast. And it allows him to make really cool apps.
But it's in WASM. It's not really a web app. Sure it has a URL and can't hijack your computer. But it's not HTML; others can't read it. It's not hackable. It's not mixable. It's not even indexable. Adblock can't tell its content from its ads. It's just a portable black box with a URL.
And devs have many incentives to write apps this way. Not all apps need to be indexed. And everyone could use the better performance.
So imagine a future where most web apps are made this way, each using a different rendering engine, written in a different language. I think it's clear why that could be bad. (Tell me if it's not.)
So, what do I propose?
I don't propose that we ditch ASM or WASM. These are steps in the right direction.
But we need to recognize that while safety/perf/better semantics are natural needs that drive the design of WASM, openness is not a natural need and it won't naturally affect WASM's design. Let me explain:
People need web apps to be safe; if web apps aren't safe, people won't open their browsers. People need web apps to be fast; if not, they'll have a reason to prefer native apps.
So, we have strong natural incentives to make the web safer/faster/etc. But we don't have any strong natural incentive to make it "open." So "openness," naturally, won't get enough attention.
But if we think that this openness should be a feature of the web, then we should treat it as a first-class feature, among the other features like perf and safety. Meaning that when making a decision about adding a functionality to the web platform, we should not only consider how it affects the web's safety and performance, but also what it does to the web's openness.
And we should communicate that to the community, especially when news like this come out. So that readers just don't assume that the web is only gonna get faster, but that it's openness is still gonna be a goal. This will also help create momentum and community feedback for this goal.
What does having openness as a goal mean in practice?
It probably means that committees would constantly look at what devs do in WASM land, and create standardized, high-level versions of them to be used by all developers [3], and also couple these features with great tooling and other benefits that are hard to replicate for WASM. [4]
This makes sure that developers have all the incentives to try to remain within high-level APIs and standard structures as much as possible (thus, keeping web apps readable/interoperable/etc), and only venture into WASM land when they absolutely need to.
I should conclude by saying that I realize this is probably what WASM's authors intend to do. But imho, it is just not being communicated very well. Many people don't notice that openness is a goal, some don't see its benefits. That's why we should communicate openness as a primary goal and write it in our documents, in huge black letters :)
>> TL/DR: Openness is important. There isn't much community momentum behind it (unlike perf and better semantics). There aren't natural incentives to focus on openness, so it might become an afterthought. Web apps might turn into high-performing black boxes. The black box part is bad. To prevent that, we should take openness as a primary goal, and communicate that with the community.
---
[1] WASM is more high-level than ones and zeros, but you get the point.
[2] Today's web apps aren't really open, per my duck-typed definition of "open." They're only open to some extent. It takes a significant amount of time and patience to understand how a certain feature is implemented in a typical web app. And I believe there is an opportunity to make that much easier.
[3] This is to some extent covered in the extensible web manifesto.
[4] It doesn't mean we should deliberately limit WASM's capabilities though. Let me know if I should explain better.
ps. I use compile-to-js languages exclusively. This discussion is definitely not a matter of taste or resistance to having to learn something new :)