If people start writing Python for the web for no other reason than they just dislike JavaScript we're going to be forcing users to download a dozen different runtimes, just because of developer preference. This isn't a good thing.

Why would users need to download a runtime, given that we'd have WASM as a compilation target for Python, the language?

I remember seeing a demo of React Canvas a few years ago - basically, recreating a "DOM" of sorts inside a canvas tag - and the performance was crazy. Beautiful 60fps touch interactions. But, of course, it only does a tiny subset of what the DOM does. I'm still waiting for a good reason to use it myself to try out how the API feels.

WebAssembly is very cool techonology, but it's not going to deprecate Javascript because Javascript will be, at least for a very long time, the only scripting language that runs efficiently on the web, and also will always be the most well supported.

With WebAssembly you could write in any AoT compilation language that can compile on LLVM, but I, and many many other developers, have no interest in very low level languages like C, C++, or Rust in the browser, even though we acknowledge the flaws in JS. Maybe one day higher level languages besides Javascript will be practical, but that's a ways away.

I mean, that's kind of already the case when you want to ship a Python project as a stand-alone package to run on the desktop. Alternatively, I could see a method of installing runtimes into your browser like plugins so it doesn't have to be shipped over the wire every time. Not saying I'd ever want to do something like that, just that alternatives exist. Browsers are moving more and more towards VMs that transcend the context of a single synchronous request/response.

> And when webassembly arrives that will be over,

I really don't think this is true. I certainly agree that JavaScript isn't the perfect language, but it's a _very_ popular language. Even on the server-side, where right now you already do have the freedom to use languages like Haskell, Python, etc, you see a majority of developers now opting for Node.js. Even for desktop apps and data scientists, it's the most popular contender (all according to the latest SO survey).

You can argue about reasons all you like, but I don't think the people using JavaScript on the web are doing so only because webassembly isn't easily available yet. I think they're doing so because, for better or worse, they genuinely want to be using JavaScript (or very closely related languages like TypeScript).

WebAssembly will be great, but as a complement to Typescript, not as a replacement. I would love to import a native module for the small chunk of my code that needs to do heavy lifting. And I don't see any reason why the Typescript team couldn't eventually build a WebAssembly compatibility layer.

is basically a better way to do ASM.js . How many Python,Haskell,Livescript have been built on top of ASM.js ?

Do you really believe you can make your users download 10s of megabytes of binaries each time they visit a website just to bootstrap a language? And i'm not even talking about the runtime...

Right now, the only viable languages for webassembly are the ones that don't use garbage collection and have a limited runtime, Rust,C and C++ .

ES5 was a dumpster-fire. But ES2015+ is an amazing language. You just have to take the time to systematically study it.

If you're choosing a language you'll spend thousands of hours with, you shouldn't use "initial learning curve" as sole criteria.

make an object:

in ESx:

  var myObject= {
  	a: {
  		b: {
  			c: {
  				d: 'some value'
  			}
  		}
  	}
  }; 

  myObject= a: b: c: d: 'some value'

in ESx:

  console.log myObject.b.c.d			// crash, myObject.b does not exist

  if ( myObject.hasOwnProperty('b') and myObject.b.hasOwnProperty('c') ){
  	console.log myObject.b.c.d		// undefined
  }

  console.log myObject.b?.c?.d		// undefined

myObject= a: b: c: d: 'some value'

Is really _that_ much of an improvement over:

myObject = {a: { b: { c: { d: 'some value' } } } }

especially combined with an editor that will match those closing brackets for you. And the reality is that if you have object literals that deep, chances are the inner values will also be large enough to justify expanding it anyway.

Also lodash plugs a large number of holes in the standard functionality. In most projects I work at, I'd write something like:

_.get(myObject, 'b.c.d')

for your second example.

Manipulating the DOM from wasm shouldn't be any slower than Javascript. Slow in general because of the DOM, perhaps, but not because of wasm.

Much of that is already possible and guess what, neither TypeScript nor JavaScript are deprecated.

    "'compile the VM' strategies increase the size of 
     distributed code, lose browser devtools integration, can 
     have cross-language cycle-collection problems and miss 
     optimizations that require integration with the browser" [1].

[1] https://github.com/WebAssembly/design/blob/master/FAQ.md#is-...

Of course, lots of other problems remain, for example, downloading an entire runtime or "putting Python on WASM isn't going to magically make it fast". But I don't think the GC should be a particularly large challenge.

I mean, on the backend, there's no ultimate technical reason why you couldn't switch -- the closest you can come to the browser situation is the limited PHP hoster of the early oughts -- and still we don't see a rapid progress away from awful languages. Just more people duct taping said languages into something slightly more sane.

We'll get the same for JS. It's the new Pascal/C in that regard.