[wwweston]

> The open web has nothing to do with "view source". It never did. "View source" just makes debugging easier.

This is about as true as the idea that the only use of seeing source code is debugging (or building/deploying your own version of the app).

Which, of course, every developer here knows is not true.

Reading source code is useful for figuring out how to do something you didn't know how to do. It's useful for discovering idioms you didn't know, even if you already knew another way. It's very useful if you're trying to do bookmarklets/extensions/mashups or even more significantly engineered interop.

I don't know if there's a formal gatekeeper out there with a list of all the things that capital-O Officially make the The Open Web(TM) great, so I guess there's no way to settle what's on it.

But I don't know how anyone could argue that these things weren't significant bullet points in a much longer list of reasons why the web has seen faster and broader adoption than any of the competing VMs and why it was/is often more useful and nice to work with despite more limited capabilities.

And I think it goes almost without saying that list is much bigger than the "no single gatekeeper" point.

> you're fighting against WebAssembly because you are ideologically against black box software

I am neither fighting against WebAssembly nor ideologically against any kind of black box software. My earlier comment makes it clear I think WebAssembly has a place (and, more generally, that transpiling does) as well as its hazards.

I am stepping in to point out that Flash and WebAssembly have significant things in common, some of which are tradeoffs against things that have made the Web an effective and proliferating medium.

> [JS] some important deficiencies with respect to typing and static analysis

See my aside about Elm. Given the fact that dynamic languages (including maligned ones like JS and even PHP) seem to be about as equally successful in terms of shipped software as statically manifest typed languages, whether or not even something like TypeScript is really going to give engineering teams an edge seems like far from a settled question to me. But I'm interested to see what happens where we're talking significantly augmented capabilities rather than the largely aesthetic differences that something like CoffeeScript represents.

(Speaking of which: "TypeScript, Flow, Dart, CoffeeScript"... at least one of these things is not like the others if you're invoking static analysis and typing as reasons for transpiling.)

> You say that other people's problems with JS are "superficial", but that's exactly how I see your problems with WebAssembly.

I can't tell exactly what you're saying here, but at a close approximation, it sounds like you might be suggesting that the readability of WebAssembly is going to be on the same order of difficulty that an experienced Python developer has reading idiomatic human-written JS (ie, aesthetic). This is potentially possible, I guess, in a world where everyone writing compilers that target WebAssembly is conscientious at/above the level that the CoffeeScript developers were (CS output is really fairly readable, arguably more so than minified JS). But then again, that's not what the name suggests WebAssembly is for. In practice, most of the time it's probably going to read... a lot like assembly language dressed in C-like syntax.

[spion]

> Given the fact that dynamic languages (including maligned ones like JS and even PHP) seem to be about as equally successful in terms of shipped software as statically manifest typed languages, whether or not even something like TypeScript is really going to give engineering teams an edge seems like far from a settled question to me

I'm always so frustrated when I read this, because I've worked on a few dynamic language codebases as well as seen a few open source ones on github. Very often I see the pattern of the project contributors losing control over the dynamic language project. They slip up, the tests become insufficient and now they refuse / are afraid to touch critical parts of the code. Soon development slows down to a crawl. Or rather, there are no more changes - only additions / grafts to the existing codebase.

When I first started using TypeScript, I feared that I'm going to lose the benefits of a dynamic language and that I'll have to write a lot more boilerplate. I had no idea how little of that was true. TypeScript really goes out of its way to model as many JS idioms as possible, including some really dynamic ones:

  * Structural types are formalized duck type checking. You don't 
    have to say your object implements an interface: if it has all 
    the right fields, and they're of the right type, it does. This is 
    similar to Go interfaces (but a bit more powerful in what it can express).
  * Unions types plus type guards can model dynamic function arguments
  * Intersection types can model record (object) merging

The entire type system in TypeScript is basically a formalization of the typical duck typing patterns that are common in JavaScript. As a result, TypeScript can model almost any common JS idiom. The loss of expresivity was very minimal - maybe 1% of the most dynamic code only. And even there, you can tell the type system "I know what I'm doing" (cast to `any`), turn it off, do your dynamic stuff and then tell it the resulting types (cast to whatever types are the result before returning).

Given the above, theres been absolutely no doubt in my mind whether TypeScript gave us an edge or not. Its been incomparably better than just plain JS.

[devsquid]

Hey incase you aren't aware, having WASM output a human reading version is part of the spec.

"define a human-editable text format that is convertible to and from the binary format, supporting View Source functionality." https://github.com/WebAssembly/design/blob/master/HighLevelG...