随着Web的新时代的到来，WebAssembly，这是要在合作由谷歌，微软，苹果和Mozilla设计：WebAssembly，JavaScript和其他语言
WebAssembly高级目标
- 定义一个便携的，尺寸 - 和负载时间高效的二进制格式，作为其可被编译以原生速度来执行通过利用共同的硬件能力上广泛的可用汇编目标的平台，包括移动和物联网
我想问问那些谁已经拥有这方面的知识：
有可能任何编程语言编译成WebAssembly一旦其发？让它成为C＃，Java，Python，JavaScript，Ruby。如果是这样的话 - Web开发人员可以选择任何语言来完成他现在用JavaScript实现的目标吗？
目标确实是支持任何语言，但支持任何语言都很难在没有大的延迟的情况下得到支持。
WebAssembly目前专注于传统提前编译的语言，适用于线性内存堆，并且不需要动态重新编译，运行时代码加载或垃圾回收。其中一些约束是尽可能早地到达最小可行产品（这发生在February 2017），并考虑了现有的浏览器内编译器可以做的事情。
请注意，MVP不支持线程。线程将在不久之后添加。
编译用C/C++编写的解释器到WebAssembly可以很容易地支持Python，JavaScript和Ruby。更高版本的WebAssembly将支持JIT编译，但V8等引擎必须将WebAssembly作为新ISA（例如，与x86-64/ARM/...一样）。
C＃和Java需要类似的GC和堆栈操作基元。这也是路线图，但在MVP，线程和动态链接之后。
请注意，语言可能工作得很好，但支持他们的所有库也很困难！我们（浏览器工程师）可以很好地支持语言，但是我们需要社区围绕伟大的图书馆提供支持。
最后一句话：是的WebAssembly应该可以做很多事情，JavaScript可以做，因为它可以访问相同的Web API。它的目标不是为了替代JavaScript，而是为了补充JavaScript，避免为了自然地支持其他语言而向JavaScript添加特性，并为低级语言（如C++/Rust）提供可预测的接近本机性能。
为面向JavaScript或编译类似JavaScript语言的人们（例如TypeScript）保留JavaScript进化，并将WebAssembly发展成为喜欢其他语言的JavaScript酷伙伴。
最终WebAssembly将支持even more low-level features。其中一些对于JavaScript来说是没有意义的，但现有的代码（例如大型C++代码库）假定这些特性存在正确性和/或性能。
人们应该停止编写JavaScript并切换到WebAssembly吗？不，我期望与JavaScript的紧密集成意味着WebAssembly模块将从JavaScript中使用（例如，一个快速图像处理器），而现有的C++代码库将以Web为目标，但我没有看到JavaScript dying any time soon。
我觉得在这种情况下逐渐用javascript代码编写的代码会转移到更喜欢的编程语言中。
这是否意味着JavaScript最终会成为未来的语言？由于WebAssembly本意是非常普遍的（根据规范，它几乎可以在任何地方存在：https：//github.com/WebAssembly/design/blob/master/NonWeb.md），同时还可以补充JavaScript，该语言将在未来排名第一？ –
JavaScript是网络的通用语言。 WebAssembly或JavaScript成为＃1并不是真正的目标，至少不适合我。我们希望改进Web平台的功能，而不会增加JavaScript的负担，并且不必因为JavaScript的设计而损害WebAssembly。由于速度，可移植性和安全性方面的原因，我们希望此平台在浏览器外部也很有用。这些指标取得成功是IMO的重点。 –
这确实是一个很棒的方法。我非常兴奋！ –