Javascript 正在变成 Web 界的 C++

说白了就是一帮家伙只会自以为是的瞎搞。

如果 ES7 继续反人类下去的话就真的要退坑了。

完全看不懂你的逻辑。。

简单和极简主义 => php是最好的语言就是这么来的

@phoenixlzx 咋退坑？不做前端了？

java的学院派害人匪浅, 受害者包括js作者本人, ES6已经很过分了.

js只不过是把缺少的补回来而已，即使ES7加上也只不过和python差不多的特性集。极简可以但不能简陋。

JS 加个毛的 class

@archsocks 一个语言为啥要以别的语言为标准来改进

火了之后就开始过度设计了，所以啊人怕出名猪怕壮。

@jadecoder 本来也不是前端啊... 开始写 js 的时候就是 Node.js 写后端和 cli 程序的

大概会换个语言吧。Go 啊 或者是 rust 或者是其他什么的。虽然我承认 js 是目前用过的最方便的语言了

这都是企图在早期的累赘下添加更多累赘的后果

@anubiskong 相互吸收各种语言的优势嘛，这不都是为了更好的进化。苹果的swift不也吸收了python和js的优点。无可厚非。

js不需要class, 因为class需要提前把一切定好，实际上在现实需求中这是不现实，除非码农个个都是先知， js需要的是象golang那样的channel或者类似的模块之间的通信机制，只要定好数据格式，然后码农各自负责自己的模块，剩下的就不用管了，不象async把本来简单的代码写得跟天书一样

WebAssembly is essentially what Brendan Eich told us we didn’t really want or need: a bytecode format for the web. A somewhat more neutral platform for all compilers to target. As a compiler implementer, it still seems to me like it’s a bit of an unfortunate compromise: a way to retrofit a web-bytecode into Javascript VMs. It’s going to take programs encoded as Abstract Syntax Trees (ASTs) as input, whereas GCC, clang, and other real-world compilers usually generate Control Flow Graphs (CFGs) at the output stage, not ASTs. Forcing compilers to convert CFGs back into ASTs seems like a decision made to simplify the job of WebAssembly VM implementers, at the expense of everyone else.

这是看不懂就不翻了还是觉得 ourjs 的读者只需要看看吐槽就好呢？

不对，这翻译的还有问题哈哈哈：
WebAssembly 基本上就是 Brendan Eich 所说的我们不想要也不需要的东西：Web 界的字节码一个更加中性的平台，所有编辑器的目标。作为一个编译器实现者，我觉得将 Web 字节码重新塞回 JS VM 是一个愚蠢的妥协。VM 把 AST[1] 化的程序作为输入，而 GCC、Clang、和其他实用的编译器通常输出 CFG[2]，而不是 AST。强迫编译器把 CFG 转回 AST 看起来像是一个方便 WebAssembly VM 的实现者的决定，不过坑了其它所有人。

[1]: AST, Abstract Syntax Tree，抽象语法树
[2]: CFG, Control Flow Graphs

对比原翻译：
从本质上讲Brendan Eich告诉我们的WebAssembly，是希望将所有的编译器设立一个中立的编辑目标，我们真的不希望或需要为Web创建一种新的字节码格式或编译器实现，在我看来，这是一个有点不幸的妥协。


天哪，这都什么狗屁玩意，无法想象剩下的翻译里错了多少。我建议各位直接看原文好了：
http://pointersgonewild.com/2015/08/02/Javascript-is-the-c-of-the-web/?utm_source=ourjs.com

HackerNews 的讨论，比这里的讨论有意义的多：
https://news.ycombinator.com/item?id=9995788

然后我再慢慢吐槽……不过我扫了一眼（还没有细看）HN 的讨论，似乎已经把我想吐槽的说出来了。

上面那个我给的翻译里的「编辑器」是打错了，应该是「编译器」。

我有无敌技能：禁用客户端脚本

翻译的很乱

MVC 都跑前端去了，现在做后端搞搞 API 就行了，有点感觉前端在逆袭呀。

这个我很喜欢，摘抄一下：

>> Personally, I’m a big fan of simplicity and minimalism in programming language design. I think that smaller languages have the potential to be easier to implement, optimize, teach, debug and understand.

> After reading hundreds of blogs and articles about this or that programming language being supposedly "simple", sentences like the above have come to mean nothing.
> I wish a had a succinct meme to describe what actually happens in the real world around "simple" languages but the concepts are:
> If there's a "small" or "simple" FORMAL language specification, it means there's a "large" INFORMAL language out in the wild. The "informal" will include things like idioms, patterns, macros, code generators, industry practices, "utility" Javascript libraries, etc.

原文的翻译：
>> 就个人而言，我比较崇尚简单和极简主义编程。我认为，较小的语言比较容易实现、优化、学习、调试和理解。

评论的翻译：
> 阅读了数百篇关于各式各样所谓简洁的语言的博客和文章（估计指论文）之后，上述的话对我来说毫无意义。
> 很可惜我不能找一个简明的俗语来描述现实中关于简洁的故事，其概念如下：
> 如果有一个「小」或者「简单」的正式的语言规范，也就代表着还有一个很大的非正式的语言在现实中存在。所谓「非正式」包括了设计模式（Java 躺枪）、宏（C 躺枪，Lisp 躺枪）、代码生成器（Haskell 躺枪[1]），工业实践，Javascript 工具库（C++ 标准库躺枪），等等。

[1]：部分 Haskeller 表示 Template Haskell 是个不安全的扩展，不安全的扩展，能算 Haskell 吗？

我觉得这个总结的就很好了：你们是指望团队成员进行所谓学习，通过代码规范、代码审核、结对编程什么的来保证代码质量呢，还是相信微软的团队和 Anders Hejlsberg 帮你挑选完、集成在 C# 里的特性呢？至于什么 CoffeeScript，TypeScript，无非就是让一个 preprocesser 完成一个编译器本来就要完成的任务自动化测试确保代码质量而已。

不过我感觉 V2EX 主流的态度是宁可相信人的「主观能动性」，也不愿意用靠谱的语言及其编译器、相信业界的大牛，嗯，这个很有道理的。毕竟王垠曾经说过，不要迷信所谓大牛嘛！

如果用js做过多人大型项目，就会觉得添加的这些功能，是很有必要的。

@notcome

感谢指正，最后一段过于深奥，不好翻，能给个最终版不？ 我可以更新一下。

同意 @yibuyisheng
就像class，无非是一种语法糖，让你的代码更具模块性
其次，针对语言快速演化很重要，尤其现在语言竞争这么激烈，当然这也是由市场决定的，所以ES7的进程自然会加快。就好比现在C++11/14还在玩的起劲，17就已经在准备了~

我觉得这是一种心态问题...

虽说有了ES6，但各大浏览器厂商并未强制要求使用ES6。
如今ES5已经定稿6年多了，但浏览器平台有强制要求使用ES5么？
喜欢用ES3的可以一直用ES3，喜欢ES6的可以提前用ES6，这并没有强制用户使用最新版本的说法。
我觉得抱怨ES6新特性的那类朋友，你大可一直使用ES5甚至ES3没人会反对，但请不要批判一种语言向前发展趋势。

ES6是给无法满足当前需求的那类人用的，不是强制那些喜欢守旧的朋友使用的。



作为一名Web前端开发，我选择拥抱变化。

@ibloging 我汉语很差的，算了……

@amery2010 说的都很好。只不过有一点可能没有考虑到，那就是语言终究是工具，得靠不断的开发应用来提升对这门语言的掌握程度，仅仅停留在学术层次对于需要靠技术吃饭的开发者来说不现实。再通俗点讲，开发者能够开发的项目是有限的，而语言的特性提升空间是无限的，无论是实际开发做的太少，还是语言发展太迅速，最悲观的情况是，有些特性可能都没用过，或者就用过若干次，反正是没有足够多的机会来培养策略、思想、工作流，长远来看，又如何能熟练和精通这门工具？

能不能一开始就注明是转载翻译的？或者在标题里体现出来？当刚看帖子开头的时候，心想：哇，搞动态编译器的，好高端！v2ex上大牛这么多！看到末尾的译文链接的时候落差感觉好大。

精致、极简、优雅，这让我想起 Scheme 这门语言，那么纯粹干净，标准也不过几十页。
但，工程界追求的永远不在乎这些，更看重 规范、可控、健壮、功能强大，无论 Java Python Go 似乎都是以这个标准为目的构建的。另外，Github 为什么选择 Coffeescript | Angular2 为什么选择 Typescript 也是一个深思的原因。

仅看标准我觉得 ECMAScript 并不太复杂……复杂的是向后兼容

C++也还活得好好的

翻译的太水，无法看懂

es6只有一个 generator 个人感觉是值得从 vm 级来实现的. 另外就是 promise 这东西好是好,但是目前实现很多, 原生版的功能太单薄. 其他特性大部分都可以通过 coffee 之类的方式来实现, 没必要集成进去.

JS 从 ES6 的确感觉开始出现了过度设计的萌芽了，比如说莫名其妙的 Map Set 非要取代 {} 与 [] 而不是在原来的基础上改进，所以多了很多冗余的语法，背离了 JS 语言精粹中的精神…… 奇怪的取代 var 的 const 和几乎用不到的 let …… Class 与 extends。还有一些比较冷门的特性比如说解构赋值什么的，实在是让人不能理解。

我就觉得es6很好，把残缺的地方补上去了。python 3.5不也类似么

@plqws 学过java和python很容易理解吧

@plqws 哈哈， destructuring 是我最喜欢编程语言的特性之一

很多特性会彻底改变写js 的方式吧，像generator，像 es7的 await， proxy 可以用来实现更漂亮的api，唯一不满意的是没有变成coffeescript

@duhastmich 赞 唯一不满意的是没有变成 coffeescirpt...

es6又没有把你们喜欢的功能去掉吧~~~ ，多了个class多好，喜欢用class的用class 不喜欢用的不用不久好了，，微软的typescript的很好啊

正因为Coffeescript潜在地形成了分裂JS社区的威胁，学院派的人说：你们别弄了，ES6都会有的...
@duhastmich @zhpooer

@amery2010 言的化永是制的。ES5 出了，如果你不理解 ES5 的法，你就法理解 ES5 代的程序；同即便痛恨 ES6 的法，懂人的程序仍要被迫 ES6 的法。

言是有的。

除非分裂。

WebAssembly。。。总算有机会真正不用JS了。。。

如果尝试用 ES6/7 写一点东西，就会知道 ES6/7 有多好了。
let/const只是本来就应该有的块作用域，残念的只是为了要向下兼容没办法和Swift一样用var/let；
Arrow function拯救了var that = this的地狱；
class只不过是给原本的原型继承提供一种语法糖；
async/await、generators把代码变得更漂亮了；
Promise是业界普遍使用多年的东西，放到Javascript引擎里并没有不妥...

楼主用的百度翻译吗？

诚心默念大法好，Js大法保平安

喂, ES8 什么时候出来呀?