如果python代替javascript_如果 Python 代替 JavaScript 成为浏览器前端编程语言，这个世界会更美好吗？...

不会，答案是肯定的。

以这世上任何脚本语言，如果从9x年开始成为浏览器标配脚本语言，到今天为止，不管是别的任何语言都不可能比JS表现的更好。这里的关键是，主基调流行的JS规范或者主流类库(不是指JS本身规范，而是实现厂商)，经历了好几波的更替，是必然的结果，这里说的不是JS开源类库，而是指浏览器厂商，JS初期，IE6、7年代，火狐兼容年代，IE和Chrome共占市场时间，到今天的Chrome主流。市场份额决定了他的主要用法。特别是过去没有nodejs环境前提下。今天是v8一统江山了，所以按理来说，也算是JS进化和发展最好的阶段。

每个脚本语言，使用到最后，都存在那个问题，动态类型判断的问题。python不是我的主力开发语言，但如PHP，对于高阶开发者，大概30-40%工作量是判定类型，或者是检查不为空，isset，类型安全，虽然PHP7提供了类型指定，但这些判断还是很多，非常无趣。即使如，C#和Java大量的需要判定不为null。

曾经我认为就此一度不再进化的JS(就是在IE和Chrome共占市场时期)，coffeescript是最好的优化方案，就如Kotlin，他立足于良性优化，提供更可读的代码，解决一些核心的痛点，却不是更彻底性的解决(一如coffeescript之于typescript，kotlin之于scala)。

然后的然后，我始终不明白，typescript为什么不提供一个runtime lib，早期还有，中后期直接弃了，所以我曾经还自己撸了一个runtime，实现机理也很简单。官方也许是考虑到转译成JS的规范发展的不确定性，所以直接弃了runtime lib。但今天ES规范正朝着奇葩的道路在发展，typescript的确是目前最佳的替代选择方案。

JS原型链，首先就你第一段的代码，其实以前是不推荐在function里面去写prototype，主要是JS的运行时机的问题。真正做的最好，是当年Mootools里面实现的伪造Class，以前大量基于他的Class构造类，应用开发，需要的是这种机制，而不是原型链。

原型链，这个几乎以前每天都要面对的东西。那年头算是JS唯一的救命稻草，写的头皮发麻，无趣得很。对于今天的人可能不知道，原型链写法还会有性能区别。算了，这些今天 who cares 呢？

所以我很反对到今天还去写原型链，交给babel去实现吧，专注用新的es语法，你需要面对的是未来不是过去。不过作为JS开发者，特别直接用nodejs开发服务的，原型链还是要懂。这就让人很尴尬。

然后的然后，scala.js，kotlin to js等等，还有webassembly，再等等吧，我预估未来的发展是，大家会将JS作为一种汇编的存在，谁也不会直接去写他，都是用各自熟悉的语言开发，然后最终build for js版本(基于现在JS转译的环境实在是太成熟了，仅babel的性能是以前的几倍之上)。所以也不需要对ES的各种奇葩新规感到奇怪，他不是给你准备的，而是考虑更广阔的未来。

所以，谁都不可能在未来取代JS，他也不需要成为你最喜欢的语言，不会有哪个语言比他更适合前端环境。起码，就受气包这一点，JS没有豪门背景，没有这方面的思想包袱。