阅读更多

12顶
19踩

编程语言

原创新闻 JavaScript 的替代品

2012-12-11 17:06 by 副主编 wangguo 评论(87) 有42968人浏览
JavaScript几乎无处不在,HTML5的出现,使得JavaScript达到了前所未有的高度。如今,JavaScript已经开始向移动应用开发领域渗透,成为开发跨平台应用不可或缺的语言。

如果你不会JavaScript,或者你对JavaScript的语法不满意,这一点都不影响你的web应用的开发工作,相反,你可以使用其他语言来代替JavaScript。尽管目前的浏览器尚不支持这些语言,但你可以将它们编译成为JavaScript代码。

比如,如果你更喜欢经典的面向对象方式,并想要一些语法糖,那么你可以试试CoffeeScript;如果你希望有一个更严格的类型系统,那么你可能会发现Dart或TypeScript更有趣一些;如果你更喜欢函数式编程,那么ClojureScript或Roy可以帮助你。

下面就是一些JavaScript的替代方案。这些语言之所以能够成为JavaScript潜在的替代品(实际上还无法替代),说明它们足够优秀,而它们优秀的原因,正是因为它们“站在JavaScript的肩膀上”。

1.  CoffeeScript官方网站 / GitHub

CoffeeScript是一个使用纯Ruby编写的编程语言,创建者Jeremy Ashkenas戏称它是“JavaScript的不那么铺张卖弄的小兄弟”。优势如下:

  • CoffeeScript只使用了JavaScript的“精髓”,抛弃了原来JavaScript晦涩、容易出问题的那部分东西,如全局变量声明、with等。
  • CoffeeScript提供了很多语法糖,让代码更优雅可读。
  • CoffeeScript还提供了一个机会,让你现在就可以使用ECMAScript的新特性。


2.  Dart官方网站

Dart是谷歌推出的一种基于类的可选类型化编程语言,主要用于创建Web应用程序。谷歌称,Dart的设计目标是为Web编程创造结构化但又富有灵活性的语言;编程方法一目了然,符合程序员的自然习惯,易于学习;能在所有浏览器和不同环境中实现高性能。

Dart代码以两种方式执行,一种是原生虚拟机,一种是JavaScript引擎,用编译器将Dart代码翻译成 JavaScript代码。这允许程序员在Dart中创建Web应用,编译后在任何浏览器上运行。



3.  TypeScript官方网站

TypeScript是微软开发的开源编程语言,它是JavaScript的一个超集,而且本质上向这个语言添加了可选的静态类型和基于类的面向对象编程。TypeScript扩展了JavaScript的句法,所以任何现有的JavaScript程序可以不加改变的在TypeScript下工作。TypeScript是为大型应用之开发而设计,而编译时它产生 JavaScript 以确保兼容性。



4.  ClojureScriptGitHub

ClojureScript是由Clojure的创建者Rich Hickey推出的,目标是“做Javascript所能做到的事情”。它是LISP 和 Java 技术结合的产物,兼具函数编程和Java平台的优势,聚焦于低错和易用的并发编程,同时足以完成一个通用编程语言的各种任务。你可以通过ClojureScript使用Clojure语言编写代码,然后将其编译为Javascript。

5.  Opal官方网站 / GitHub

一个可将Ruby代码转换为JavaScript的编译器。



6.  IcedCoffeeScript官方网站 / GitHub

这是Coffeescript语言的扩展集。iced解析器是标准coffee解释器的非正式替代方案,因为它能解释所有现存的Coffeescript程序。它添加了2个关键字:await 和 defer,为浏览器和服务器两者提供了强大的异步控制功能。



7.  LiveScript官方网站 / GitHub

LiveScript是Coco的一个分支,是CoffeeScript的间接子集,并在面向对象和命令式编程方面进行了诸多改进。其代码可以编译成JavaScript。



8.  Kaffeine官方网站 / GitHub

Kaffeine是JavaScript语法的扩展,与JavaScript非常类似,代码可以直接编译成JavaScript。



9.  Roy官方网站 / GitHub

Roy是一个以JavaScript为目标的试验性的编程语言,试图融合JavaScript语义和静态函数语言的一些特点,如Damas-Hindley-Milner类型接口、缩进语法、编译时元编程、模式匹配、Monad语法等。



Via Jster
  • 大小: 52.1 KB
  • 大小: 33 KB
  • 大小: 40.5 KB
  • 大小: 39.3 KB
  • 大小: 54.6 KB
  • 大小: 59.7 KB
  • 大小: 33.6 KB
  • 大小: 31.3 KB
12
19
评论 共 87 条 请登录后发表评论
87 楼 lovecruel 2019-08-20 12:17
虽然我只是一个菜鸟js,主要做后端开发的.但是也不得不说一点.javascript确实要很多要改进的地方.这是不争的事实.不接受反驳.前面也有人提到了,由于历史原因,还有垄断地位,所以一直到现在还是这破样子.
不要跟我讲什么因为你不了解js,你还没学精等等理由.
说点实际的,一门语言都是为人服务的.编程语言就是为开发服务的,使用一门语言需要看其成本的,写代码的时间,调试代码的时间,查找bug的时间等,还有旧代码的维护扩展等方面来看.js相比其他语言而言,成本比较大.就算是用上面几种替代方案,也是不可能完全替代的.调试,查历史bug或新人熟悉旧系统的数据流向,执行过程等等都是需要看之前的js代码的.这个时间成本是比较高的.除非是招一个对js比较精通的人.水平一般的开发,可能主要是做后端开发的,花费的时间是比较昂贵的.
简而言之,垄断地位可以决定这门语言一直很红.但是无改进动力,守旧懒散的发展方式决定了效益发展慢,没有性价比.
86 楼 cyheye 2013-01-17 10:58
了解下,学习下~~~~~~~
85 楼 yy77 2013-01-10 11:27
coffeescript不是用javascript(node.js)写的么?
84 楼 kidneyball 2013-01-09 12:09
kanme818 写道
kidneyball 写道
kanme818 写道
我勒个去,这帖子还有人在回复?老盯着语言问题搞来搞去有毛意思


重启服务器一次要3分钟呀,码码字挺好的

人才了,3分钟能码那么多字。。。


一小时至少重启五次……还是用了JRebel之后……
83 楼 kanme818 2013-01-09 11:59
kidneyball 写道
kanme818 写道
我勒个去,这帖子还有人在回复?老盯着语言问题搞来搞去有毛意思


重启服务器一次要3分钟呀,码码字挺好的

人才了,3分钟能码那么多字。。。
82 楼 kidneyball 2013-01-09 11:36
kanme818 写道
我勒个去,这帖子还有人在回复?老盯着语言问题搞来搞去有毛意思


重启服务器一次要3分钟呀,码码字挺好的
81 楼 kidneyball 2013-01-09 11:22
danny.chiu 写道

呵呵!

本来用手机打了好多字,突然safari崩溃了。。我也崩溃了。。

我个回复都提到了,js是有缺陷的,朋友不能视而不见嘛。js不完美,但也不是垃圾,除非对它不了解,你不能偷换概念啊,“谁说这个语言不好用,谁就是低手”。能和资深的前辈聊天,是件幸事,我经常从你们那学到很多理念。

但我还是觉得您先入为主了。所谓先入为主和时间并无直接的关系,而是看你先掌握、熟悉哪门语言。java和javascript是雷锋和雷锋峰的关系,不能拿来对比的。说到“==”和“===”,和其他语言的“:=”之类,这只是一个语法特例而已:“==”两边如果类型不同,会强制转换再比较,es5里面已经有很详细的说明了;“===”不会做类型转换。这作为js的一个语法现象,再正常不过了,每个语言都有自己的特点。js很简单,键值对、原型链。[]==[]是false,是因为这是两个不同的引用,如果觉得别扭,那就是先入为主了,用js的思维来思考,才能用好js。没有哪个统一的语言规范规定了,[]==[]要返回true。

我没有谈论js语言规范的优缺点,因为我改变不了任何东西,当然这不是重点,术业有专攻,我方向不在这。您的小偷的例子很生动,可是牵强了一点,站在jser的角度,这例子也可以说给你们听。jser并非都是敝帚自珍之流,至少我是很乐于看到前端竞争起来的。但这不能说明js不行,我很看好现在的js,以及它的发展趋势,因为html5。

至于它的历史决定了它一定不是完美的,见仁见智吧,还没见过哪种敢号称完美的语言。人都有优缺点,关键是看如何使用。es4之所以失败,是因为它没有群众基础。反对者代表之一,就是之前提到过的《javascript语言精粹》的作者,这两阵容细说起来就长了。

“谁能适应其中古怪的地方,谁就是高手”呵呵,这是玩笑话吧。只会语言,没有丰富编程思想的人,说到哪都是普通的码农。


首先先主动承认错误,这些隐含转换关系我还不到信手拈来的地步,实际使用中我也是主要使用===。之前发帖是用上班时重启服务器的空档来写的,简单用node.js测试了一下。今天再用浏览器测试了一下,在浏览器中{}是完全不能与==结合的,而且[]==[]是false,不是我之前说的true。因此我举这个例没有什么说服力了,可以跳过。

其次指出这位朋友之前帖子的一个疑似错误,[]与其他类型结合运算,并不是被隐含转型为Number 0, 而是空字符串。可以参考 []+0 的结果。

再强调一下,我觉得和你在对JS的看法上其实没有本质分歧,而是在各说各话。我从来不认为JS整体是垃圾(没有任何一个能流行起来,经过市场检验的语言是垃圾。就算不能流行起来,出于对作者劳动和智慧的尊重,我也不会认为任何一个语言是垃圾),我只是觉得JS中有一些语言特性应该改进。而JS缺乏外在的改进动力,所以我觉得应该鼓励竞争者。所以,只要你认同js中仍有缺陷,值得改进,对我来说就足够了。至于举出来的例子你是否觉得是重大缺陷,在我看来并不重要。

我举那个例子,并不是想影射JS本身,门被撬在正常思维中是一个明显负面的事情,而JS中是否存在这种程度的负面特性我们未有共识,因此完全没有可类比性。我做这个类比,是想说明如果将这种思路用在考虑“一个东西是否需要改进”上,我可以用它证明任何东西都不需要改进。当然你也说了,你根本不曾去考虑改进语言的问题,这也就解释了我的疑惑。以目前的情况来看,JS语言不会进入对语言特性上的细节作出调整的高速发展阶段,关于这点我们的看法是一致的。分别在于,在这个帖子里,我的着眼点是能否通过改变外部环境,引入竞争来加速这种发展速度,而你的着眼点在于这些语言特性技术上的运作原理。

我前面提到ES4的例子,只是一个小插曲,真正要说的是js被匆匆创建后,经过短暂的不系统的发展,从ES3定稿后,10年来就一直没变过了。而目前的ES5,并不是一个“比ES3跨了两代”的版本,而是原本的ES3.5。我只是要以此说明,如果有人认为JS完全没有问题,那就是说一个10年前被一个年轻人在与老板意见不统一的前提下用10天时间弄出来的语言刚好没有任何问题,这在常识上就是说不通的。既然你也认为JS确实有其缺陷,那这整段话你都可以跳过。至于ES4究竟为什么被否决,不是重点。
80 楼 kanme818 2013-01-09 09:41
我勒个去,这帖子还有人在回复?老盯着语言问题搞来搞去有毛意思
79 楼 danny.chiu 2013-01-09 09:30
kidneyball 写道
danny.chiu 写道
所谓码农 写道

我认为,人类的直觉是因为你的认知惯性,为什么你可以接受C语法系里面的赋值运算符=作为SQL和其他一些语言里面等值判断,而不能接受===操作符?要说直观,难道“==”比“=”更直观吗? 还有,“{}==!{}”这是什么操作符能解释一下吗???
关于第二点代码量敏感,未免太搞笑了,你以为你生活在90年代?我就不相信了,就算你多写一万个function,用gzip压缩一下大小会相差100字节?

认知惯性!精辟!

他举的例子是空数组和空数组比较,空对象和空对象比较,他以为结果不科学。
其实这种细节基本不会影响到多少,非要扣的话,咱们也可以分析下:
1.首先引用之间比较:[]==[],{}=={}。这肯定是不同对象的引用,所以为false;
2.[]==![]:![]是false,是个 Boolean,根据 ES5 的规定,一方是 Boolean,则将另一方转化成 Number 之后,再比较。Number([])结果是0,0==false,返回true;
3.{}==!{}:这应该是写法上的示意,在控制台输入会报错,是因为在assign operation context中的时候{}并不被解析为new Object,而是定一个scope。实际意思应该是
var a = {}, b = {};
a == !b; // false
// 或者写成这样:
({})==!({})

这和第二点类似,Number({})结果为 NaN,凡是一边是 NaN 的时候,比较结果是 false。

这位朋友估计是先入为主了~


另外,从语言特性上我看是说不通了。那换个角度从历史上看看吧。
先转篇老文: http://www.ruanyifeng.com/blog/2011/06/birth_of_javascript.html

JavaScript,1995年被一个34岁的青壮年用10天时间创造出来,老板要他仿Java语法,但他自己却不喜欢Java。创立时唯一的理念,就是“简单”——实现起来简单。然后经过浏览器高速发展,而JS自身无比混乱的四年(那时JavaScript在程序员心中的地位比起Excel的VBA还有所不及),1999年12月ECMAScript 3规范发布。然后整整10年,由于种种原因,JavaScript语言规范没有重大变动。期间试图搞过ECMAScript 4,结果完全失败,胎死腹中。最后由同期并行运作一起搞的ECMAScript 3.5挑起大旗,直接改名为ECMAScript 5,到2009年正式发布。2011年发布ECMAScript 5.1。目前ECMAScript 6正在起草。

这样的背景下,JavaScript刚好是一种完美语言的几率是几近为零。十年来,jser的心态就是“反正这个语言本身是改不动了,而且除了它也没得选。谁能适应其中古怪的地方,谁就是高手”。到最后,就变成了“谁说这个语言不好用,谁就是低手”。


呵呵!

本来用手机打了好多字,突然safari崩溃了。。我也崩溃了。。

我个回复都提到了,js是有缺陷的,朋友不能视而不见嘛。js不完美,但也不是垃圾,除非对它不了解,你不能偷换概念啊,“谁说这个语言不好用,谁就是低手”。能和资深的前辈聊天,是件幸事,我经常从你们那学到很多理念。

但我还是觉得您先入为主了。所谓先入为主和时间并无直接的关系,而是看你先掌握、熟悉哪门语言。java和javascript是雷锋和雷锋峰的关系,不能拿来对比的。说到“==”和“===”,和其他语言的“:=”之类,这只是一个语法特例而已:“==”两边如果类型不同,会强制转换再比较,es5里面已经有很详细的说明了;“===”不会做类型转换。这作为js的一个语法现象,再正常不过了,每个语言都有自己的特点。js很简单,键值对、原型链。[]==[]是false,是因为这是两个不同的引用,如果觉得别扭,那就是先入为主了,用js的思维来思考,才能用好js。没有哪个统一的语言规范规定了,[]==[]要返回true。

我没有谈论js语言规范的优缺点,因为我改变不了任何东西,当然这不是重点,术业有专攻,我方向不在这。您的小偷的例子很生动,可是牵强了一点,站在jser的角度,这例子也可以说给你们听。jser并非都是敝帚自珍之流,至少我是很乐于看到前端竞争起来的。但这不能说明js不行,我很看好现在的js,以及它的发展趋势,因为html5。

至于它的历史决定了它一定不是完美的,见仁见智吧,还没见过哪种敢号称完美的语言。人都有优缺点,关键是看如何使用。es4之所以失败,是因为它没有群众基础。反对者代表之一,就是之前提到过的《javascript语言精粹》的作者,这两阵容细说起来就长了。

“谁能适应其中古怪的地方,谁就是高手”呵呵,这是玩笑话吧。只会语言,没有丰富编程思想的人,说到哪都是普通的码农。
78 楼 kidneyball 2013-01-08 22:54
danny.chiu 写道
所谓码农 写道

我认为,人类的直觉是因为你的认知惯性,为什么你可以接受C语法系里面的赋值运算符=作为SQL和其他一些语言里面等值判断,而不能接受===操作符?要说直观,难道“==”比“=”更直观吗? 还有,“{}==!{}”这是什么操作符能解释一下吗???
关于第二点代码量敏感,未免太搞笑了,你以为你生活在90年代?我就不相信了,就算你多写一万个function,用gzip压缩一下大小会相差100字节?

认知惯性!精辟!

他举的例子是空数组和空数组比较,空对象和空对象比较,他以为结果不科学。
其实这种细节基本不会影响到多少,非要扣的话,咱们也可以分析下:
1.首先引用之间比较:[]==[],{}=={}。这肯定是不同对象的引用,所以为false;
2.[]==![]:![]是false,是个 Boolean,根据 ES5 的规定,一方是 Boolean,则将另一方转化成 Number 之后,再比较。Number([])结果是0,0==false,返回true;
3.{}==!{}:这应该是写法上的示意,在控制台输入会报错,是因为在assign operation context中的时候{}并不被解析为new Object,而是定一个scope。实际意思应该是
var a = {}, b = {};
a == !b; // false
// 或者写成这样:
({})==!({})

这和第二点类似,Number({})结果为 NaN,凡是一边是 NaN 的时候,比较结果是 false。

这位朋友估计是先入为主了~


另外,从语言特性上我看是说不通了。那换个角度从历史上看看吧。
先转篇老文: http://www.ruanyifeng.com/blog/2011/06/birth_of_javascript.html

JavaScript,1995年被一个34岁的青壮年用10天时间创造出来,老板要他仿Java语法,但他自己却不喜欢Java。创立时唯一的理念,就是“简单”——实现起来简单。然后经过浏览器高速发展,而JS自身无比混乱的四年(那时JavaScript在程序员心中的地位比起Excel的VBA还有所不及),1999年12月ECMAScript 3规范发布。然后整整10年,由于种种原因,JavaScript语言规范没有重大变动。期间试图搞过ECMAScript 4,结果完全失败,胎死腹中。最后由同期并行运作一起搞的ECMAScript 3.5挑起大旗,直接改名为ECMAScript 5,到2009年正式发布。2011年发布ECMAScript 5.1。目前ECMAScript 6正在起草。

这样的背景下,JavaScript刚好是一种完美语言的几率是几近为零。十年来,jser的心态就是“反正这个语言本身是改不动了,而且除了它也没得选。谁能适应其中古怪的地方,谁就是高手”。到最后,就变成了“谁说这个语言不好用,谁就是低手”。
77 楼 kidneyball 2013-01-08 21:30
danny.chiu 写道
所谓码农 写道

我认为,人类的直觉是因为你的认知惯性,为什么你可以接受C语法系里面的赋值运算符=作为SQL和其他一些语言里面等值判断,而不能接受===操作符?要说直观,难道“==”比“=”更直观吗? 还有,“{}==!{}”这是什么操作符能解释一下吗???
关于第二点代码量敏感,未免太搞笑了,你以为你生活在90年代?我就不相信了,就算你多写一万个function,用gzip压缩一下大小会相差100字节?

认知惯性!精辟!

他举的例子是空数组和空数组比较,空对象和空对象比较,他以为结果不科学。
其实这种细节基本不会影响到多少,非要扣的话,咱们也可以分析下:
1.首先引用之间比较:[]==[],{}=={}。这肯定是不同对象的引用,所以为false;
2.[]==![]:![]是false,是个 Boolean,根据 ES5 的规定,一方是 Boolean,则将另一方转化成 Number 之后,再比较。Number([])结果是0,0==false,返回true;
3.{}==!{}:这应该是写法上的示意,在控制台输入会报错,是因为在assign operation context中的时候{}并不被解析为new Object,而是定一个scope。实际意思应该是
var a = {}, b = {};
a == !b; // false
// 或者写成这样:
({})==!({})

这和第二点类似,Number({})结果为 NaN,凡是一边是 NaN 的时候,比较结果是 false。

这位朋友估计是先入为主了~


其实我和你没有本质上的分歧,而且说的不是同一样东西。这个帖子本来说的是9种其他语言,我是在列举一些JS规范中我认为可以改进的地方,去论证这些新型语言有其价值。而你则是在论证我列出来的这些语言特性都是可以从JS规范或者具体实现上推演出来的。感觉按你目前这种思路,世上真是没有东西是需要改动的。就好比家里的门锁被撬了,我的第一反应是:这门锁要改善或者换锁,因为门的作用是防止没有钥匙的人进来。而你的第一反应是:嗯,这里门缝很大,信用卡可以插进来,锁闩是月牙形的,所以这个锁能被信用卡顶开,是很合理的。

我在谈论一个语言规范的优缺点,自然会和其他语言比较。这“先入为主”的结论似乎有些武断。我01年开始接触JavaScript,使用至今(非专职前端,还主要还是做Java后端,偏向业务系统),05年开始学习Python,08年才开始学习Ruby,07到11年一直在使用Ext,去年到现在一直在用JQuery+Prototype。要先入为主也是JavaScript为主吧。

76 楼 kidneyball 2013-01-08 19:50
danny.chiu 写道
kidneyball 写道

这位朋友的“觉得XX垃圾的,基本上是XX菜鸟”观点可以跟一楼的朋友强调一下。他带头说9种语言二,自然会引来说js二的人。不知道他有什么好气愤的。

我个人的观点是,js不是垃圾语言,是种中规中矩的应用脚本语言。功能上能满足需求,但语言特性说不上完美,有很多可以提高改进的地方。但由于历史原因,它独占着前端开发领域,由于缺少对手,根本就没有改进的动力。所以我个人倾向于希望在浏览器开发领域有更多的选择,竞争。

楼主列的几点回应,还是跳不出“这就是语言特性,我就是这样”的框框。我们当然知道这是语言特性,但语言特性也分好坏,好的语言特性符合人类直觉,简单明了,容易理解和维护。我们不是问“为什么在js里会这样”,而是在思考“为什么js语言规范要选择这样做,有没有更好的方法,为什么它没有引入更好的方法”。

类似的例子还能举一大堆,例如:

1. []==[]是true,[]==![]也是true,但{}=={}是false,{}==!{}也是false。作为勉强入门的jser,我确实知道[]在参与==运算时被隐含转型为""(空字符串),但在与!结合时又被看成true。所以[]==![]等价于 ""==false ,而空字符串在参与==运算时被看成false。而{}在参与==运算时不做转型,两个{}字面量属于不同对象。

问题是,一种语言的语言特性经过种种组合,最终得出了如此不符合人类直觉的现象,你觉得这是一种好特性吗?

其他语言对此的处理是:
Ruby:[]==[]为true,[]==![]为假,{}=={}为true,{}==!{}为false
Python:[]==[]为True,[]==![]报错([]没有定义!操作),{}=={}为True,{}==!{}报错

我认为这两种语言的做法都相对更符合人类思维。

2. JS的主要应用场景是在网络上传输,代码中每个字符都是对应着流量。在不影响理解和功能的前提下,自然是代码量越少越好。闭包是Js中一种很常用的语言特性,而事实上Js的匿名函数(Lambda表达式)定义却是诸多支持Lambda的语言中最冗长的。Ruby里写array.map {|x| x+1},Js中却要写array.map(function(x){return x;})。在不影响向前兼容的前提下,加入一种简单的Lambda语法糖在技术上根本没有难度,连Java这种出了名的老乌龟被C#逼急了也要引入更为简洁的Lambda。而Js从一开始就支持闭包,本身应用场景又对代码量敏感,却这么多年都没有改动。背后的原因,我看来根本就是因为没有竞争,所以没有动力。毕竟有很多更重要的特性都还没有那份闲情逸致加进去。


谢谢你的回复!

我觉得可能有点误解,但基本观点是一致的。对的,不要轻易的说什么东西不行,往往是对它缺乏了解,这是个浮躁的社会。就跟周易一样,如果你看到她的第一反应就是迷信,我觉得就过了,假的东西能存在五千年吗?科学只能解释它能解释的东西。后来学习了一点点《奇门遁甲》,它的象数理模型,及宇宙全息、天人合一等理论,很是经典。希望不要扯远了,如果有人不信,建议去花1-2k大洋,找个名家测测,不否认有很多摆摊骗人的。

朋友很谦虚,呵呵。我也说到了“js确有糟粕,毕竟它的设计非常仓促,有些陷阱,要不为啥 Douglas Crockford 的书名字叫《The Good Parts of JavaScript》”。和你不同的是,我的理解角度:我没有问为什么js语言规范选择这样做,有没有更好的方法,为什么它没有引入更好的方法;我是你说的反面教材,我只问了为什么在js里会这样。毕竟我改变不了它,不如以它为工具,用它来思考。了解js的走势,能用它做出好的产品、游戏引擎,这是我对自己的定位。每人侧重都有不同,我不觉得有高下之分。因此在我的角度来说,第一点js没有不符合人类直觉,为什么在js里会这样你也说明白了。至于另外两种我没觉得有多高明的地方,没有任何一种规范说哪种是标准的,所以我觉得这三种都很和谐,这只是语言特性而已!就好像有人大赞 CoffeeScript 优美一样,类似Ruby/Python等类Lisp语法,这是多么的优美!

网络传输方面,代码其实很小,合并压缩一下(甚至可以压缩变量名),也就一张图片的大小。所以就有很多有用的库来让工作变得更人性化。js不是支持匿名函数中写法最长的,as要长一些,因为还要指定返回值类型,但这一点不妨碍它红的发紫。朋友这样说有点吹毛求疵了,回想几年前从java转过来,感觉很顺畅,倒是做Rails项目时,反而很别扭了,各种缩进反而让我觉得混乱,这当然是和咱们的积累有关系,萝卜白菜各有所爱,你可能会喜欢 CoffeeScript。

js缺乏竞争,缺少动力,这是不争的事实!可喜的是,随着 html5 的来临,各种重要的特性都在完善中。


所谓码农 写道
kidneyball 写道
danny.chiu 写道

我也凑凑热闹,发表下观点,不针对任何人。
觉得javascript垃圾的,基本上是js菜鸟:这是我的观点。下面回答下上面引用的问题:
1. js是大众语言,不是高富帅。命名空间、模块、类和继承等,不是原生支持的,人们喜欢它,是因为它足够灵活。“js库一大部分是在弥补语言缺陷”,不知从何得来,js确有糟粕,在<<javascript语言精粹>>里面讲的很清楚了,觉得缺陷太多,往往是对它不够了解。
2. “==”比较的话,会进行强制类型转换,“===”会比较类型,弱类型语言,这是js的基础。
3. 这只是js的实现方式,也不是只有js这么实现的。如果你学过js的话(我的意思是把它当成一门语言),就知道,这是在用不同的引用在比较,结果肯定是不同的。如果要比较复杂对象,可以先 .toString() 再比较,或者用 JSON 序列化之后再比,你说的也是一个常用的办法。
4. 这可能就是先入为主的原因了吧。如果最先接触的是基于原型继承的语言,就会觉得这很自然,而且还节省内存。不够了解、没深入学习就会觉得,这继承机制够乱的。
5. 还是个非常基础的问题,js只有函数级作用域,没有块级作用域,没啥好说的。
6. 这结果显然是 0,很符合jser思考的习惯。如果你系统学过js,就知道js有个类似“预编译”过程,这里会把变量声明、函数声明提到前面,确定作用域链,然后逐行执行等细节。
7. 还是个js常识问题,如果结尾不加“;”,js解析时会自动帮你加上。但如果压缩、合并的话,就会出问题,因为没有“;”,就合成一长段了。但如果都按规范写,就不会出问题。function前加“;”是个很好的编程习惯,如果你觉得非常别扭,说明你还没有进入js世界。

顺便发个案例,我做的两个js游戏,有兴趣可以交流下:
1. 2年前练手拙作,坦克大战
2. h5wan平台上的打飞机游戏,还未发布,内测中。


这位朋友的“觉得XX垃圾的,基本上是XX菜鸟”观点可以跟一楼的朋友强调一下。他带头说9种语言二,自然会引来说js二的人。不知道他有什么好气愤的。

我个人的观点是,js不是垃圾语言,是种中规中矩的应用脚本语言。功能上能满足需求,但语言特性说不上完美,有很多可以提高改进的地方。但由于历史原因,它独占着前端开发领域,由于缺少对手,根本就没有改进的动力。所以我个人倾向于希望在浏览器开发领域有更多的选择,竞争。

楼主列的几点回应,还是跳不出“这就是语言特性,我就是这样”的框框。我们当然知道这是语言特性,但语言特性也分好坏,好的语言特性符合人类直觉,简单明了,容易理解和维护。我们不是问“为什么在js里会这样”,而是在思考“为什么js语言规范要选择这样做,有没有更好的方法,为什么它没有引入更好的方法”。

类似的例子还能举一大堆,例如:

1. []==[]是true,[]==![]也是true,但{}=={}是false,{}==!{}也是false。作为勉强入门的jser,我确实知道[]在参与==运算时被隐含转型为""(空字符串),但在与!结合时又被看成true。所以[]==![]等价于 ""==false ,而空字符串在参与==运算时被看成false。而{}在参与==运算时不做转型,两个{}字面量属于不同对象。

问题是,一种语言的语言特性经过种种组合,最终得出了如此不符合人类直觉的现象,你觉得这是一种好特性吗?

其他语言对此的处理是:
Ruby:[]==[]为true,[]==![]为假,{}=={}为true,{}==!{}为false
Python:[]==[]为True,[]==![]报错([]没有定义!操作),{}=={}为True,{}==!{}报错

我认为这两种语言的做法都相对更符合人类思维。

2. JS的主要应用场景是在网络上传输,代码中每个字符都是对应着流量。在不影响理解和功能的前提下,自然是代码量越少越好。闭包是Js中一种很常用的语言特性,而事实上Js的匿名函数(Lambda表达式)定义却是诸多支持Lambda的语言中最冗长的。Ruby里写array.map {|x| x+1},Js中却要写array.map(function(x){return x;})。在不影响向前兼容的前提下,加入一种简单的Lambda语法糖在技术上根本没有难度,连Java这种出了名的老乌龟被C#逼急了也要引入更为简洁的Lambda。而Js从一开始就支持闭包,本身应用场景又对代码量敏感,却这么多年都没有改动。背后的原因,我看来根本就是因为没有竞争,所以没有动力。毕竟有很多更重要的特性都还没有那份闲情逸致加进去。

我认为,人类的直觉是因为你的认知惯性,为什么你可以接受C语法系里面的赋值运算符=作为SQL和其他一些语言里面等值判断,而不能接受===操作符?要说直观,难道“==”比“=”更直观吗? 还有,“{}==!{}”这是什么操作符能解释一下吗???
关于第二点代码量敏感,未免太搞笑了,你以为你生活在90年代?我就不相信了,就算你多写一万个function,用gzip压缩一下大小会相差100字节?


人类直觉是认知惯性没错,但不代表一个语言随意破坏这种认知惯性就是好事,你要破坏,总该有拿得出台面的原因吧。赋值表达式和相等比较在认知惯性中都可以用=号来表示,既然冲突了,那要么根本不提供赋值表达式(例如Basic,只有赋值语句,没有赋值表达式),要么其中一个妥协。像delphi那样选择用:=来做赋值,保留相等比较是=;C和java选择用==来比较,保留赋值用=。都可以,但至少人家拿得出个说法。

就算你拿不出什么说法,至少好的语言特性应该能举一反三,符合推理吧。但现在我告诉你,在某种语言里,==是一个判断等值的符号,!是逻辑取反符号,一般情况下 a==a时,a == !a为假。不过,又存在特例,当a是空数组时,a == a 为假,a == !a 也为假,你自己小心吧。在这种语言里,空数组如果单独跟==一起用,最终将作为false来处理,但同一个空数组跟!一起用,则作为true来处理。两个空数组用==判断,视为true,而两个空对象用==判断,又视为false。

好吧,作为js高手,你推荐我总是用===。既然这样,这个语言弄出个==来干什么。既然===是推荐用法,为什么推荐用法反而要我多按一个键。这个语言号称“JavaScript”,本来就是借鉴Java的基础语法,为什么与Java一致的==不是推荐用法?

更何况,这里只是举个例,类似的“特殊情况”在js里到处都是。所有能正常发展的语言,都在调整自身提高统一性。只有js,语言本身因为各种原因发展缓慢,而社区则不断告诉你:这个语言就是这样,能否避开这些特例,就是高手和低手的区别。

至于代码量敏感,首先你说的90年代还真说对了,这种冗长的function语法在1999发布的SCMAScript 3规范里就是这样了。另外引入语法糖减少代码量,提高开发效率,所有脚本语言都在争先恐后地做。网络环境下代码量敏感只是在js的特定应用场景中,一个额外的好处。按道理js比其他脚本语言更有理由加入更简洁的Lambda形式。可惜js反正就算不做,也动摇不了它的垄断地位,根本就没有动力搞。

另外我码这么多字,都是举例,其实只是想说一件事:“现在JS还有改进空间,但进步动力不足,应该鼓励引入竞争。对前端开发,以及Js本身都是好事”。你是不是想论证现在的Js已经完美到多一分有余,少一分不足了?
75 楼 danny.chiu 2013-01-08 18:01
所谓码农 写道

我认为,人类的直觉是因为你的认知惯性,为什么你可以接受C语法系里面的赋值运算符=作为SQL和其他一些语言里面等值判断,而不能接受===操作符?要说直观,难道“==”比“=”更直观吗? 还有,“{}==!{}”这是什么操作符能解释一下吗???
关于第二点代码量敏感,未免太搞笑了,你以为你生活在90年代?我就不相信了,就算你多写一万个function,用gzip压缩一下大小会相差100字节?

认知惯性!精辟!

他举的例子是空数组和空数组比较,空对象和空对象比较,他以为结果不科学。
其实这种细节基本不会影响到多少,非要扣的话,咱们也可以分析下:
1.首先引用之间比较:[]==[],{}=={}。这肯定是不同对象的引用,所以为false;
2.[]==![]:![]是false,是个 Boolean,根据 ES5 的规定,一方是 Boolean,则将另一方转化成 Number 之后,再比较。Number([])结果是0,0==false,返回true;
3.{}==!{}:这应该是写法上的示意,在控制台输入会报错,是因为在assign operation context中的时候{}并不被解析为new Object,而是定一个scope。实际意思应该是
var a = {}, b = {};
a == !b; // false
// 或者写成这样:
({})==!({})

这和第二点类似,Number({})结果为 NaN,凡是一边是 NaN 的时候,比较结果是 false。

这位朋友估计是先入为主了~
74 楼 danny.chiu 2013-01-08 17:11
kidneyball 写道

这位朋友的“觉得XX垃圾的,基本上是XX菜鸟”观点可以跟一楼的朋友强调一下。他带头说9种语言二,自然会引来说js二的人。不知道他有什么好气愤的。

我个人的观点是,js不是垃圾语言,是种中规中矩的应用脚本语言。功能上能满足需求,但语言特性说不上完美,有很多可以提高改进的地方。但由于历史原因,它独占着前端开发领域,由于缺少对手,根本就没有改进的动力。所以我个人倾向于希望在浏览器开发领域有更多的选择,竞争。

楼主列的几点回应,还是跳不出“这就是语言特性,我就是这样”的框框。我们当然知道这是语言特性,但语言特性也分好坏,好的语言特性符合人类直觉,简单明了,容易理解和维护。我们不是问“为什么在js里会这样”,而是在思考“为什么js语言规范要选择这样做,有没有更好的方法,为什么它没有引入更好的方法”。

类似的例子还能举一大堆,例如:

1. []==[]是true,[]==![]也是true,但{}=={}是false,{}==!{}也是false。作为勉强入门的jser,我确实知道[]在参与==运算时被隐含转型为""(空字符串),但在与!结合时又被看成true。所以[]==![]等价于 ""==false ,而空字符串在参与==运算时被看成false。而{}在参与==运算时不做转型,两个{}字面量属于不同对象。

问题是,一种语言的语言特性经过种种组合,最终得出了如此不符合人类直觉的现象,你觉得这是一种好特性吗?

其他语言对此的处理是:
Ruby:[]==[]为true,[]==![]为假,{}=={}为true,{}==!{}为false
Python:[]==[]为True,[]==![]报错([]没有定义!操作),{}=={}为True,{}==!{}报错

我认为这两种语言的做法都相对更符合人类思维。

2. JS的主要应用场景是在网络上传输,代码中每个字符都是对应着流量。在不影响理解和功能的前提下,自然是代码量越少越好。闭包是Js中一种很常用的语言特性,而事实上Js的匿名函数(Lambda表达式)定义却是诸多支持Lambda的语言中最冗长的。Ruby里写array.map {|x| x+1},Js中却要写array.map(function(x){return x;})。在不影响向前兼容的前提下,加入一种简单的Lambda语法糖在技术上根本没有难度,连Java这种出了名的老乌龟被C#逼急了也要引入更为简洁的Lambda。而Js从一开始就支持闭包,本身应用场景又对代码量敏感,却这么多年都没有改动。背后的原因,我看来根本就是因为没有竞争,所以没有动力。毕竟有很多更重要的特性都还没有那份闲情逸致加进去。


谢谢你的回复!

我觉得可能有点误解,但基本观点是一致的。对的,不要轻易的说什么东西不行,往往是对它缺乏了解,这是个浮躁的社会。就跟周易一样,如果你看到她的第一反应就是迷信,我觉得就过了,假的东西能存在五千年吗?科学只能解释它能解释的东西。后来学习了一点点《奇门遁甲》,它的象数理模型,及宇宙全息、天人合一等理论,很是经典。希望不要扯远了,如果有人不信,建议去花1-2k大洋,找个名家测测,不否认有很多摆摊骗人的。

朋友很谦虚,呵呵。我也说到了“js确有糟粕,毕竟它的设计非常仓促,有些陷阱,要不为啥 Douglas Crockford 的书名字叫《The Good Parts of JavaScript》”。和你不同的是,我的理解角度:我没有问为什么js语言规范选择这样做,有没有更好的方法,为什么它没有引入更好的方法;我是你说的反面教材,我只问了为什么在js里会这样。毕竟我改变不了它,不如以它为工具,用它来思考。了解js的走势,能用它做出好的产品、游戏引擎,这是我对自己的定位。每人侧重都有不同,我不觉得有高下之分。因此在我的角度来说,第一点js没有不符合人类直觉,为什么在js里会这样你也说明白了。至于另外两种我没觉得有多高明的地方,没有任何一种规范说哪种是标准的,所以我觉得这三种都很和谐,这只是语言特性而已!就好像有人大赞 CoffeeScript 优美一样,类似Ruby/Python等类Lisp语法,这是多么的优美!

网络传输方面,代码其实很小,合并压缩一下(甚至可以压缩变量名),也就一张图片的大小。所以就有很多有用的库来让工作变得更人性化。js不是支持匿名函数中写法最长的,as要长一些,因为还要指定返回值类型,但这一点不妨碍它红的发紫。朋友这样说有点吹毛求疵了,回想几年前从java转过来,感觉很顺畅,倒是做Rails项目时,反而很别扭了,各种缩进反而让我觉得混乱,这当然是和咱们的积累有关系,萝卜白菜各有所爱,你可能会喜欢 CoffeeScript。

js缺乏竞争,缺少动力,这是不争的事实!可喜的是,随着 html5 的来临,各种重要的特性都在完善中。
73 楼 Mr_Ron 2013-01-08 16:17
[img][/img]
72 楼 所谓码农 2013-01-08 16:15
kidneyball 写道
danny.chiu 写道

我也凑凑热闹,发表下观点,不针对任何人。
觉得javascript垃圾的,基本上是js菜鸟:这是我的观点。下面回答下上面引用的问题:
1. js是大众语言,不是高富帅。命名空间、模块、类和继承等,不是原生支持的,人们喜欢它,是因为它足够灵活。“js库一大部分是在弥补语言缺陷”,不知从何得来,js确有糟粕,在<<javascript语言精粹>>里面讲的很清楚了,觉得缺陷太多,往往是对它不够了解。
2. “==”比较的话,会进行强制类型转换,“===”会比较类型,弱类型语言,这是js的基础。
3. 这只是js的实现方式,也不是只有js这么实现的。如果你学过js的话(我的意思是把它当成一门语言),就知道,这是在用不同的引用在比较,结果肯定是不同的。如果要比较复杂对象,可以先 .toString() 再比较,或者用 JSON 序列化之后再比,你说的也是一个常用的办法。
4. 这可能就是先入为主的原因了吧。如果最先接触的是基于原型继承的语言,就会觉得这很自然,而且还节省内存。不够了解、没深入学习就会觉得,这继承机制够乱的。
5. 还是个非常基础的问题,js只有函数级作用域,没有块级作用域,没啥好说的。
6. 这结果显然是 0,很符合jser思考的习惯。如果你系统学过js,就知道js有个类似“预编译”过程,这里会把变量声明、函数声明提到前面,确定作用域链,然后逐行执行等细节。
7. 还是个js常识问题,如果结尾不加“;”,js解析时会自动帮你加上。但如果压缩、合并的话,就会出问题,因为没有“;”,就合成一长段了。但如果都按规范写,就不会出问题。function前加“;”是个很好的编程习惯,如果你觉得非常别扭,说明你还没有进入js世界。

顺便发个案例,我做的两个js游戏,有兴趣可以交流下:
1. 2年前练手拙作,坦克大战
2. h5wan平台上的打飞机游戏,还未发布,内测中。


这位朋友的“觉得XX垃圾的,基本上是XX菜鸟”观点可以跟一楼的朋友强调一下。他带头说9种语言二,自然会引来说js二的人。不知道他有什么好气愤的。

我个人的观点是,js不是垃圾语言,是种中规中矩的应用脚本语言。功能上能满足需求,但语言特性说不上完美,有很多可以提高改进的地方。但由于历史原因,它独占着前端开发领域,由于缺少对手,根本就没有改进的动力。所以我个人倾向于希望在浏览器开发领域有更多的选择,竞争。

楼主列的几点回应,还是跳不出“这就是语言特性,我就是这样”的框框。我们当然知道这是语言特性,但语言特性也分好坏,好的语言特性符合人类直觉,简单明了,容易理解和维护。我们不是问“为什么在js里会这样”,而是在思考“为什么js语言规范要选择这样做,有没有更好的方法,为什么它没有引入更好的方法”。

类似的例子还能举一大堆,例如:

1. []==[]是true,[]==![]也是true,但{}=={}是false,{}==!{}也是false。作为勉强入门的jser,我确实知道[]在参与==运算时被隐含转型为""(空字符串),但在与!结合时又被看成true。所以[]==![]等价于 ""==false ,而空字符串在参与==运算时被看成false。而{}在参与==运算时不做转型,两个{}字面量属于不同对象。

问题是,一种语言的语言特性经过种种组合,最终得出了如此不符合人类直觉的现象,你觉得这是一种好特性吗?

其他语言对此的处理是:
Ruby:[]==[]为true,[]==![]为假,{}=={}为true,{}==!{}为false
Python:[]==[]为True,[]==![]报错([]没有定义!操作),{}=={}为True,{}==!{}报错

我认为这两种语言的做法都相对更符合人类思维。

2. JS的主要应用场景是在网络上传输,代码中每个字符都是对应着流量。在不影响理解和功能的前提下,自然是代码量越少越好。闭包是Js中一种很常用的语言特性,而事实上Js的匿名函数(Lambda表达式)定义却是诸多支持Lambda的语言中最冗长的。Ruby里写array.map {|x| x+1},Js中却要写array.map(function(x){return x;})。在不影响向前兼容的前提下,加入一种简单的Lambda语法糖在技术上根本没有难度,连Java这种出了名的老乌龟被C#逼急了也要引入更为简洁的Lambda。而Js从一开始就支持闭包,本身应用场景又对代码量敏感,却这么多年都没有改动。背后的原因,我看来根本就是因为没有竞争,所以没有动力。毕竟有很多更重要的特性都还没有那份闲情逸致加进去。

我认为,人类的直觉是因为你的认知惯性,为什么你可以接受C语法系里面的赋值运算符=作为SQL和其他一些语言里面等值判断,而不能接受===操作符?要说直观,难道“==”比“=”更直观吗? 还有,“{}==!{}”这是什么操作符能解释一下吗???
关于第二点代码量敏感,未免太搞笑了,你以为你生活在90年代?我就不相信了,就算你多写一万个function,用gzip压缩一下大小会相差100字节?
71 楼 kidneyball 2013-01-08 14:22
danny.chiu 写道

我也凑凑热闹,发表下观点,不针对任何人。
觉得javascript垃圾的,基本上是js菜鸟:这是我的观点。下面回答下上面引用的问题:
1. js是大众语言,不是高富帅。命名空间、模块、类和继承等,不是原生支持的,人们喜欢它,是因为它足够灵活。“js库一大部分是在弥补语言缺陷”,不知从何得来,js确有糟粕,在<<javascript语言精粹>>里面讲的很清楚了,觉得缺陷太多,往往是对它不够了解。
2. “==”比较的话,会进行强制类型转换,“===”会比较类型,弱类型语言,这是js的基础。
3. 这只是js的实现方式,也不是只有js这么实现的。如果你学过js的话(我的意思是把它当成一门语言),就知道,这是在用不同的引用在比较,结果肯定是不同的。如果要比较复杂对象,可以先 .toString() 再比较,或者用 JSON 序列化之后再比,你说的也是一个常用的办法。
4. 这可能就是先入为主的原因了吧。如果最先接触的是基于原型继承的语言,就会觉得这很自然,而且还节省内存。不够了解、没深入学习就会觉得,这继承机制够乱的。
5. 还是个非常基础的问题,js只有函数级作用域,没有块级作用域,没啥好说的。
6. 这结果显然是 0,很符合jser思考的习惯。如果你系统学过js,就知道js有个类似“预编译”过程,这里会把变量声明、函数声明提到前面,确定作用域链,然后逐行执行等细节。
7. 还是个js常识问题,如果结尾不加“;”,js解析时会自动帮你加上。但如果压缩、合并的话,就会出问题,因为没有“;”,就合成一长段了。但如果都按规范写,就不会出问题。function前加“;”是个很好的编程习惯,如果你觉得非常别扭,说明你还没有进入js世界。

顺便发个案例,我做的两个js游戏,有兴趣可以交流下:
1. 2年前练手拙作,坦克大战
2. h5wan平台上的打飞机游戏,还未发布,内测中。


这位朋友的“觉得XX垃圾的,基本上是XX菜鸟”观点可以跟一楼的朋友强调一下。他带头说9种语言二,自然会引来说js二的人。不知道他有什么好气愤的。

我个人的观点是,js不是垃圾语言,是种中规中矩的应用脚本语言。功能上能满足需求,但语言特性说不上完美,有很多可以提高改进的地方。但由于历史原因,它独占着前端开发领域,由于缺少对手,根本就没有改进的动力。所以我个人倾向于希望在浏览器开发领域有更多的选择,竞争。

楼主列的几点回应,还是跳不出“这就是语言特性,我就是这样”的框框。我们当然知道这是语言特性,但语言特性也分好坏,好的语言特性符合人类直觉,简单明了,容易理解和维护。我们不是问“为什么在js里会这样”,而是在思考“为什么js语言规范要选择这样做,有没有更好的方法,为什么它没有引入更好的方法”。

类似的例子还能举一大堆,例如:

1. []==[]是true,[]==![]也是true,但{}=={}是false,{}==!{}也是false。作为勉强入门的jser,我确实知道[]在参与==运算时被隐含转型为""(空字符串),但在与!结合时又被看成true。所以[]==![]等价于 ""==false ,而空字符串在参与==运算时被看成false。而{}在参与==运算时不做转型,两个{}字面量属于不同对象。

问题是,一种语言的语言特性经过种种组合,最终得出了如此不符合人类直觉的现象,你觉得这是一种好特性吗?

其他语言对此的处理是:
Ruby:[]==[]为true,[]==![]为假,{}=={}为true,{}==!{}为false
Python:[]==[]为True,[]==![]报错([]没有定义!操作),{}=={}为True,{}==!{}报错

我认为这两种语言的做法都相对更符合人类思维。

2. JS的主要应用场景是在网络上传输,代码中每个字符都是对应着流量。在不影响理解和功能的前提下,自然是代码量越少越好。闭包是Js中一种很常用的语言特性,而事实上Js的匿名函数(Lambda表达式)定义却是诸多支持Lambda的语言中最冗长的。Ruby里写array.map {|x| x+1},Js中却要写array.map(function(x){return x;})。在不影响向前兼容的前提下,加入一种简单的Lambda语法糖在技术上根本没有难度,连Java这种出了名的老乌龟被C#逼急了也要引入更为简洁的Lambda。而Js从一开始就支持闭包,本身应用场景又对代码量敏感,却这么多年都没有改动。背后的原因,我看来根本就是因为没有竞争,所以没有动力。毕竟有很多更重要的特性都还没有那份闲情逸致加进去。
70 楼 danny.chiu 2013-01-08 09:51
半人马 写道

1. 语言层面缺乏namespace. 别跟我说有n多的库都能解决这个问题,javascript二就二在别的语言的库都在做实事,js的库一大部分在弥补语言缺陷。
2. 万恶的type coerce:  
1 == “1” => true

3. 弱智的判等
   
    {} == {} //false
    ['a', 'b'] == ['a', 'b'] // false
    

    要基于值判等?可以,为每一个类型写一套基于值的deep equality test
4. 乱七八糟的继承机制
    prototype和constructor指来指去,成员一会要放在constructor里,一会要放在prototype里,最后人们终于忍受不了了,搞出来一个Object.create
5. 恶心的scoping,跑跑这段代码:
   
   var arr = [1,2,3];
   var out = [];
   for(var i = 0; i<arr.length;i++) {
      var item = arr[i];
      out.push(function(){ alert(item); });
   }
   out.forEach(function(func){ func(); });

6. hoisting
引用一下肾球(真是好名字)的例子
a = 0;
(function foo() {
   a = 3;
   var a;
})();
alert(a);

7. ;不是必需的,但不写经常会有意外的结果, 为了避免潜在的bug,经常需要写丑陋的 ;function(){...} 


我也凑凑热闹,发表下观点,不针对任何人。
觉得javascript垃圾的,基本上是js菜鸟:这是我的观点。下面回答下上面引用的问题:
1. js是大众语言,不是高富帅。命名空间、模块、类和继承等,不是原生支持的,人们喜欢它,是因为它足够灵活。“js库一大部分是在弥补语言缺陷”,不知从何得来,js确有糟粕,在<<javascript语言精粹>>里面讲的很清楚了,觉得缺陷太多,往往是对它不够了解。
2. “==”比较的话,会进行强制类型转换,“===”会比较类型,弱类型语言,这是js的基础。
3. 这只是js的实现方式,也不是只有js这么实现的。如果你学过js的话(我的意思是把它当成一门语言),就知道,这是在用不同的引用在比较,结果肯定是不同的。如果要比较复杂对象,可以先 .toString() 再比较,或者用 JSON 序列化之后再比,你说的也是一个常用的办法。
4. 这可能就是先入为主的原因了吧。如果最先接触的是基于原型继承的语言,就会觉得这很自然,而且还节省内存。不够了解、没深入学习就会觉得,这继承机制够乱的。
5. 还是个非常基础的问题,js只有函数级作用域,没有块级作用域,没啥好说的。
6. 这结果显然是 0,很符合jser思考的习惯。如果你系统学过js,就知道js有个类似“预编译”过程,这里会把变量声明、函数声明提到前面,确定作用域链,然后逐行执行等细节。
7. 还是个js常识问题,如果结尾不加“;”,js解析时会自动帮你加上。但如果压缩、合并的话,就会出问题,因为没有“;”,就合成一长段了。但如果都按规范写,就不会出问题。function前加“;”是个很好的编程习惯,如果你觉得非常别扭,说明你还没有进入js世界。

顺便发个案例,我做的两个js游戏,有兴趣可以交流下:
1. 2年前练手拙作,坦克大战
2. h5wan平台上的打飞机游戏,还未发布,内测中。
69 楼 danny.chiu 2013-01-08 09:17
半人马 写道
所谓码农 写道
半人马 写道
damoqiongqiu 写道
非常可惜,列举的9款语言都非常二,别说替代,抢份额都抢不到。

无知者无畏。javascript无法被替代的唯一原因是历史原因。要想找到比javascript更二的语言真的不容易。

我只想说,你真的会javascript吗?你觉得哪些地方需要被替代?


1. 语言层面缺乏namespace. 别跟我说有n多的库都能解决这个问题,javascript二就二在别的语言的库都在做实事,js的库一大部分在弥补语言缺陷。
2. 万恶的type coerce:  
1 == “1” => true

3. 弱智的判等
   
    {} == {} //false
    ['a', 'b'] == ['a', 'b'] // false
    

    要基于值判等?可以,为每一个类型写一套基于值的deep equality test
4. 乱七八糟的继承机制
    prototype和constructor指来指去,成员一会要放在constructor里,一会要放在prototype里,最后人们终于忍受不了了,搞出来一个Object.create
5. 恶心的scoping,跑跑这段代码:
   
   var arr = [1,2,3];
   var out = [];
   for(var i = 0; i<arr.length;i++) {
      var item = arr[i];
      out.push(function(){ alert(item); });
   }
   out.forEach(function(func){ func(); });

6. hoisting
引用一下肾球(真是好名字)的例子
a = 0;
(function foo() {
   a = 3;
   var a;
})();
alert(a);

7. ;不是必需的,但不写经常会有意外的结果, 为了避免潜在的bug,经常需要写丑陋的 ;function(){...} 

68 楼 shuhen2011 2013-01-06 15:41
前端JS毕竟是依靠浏览器存活的,而浏览器...算了...蛋疼的地方多了。不过我觉得在服务端的Nodejs还是有点意思的,目前服务端js基本上就它最热了,至少标准还能统一一些

发表评论

您还没有登录,请您登录后再发表评论

相关推荐

  • FreshWDL:FreshWDL是WDL的纯JavaScript替代品

    FreshWDL是WDL(在Flash上​​运行)的轻量级纯JavaScript替代方案。 这使用户几乎可以从任何设备和平台访问它。 目前,它仍然很简单,几乎没有可定制性,但是只要有兴趣和支持,它就能走很长一段路! 请通过以下...

  • js_password_w_asterisks:简单的 Javascript 替代品

    js_password_w_asterisks 简单的 Javascript 替代 &lt;input type="password" ...

  • stylekit:JavaScript替代品,用于使用XML和XSL创建动态文档

    样式包 使用XML和XSL创建动态文档。 由创建和维护。 该项目当前正在。 有关如何使用样式套件的更多信息,请参见LogicPull。 配置 Stylkit带有一个配置文件config.js 。 这可用于设置Apache FOP可执行文件的位置,...

  • Pure.Lettering.js:Lettering.js 的纯 Javascript 替代品

    Pure.Lettering.js 为什么要做这个? 我是忠实粉丝,而且我已经有一段时间了。 排版是 Web 中非常被低估的部分,但只有一个问题:jQuery。 你看,关于 Lettering.js 的事情是它实际上并没有做那么多,那么为什么要...

  • Dumbdown – Markdown的替代品-JavaScript开发

    降价的愚蠢替代品。 标题的关键字是标题。 Dumbdown-Markdown的替代选项首先是示例标题,这是Dumbdown。 标题的关键字是标题。 字幕Dumbdown编译为html。 Dumbdown段落是Markdown的替代方法。 段落空行变成 链接...

  • 7月十大Java故事:5种JavaScript替代品,OpenJDK Mobile回来了等等

    1.前端开发JavaScript的5种替代方法 我们七月份最受欢迎的文章是Matthew Davis对那些不想使用JavaScript的人的五个替代选择。 这是一种很难避免的语言,但是在他的来宾帖子中,他通过5种不同的方法与我们交谈来...

  • Heroku和Netlify替代-JavaScript开发

    Heroku&Netlify替代品警告:它仍处于beta版,但我想尽快将其发布,而无需过多考虑所有内容-大部分情况下都是如此。 probably它可能到处都是bug,意大利面条代码等,请忽略它们! 关于...

  • readonly-date:JavaScript的Date类型的不变替代品

    只读日期 JavaScript的Date类型的不变替代品 执照 该存储库根据Apache License 2.0获得许可(请参阅“注意”和“许可”)。

  • squery:另一个jQuery替代品

    squery 另一个jQuery“替换” squery基于令人敬畏的并带来以下扩展: .off支持。 即使没有听众。 .on和.off支持多个空格分隔的事件名称。 当仅匹配一个元素时, $('a')返回一个Node ,否则返回NodeList 。...

  • Sucrase:超快速的 Babel 替代品-javascript

    Sucrase:超快速的 Babel 替代品 Sucrase 尝试一下 Sucrase 是 Babel 的替代品,可以实现超快速的开发构建。 Sucrase 没有编译大量的 JS 功能以使其能够在 Internet Explorer 中工作,而是假设您正在使用最新的...

  • PureDom:基于纯 Javascript 的 HTML Builder 库作为模板的替代品

    PureDom 是一种高效的 HTML 构建器和 DOM 转换器,针对最新的浏览器引擎进行了优化,但主要针对与 Node JS 和 MVC 框架一起使用,作为 HTML 模板的替代品。 它旨在将模型数据转换为语义 HTML。 PureDom 不关心遗留...

  • MDEditor:一个可替换JavaScript textarea替代品,用于编写美观且易于理解的markdown

    MDEditor-Markdown编辑器插入式JavaScript textarea替代品,用于编写美观且易于理解的markdown。 WYSIWYG式编辑器允许用户使用工具栏按钮和快捷方式修改markdown。 产生HTML的所见即所得(WYSIWYG)编辑器通常很复杂...

  • sensei:https的替代品

    Sensei 旨在替代 ,使用更简单和更新的堆栈。 它在功能方面并不符合标准,但已准备好进行试驾。 安装 使用发布的 Docker 镜像 :spouting_whale: 使用docker image pull zenika/sensei 创建别名sensei alias ...

  • shrinkray:Electron的轻量级替代品,可使用Javascript制作macOS应用

    由于仅支持macOS(目前),因此是Electron的轻量级替代品。 特征 用于将静态网站转换为macOS应用程序的CLI。 微小的应用程序大小(macOS:&lt;100K&gt;/html -o example.app 示例应用 Draw.io (单击缩略图可下载应用...

  • graphlibrary:现成的dagregraphlib替代品

    图书馆 Graphlibrary是一个JavaScript库,它提供无向和有向多图的数据结构... 它被设计为dagrejs / graphlib的现成替代品。 要了解更多 。执照Graphlibrary是根据MIT许可条款获得许可的。 有关详细信息,请参见文件。

  • sox:SOX的开源替代品

    硫氧化物SOX的开源替代品

  • 掌声:人性化的替代品

    掌声 :clapping_hands: 模式替换器,有助于创建人性化的替换。 试试,在这里您可以测试掌声的每个选项。 安装 首先,请确保您已安装最新版本的 (在此步骤之后,您可能需要重新启动计算机)。...

  • Slack开源替代品RocketChat

    Rocket.Chat 是特性最丰富的 Slack 开源替代品之一。 主要功能:群组聊天,直接通信,私聊群,桌面通知,媒体嵌入,链接预览,文件上传,语音/视频 聊天,截图等等。

  • cordova-medivac:cordova-mobile-spec 的简化替代品

    科尔多瓦医疗运输机 描述 这是cordova-mobile-spec的简化替代品。 跑步 要在平台PLATFORM上创建测试应用程序,请运行: cordova-medivac/drop.js --PLATFORM --all

  • pypy3.6-v7.3.0rc1-aarch64.tar.bz2

    Python库是一组预先编写的代码模块,旨在帮助开发者实现特定的编程任务,无需从零开始编写代码。这些库可以包括各种功能,如数学运算、文件操作、数据分析和网络编程等。Python社区提供了大量的第三方库,如NumPy、Pandas和Requests,极大地丰富了Python的应用领域,从数据科学到Web开发。Python库的丰富性是Python成为最受欢迎的编程语言之一的关键原因之一。这些库不仅为初学者提供了快速入门的途径,而且为经验丰富的开发者提供了强大的工具,以高效率、高质量地完成复杂任务。例如,Matplotlib和Seaborn库在数据可视化领域内非常受欢迎,它们提供了广泛的工具和技术,可以创建高度定制化的图表和图形,帮助数据科学家和分析师在数据探索和结果展示中更有效地传达信息。

Global site tag (gtag.js) - Google Analytics