贺师俊：JavaScript取得如今成就的天时、地利、人和

个人简介 贺师俊，网名Hax，有年头的Web开发者。信仰Web标准，HTML纯化论者+CSS理想主义者+JavaScript改革派+REST信徒。 他致力于构建真正实践互联网开放理念的Web产品，并平衡需求、技术和人性因素。所以在写代码以外，他还热切的关注可用性、无障碍性乃至更广泛意义上的用户体验（譬如售后服务）。 作为一个坚持己见的人，Hax因犀利的技术批评为人所知，其拍砖对象下到写书神棍上至业界权威，中间亦包括他的同事和朋友——因为他深信正直坦诚是技术人员必须坚守的美德，并希望通过自由而热烈的讨论推动技术社群不断成长、永葆活力。 Hax毕业于复旦大学，感兴趣的领域除了Web标准、协议、架构以及与Web相关的各种具体技术之外，还包括交互设计、编程语言和方法论，最近则迷上了字体和排版。可@haxy（推特、饭否或新浪微博）与他交流。

QCon是由InfoQ主办的全球顶级技术盛会，每年在伦敦、北京、东京、纽约、圣保罗、杭州、旧金山召开。自2007年3月份首次举办以来，已经有包括传统制造、金融、电信、互联网、航空航天等领域的近万名架构师、项目经理、团队领导者和高级开发人员参加过QCon大会。

   

1. 各位网友大家好，现在我们是在QCon北京站的现场，今天做客我们专访间的是贺师俊来自于百姓网。非常欢迎贺老师，首先想问你的问题是：你是什么时候对Web开发比较感兴趣的，当时Web开发的情景是怎么样的？

贺师俊：我最早开始做web开发的话可以追溯到98年99年的时候，当时是还在做兼容IE4的那么一个年代。到今天有很多具体的技术我已经忘记了，开始做的时候会有很多问题，是现在不能想象的。最初做的那个东西，在浏览器上写那样一些代码，然后刷新一下就能看到效果，总体的讲和今天刚来做前端的人的实际上感觉是一样的。也就是因为这样的一个感觉，所以走上了前端的这条道路。

   

2. 可能现在你要兼容的浏览器会要更多点，但当时有没有遇到过什么兼容性的问题？

贺师俊：那个年代是第一次浏览器大战的时候，主要是IE和Mozilla的前身NetScript。当然了，我开花的时候基本上IE已经开始了它的统治时期，所以基本只要考虑做IE就可以了。可也还是会有很多问题，比如遵照W3C的标准看，IE跟这个标准还是有很多的差距的，所以开发起来也不是那么一帆风顺。因为我是从那个年代过来的，而且在国内它的份额一直很高，比国外要高，所以我一直兼容了ADO很多年。虽然现在浏览器比以前有了更多，特别是移动专用的，但是和过去比较的话，开发API的难度以及跟标准相符的程度总体上是要比当年要好很多的。而且最近IE6和7的份额基本上已经在5%以下了，我认为需要兼容IE6、7的时代可以说已经过去了。

   

3. 听说你最近迷上了字体跟排版，最近参与了一个中国W3C兴趣小组关于中文排版规范的起草工作，你能聊聊这期间的故事吗？

贺师俊：好，关于排版这件事，我觉得做前端的人对整个战线会有比较多的考虑，所以你或多或少的会经历这样一个时期。我个人对这方面的兴趣主要来自我上一份工作。我上一份工作是在盛大，做电子书相关的工作，所以对这字体排版方面考虑的更多一些。最近参与的是W3C的中文兴趣小组，叫Chinese Interest Group，这其实是每个人都可以参与的。这个队伍的作用实际上是让所有对中文在W3C标准上有相关问题的人能够在一起这边讨论。

中文的排版甚至整个东亚文字的排版其实都与西方文字的排版不太一样的。比如我们有直排，是方块字，而且我们还有很多混排方面的问题。比如我们经常遇到的，西文跟中文混排，视觉效果上可能会有点问题，诸如此类。最近有这样一份文件出来，叫做《中文排版的需求》的文档，这个文档的作用是收集一些汉字输入的标准。如果要将它制定成为一个相比以前更好的标准，首先得有足够的意见与相应的输入，也就是说需要具体的排版需求，然后才能做出一个更好API或者更好的CSS相关的规范，所以我们需要讨论。那在这之前已经有了日文的排版需求，韩文的排版需求，所以现在有了中文的排版需求后，我们就在W3C成立了这么一个小组。

我在小组中只是参与讨论，是因为这个文件的起草，现在主要由一位从事数字出版相关行业的台湾董事与大陆这边的梁海以及另外几位网友在做，名字我记不得很全。最近这个工作有些不同的声音，比如这个草案做得还不够好。我觉得这事情要向前看，之前中文排版这方面的工作根本没有人员投入，现在至少有人下手做了。

在质量上有缺陷，还有待提高的原因，第一这毕竟是志愿者团体，我们在专业上有所不足。第二，日文方面的排版规范，它的起草者包括了具有国家排版标准的相关专业者，以及在微软公司做微软office的资深的工程师，显然这样一个背景下它的质量更好一些。所以如果大家对这方面有兴趣，特别是在排版方面有兴趣，或者传统的出版界从事工作的朋友，希望能来参与这个起草工作。我们在GitHub上有一个专门repo，就是这份草案，有问题可以到上面去开issue，也可以开pull request，我们可以用开源的方法推进这个工程。

   

4. 假设把这个规范由我们中国人制定好，并且我们大家都同意通过之后，提交给W3C，他们就会按照这个标准制定是吗？

贺师俊：需要强调的是这份文档它是个收集需求的文档，并不是一个通过它制定一个我们的标准。它需要收集的是在传统排版里面可能的比较罕见的排版需求。因为中文是方块字，所以它有纵横对齐这样的版式。比如中文中混排了西文，西文要尽量能够排在几个方块字的区域里面，这类算是比较罕见的排版方法。如果我们出版界的朋友觉得这是一个需求，那他就需要提出来。因为现有的CSS规范里面，可能还没有能够做到这种排版方法的相关属性和模型。所以我们首先把需求提出来，然后给CSS工作者相关的专家看，讨论如何在现有的规范里加入新的属性或者新的模型来满足这个需求，整个流程大概是这样的。

   

5. 排版规范是不是与语系有关系，或者纯粹是因为字体问题？

贺师俊：与很多因素都有关系，比方说繁体中文和简体中文在排版上就可能会有一些差异。汉语在大陆基本都是横排，竖排很罕见，其中一个原因就可能是因为电子出版物。因为虽然我们进入了电子出版时代，但是电子出版的版式没有跟上，使得排版软件只能排好横排，而无法排好纵排，所以大家都只能使用横排。其他语言也有他们的问题，比如有些语言是从右向左写的，比方说阿拉伯语，希伯来语，可能还有些有趣的语言。类似蒙古语这种情况的，这个工作现在也能是国内的专家去做。蒙古语是直排的，但是跟汉语的直排有区别。汉语是从右往左排，蒙古语是从左往右排，所以在这方面每种语言都可能有很多奇葩的需求。混排的问题还会更复杂，因为你可能会要考虑多种语言混合在一起的效果。

   

6. W3C的版式征集工作中，比如日本有国家标准委员会的起草者，有微软旗下做多国语言软件工程师，那么我们国内现在参与的人都有些什么身份，有没有出版界或者互联网公司中的人参与到这件企划中来？

贺师俊：说起来有点汗颜，中文排版的参与者就只有这位台湾的同胞是专门搞电子出版的。他自己的公司应该是做电子出版方面工作的，他参与过很多EBOOK方面的工作。大陆这边有位叫做梁海的年轻人，他有各个方面的学识，特别在语言学与排版方面见长。而国内相关的大公司里并没有什么人参与，这方面非常遗憾。据我所知，中国也是W3C设立总部的国家之一，这份草案也有邀请相关的公司，但好像参与度不是很够。

   

7. 国内相关单位参与度不高是因为什么因素呢？

贺师俊：这只能说一些我听到的传闻了。比如国内出版界的龙头企业方正公司，好像因为有专利上的考虑所以还没有参与。据说方正公司是愿意进行审阅的，但是因为W3C的相关的文档有相关的专利政策，如果参与后写了部分，这一部分专利可能需要放弃，所以不太愿意参与起草。这可能是一方面原因，还有一方面可能相关公司对这份文件本身的标准与文档相关的需求认识不太到位，我看了他们的一些反馈，大概是他们对整个web标准的构成还不是特别理解。比如认为web的排版方法主要是流式的版本，不是一个固定的类似纸张这样的东西，它不能满足所有的需求。在一定程度上，如果要出一个与艺术设计相关的书，它的形式本身可能就会影响，形式本身也是非常重要的方面，同时出版的书可能得按照固定大小的纸张上才排得好。但是我认为绝大部分的书，不属于这样的类型。与页面的构成关系并不是很大，将它印刷在一本大开面的书上或者比普通更小的书上时，内容传达还是一样的。其实类似这种，我觉得是比较符合web标准且能够做排版的东西。可能像方正这样的传统出版企业对网络有些固化的理解，这是我个人看法。

   

8. 随着移动互联网在移动开发领域的发展，越来越多的应用采用HTML＋CSS＋其他再封装的方式来开发。你怎么看待这个趋势？

贺师俊：这从有互联网开始，就已经在这么做了。如果你在一个比较纯粹的web开发和比较纯粹的net开发当中画一条线的话，我们可以看到这些年来，这条线上已经有好几个点了。比如有最传统的Hyper，它主要用web开发，但是套了net的壳。然后是现在的比如RakNet，这是最近才开源的，非常火。它是其实更属于靠近net的一类，你在上面写的不是html，而是原生组件。不过开发方法是与用Rak直接开发web的方式一样的。另外当然也有更靠近web的，比方说纯粹就是一个web的页面，特别是在国内的一些厂商的浏览器上就能看到更多的定制。再比如UC，小米，百度，他们的浏览器可能有更多的定制。百度之前把这称作轻应用，这就是比较靠近web的一个例子。这条线上你可以看到各种各样的尝试方法，我觉得是挺有意思的事情。从技术的角度来看也挺好的，百花齐放嘛。

InfoQ：让开发变得相对比以前门槛更低，大概是为了更简单更快的开发产品吧？

贺师俊：我认为每个人的关注点是不一样的，你的想法其实他们也是考虑到的。在我看来可以从更宏观的一个角度去分析——web开发和net开发区别到底在哪里。

我个人认为很大的一个区别是，web的整个技术站有个预先的理念，它是一个与设备无关的跨平台的开发方式，所以web的技术方向是我需要牺牲掉一些极致的用户体验，以此获得的更好的普世性方案。我一直提到web开发的精神其中之一是——用户最终的体验，并不由开发者决定。这点与net开发不同，net开发有非常强的控制欲。web开发认为做不到或者不应该做到强大的控制，所以放弃一些。那么用户的体验最后是怎么达成的？是通过开发者，浏览器厂商，设备厂商以及用户自己达成的。比如用户加载了浏览器插件，在浏览器上勾选自定义设置选项。比如很多浏览器上都有所谓黑夜模式，可以开启；过滤广告，可以关掉；还有像云模式，在别的地方下载你的设置等等。所以用户体验是个综合的过程。

在我想法里，并没有固定的谁对谁错，但是作为一个web开发者我觉得需要强调的是web开发的方式在它做出牺牲的同时也获得了优势，这些优势是net不具有的。传统的优势不说，web开发的或者部署比net更快。更有趣的是在用户体验这方面，虽然控制不那么强烈，但是经常在没做什么事情的时候，提升了用户体验。比如我指定了一个控件，以前在使用浏览器输入时单纯只是一个文本输入框，在代码不变的情况下，支持了html5的新的类型，用户在点这个框的时候它下面的键盘就变。不再是一个普通的输入键盘，它可能把App，或者域名的.com变成一个键，你按一下就可以把.com直接打出来。接着可能再升级一下，又获得更好的体验。比方说它把你常用的email列出来，直接在候选列表里。甚至用户可以自己提升自己的体验。比如自己控制插件，完成email填写，或者取消email的自动完成，所以对web的开发来说，放弃一些控制未必一定是坏事。有时候一直走net方向的人可能会忽略这个方面的问题——他们看到了net能做而web做不到的事情，却没有看到net有些做不到而web可以做到的。我作为一个过来人，可能是需要强调一下这种均衡。

   

9. 如今JavaScript越来越强大，ES6即将成为标准。你人其他像Python、Ruby、Go等有没有可能会像JavaScript这样发展壮大？JavaScript取得了今天的成就，在天时、地利、人和方面具备了哪些条件？

贺师俊：首先JS这个语言有很多先天的缺陷，我们不能否认这点。不过在所有的这些语言里面，JS的语言设计时间是最短的——Brendan Eich只花了十天就把一个语言给设计出来了。一个十天设计的语言，到现在用了超过十年，居然还活着而且还活得挺好，这件事本身也是个奇迹。我觉得JS最大幸运是作为了浏览器的开发语言，到现在也是唯一的。如今我们已经看到JS很多优秀的地方，举个例子：在所有动态语言里面JS的性能是最高的，唯一在性能上与它接近的是lua。但是我个人认为lua基本已经到了性能的上限，它的快来自于语言设计上的简单，而从ES6、ES7的发展上看，JS性能的提升还没有到达极限，现在还在不断的加入一些新的非常有助于性能提升的特性。就目前而言，它的性能跟java相比大概有四倍的差距，这在所有有动态语言里是最快的了。要达到这样的层面，有一个非常重要的条件，那就是竞争。我们知道JS速度其实原来也不怎么快，它发展就是因为竞争带来的。从05年web应用大爆发开始，有好多的引擎在竞争，以V8领先，然后Spark monkey以及各种各样monkey系列跟上，再有像jspcontext，webkit所带的。JS最近还更新了一个达到V8程度的版本。更用说微软，微软还是很厉害的，它要么不发力，发力起来还是很狠的。我没没有从这种竞争里看到结束的可能。有这样的一个剧烈的竞争，整个语言的发展至少在性能上绝对还有进步提升的空间。从长期看来，性能还是非常重要的。

我们在ES6开发中发现很多——我叫做program eng large的大型毕业生这类需求。JS刚刚诞生的时候是一个用于脚本的语言，它的目的就是写那些小的脚本，但今天已经变成一个通用编程语言了。在ES6加入的所有的特性中——其实在ES5已经看到了这个端倪，ES5做了很多限制，比方strike的模式，去掉了很多的有问题的特性——就是为了向program eng large的这个方向前进，包括性能方面的——把在性能方面严重不能优化的东西全都做了很强的限制，ES6也继续在这个路上前进，在program eng large方面会有整个的提升。我们还引入了class，加了好多设施，这也是web应用的本身要求。我们可以看到最近的这段时间里，除了浏览器厂商，还有社区的其他力量。作为最大的web应用之一——facebook，在推进ES的发展方面也做了很多的贡献，让我们看见了很多框架，提出了各种问题和需求。我们的objective observ这个API，实际上就是为了所有的框架的需求才出现的。这些方面挂一漏万，只能说真的是天时地利人和在一起，JS的前途不可限量。可能因为我是开发web的人所以这么说，不过其他语言我也在用。比方说我们公司在使用PHP，最近从5.3开始的好多版本我仔细看了，发现如今PHP在语法上和一些特性上与JS变得越来越像了，不可否认它也是在进步的。

InfoQ：其他语言比重是不是就比较轻了，但有没有可能在一定场景下也会发展比较快？

贺师俊：我是有观点的，不会去说大家好都好的这种话，我个人不是特别看好像Ruby啊Python的未来的发展，当然它们也是一个成熟的，有一个很好的发展前景的语言。但是从发展的速度上来讲，我认为JS语言的发展速度已经远远超过了它们。其实我们之前一直很担心ES4会死掉，然后被拖累好多年。因为JS有很多的问题，比方说浏览器并不是升级了就能用新的技术，还要兼容老的，所以它会被很多东西拖累。可是我发现今天这些问题突然被社区解决了。这次我做的分享是ES的实战，里面说到的Babel是其中之一，它的编译器的架构非常有意思，是完全模块化的。可能我孤陋寡闻，这样的编译器，在其他语言里没有看到过。它有一个非常有意思的功能——当你知道浏览器已经支持了一些新特性，你就可以关闭部分编译，同时开启部分新的特新。这种编译器架构里会形成一个非常好的良性循环——社区可以有选择的使用新的语言扩展，也可以用老的，更新同时保持了很好的兼容性。这件事情，把以前的遇到的那些问题解决了。虽然是ES6实战，但其实一些ES7甚至有ES8才能定下来的特性，我们已经能够使用了。虽然在实践上还会遇到各种问题，可是在整体架构上，居然会这么简单，开发中的企业居然是这么顺畅，这件事在我看来是难以想象的。你可以看看在其他语言社区里如果要增加一个语言特性会是怎样的一个过程。所以我觉得这是我对JS未来充满信心的重要原因——它的循环已经建立了起来。而我并没有在其他的语言社区里发现有这么好的一个机制。

   

10. 你常常犀利的批评，颇有冯大辉的影子，能谈谈你印象比较深刻的几次争论吗？这些争论对你和你的技术观点有什么影响？

贺师俊：我觉得这说法也是个误解，因为我其实也没有特别的去争论。我跟冯大辉是不能比的，因为我只是在某个技术方面提出问题。可能大家此一次知道我是因为我写了一篇文章，叫做炮轰《JavaScript征途》。那本书写得有些问题，里面有些东西在基本概念上有点错误。这是好几年之前的事情了，说起来有点惭愧，我当时写了很多技术blog，大部分文章点击率不怎么高，就这个文章的点击率特别高，只是因为有吵架的事情在里面。他具体有些什么错误我记不得了，我只记得一个。他可能说的是“浮点数是在引擎里面以字符串保存的”，这个你怎么听都感觉错得离谱。而且炮轰他也不是单纯因为他有错误，我觉得问题在与作为写书的人他本身对这个错误没有一个正确的认识。比如说写错了应该去纠正，或者应该找些人帮我看看如何把这些问题解决掉。他当时只是找了社区有名的人帮他写推荐，但是没有找他们去真正的做一个技术上的review。然后你指出他的问题他态度还很差，他觉得你这个是要怎么怎么样。我觉得这个是最不能忍的，倒不是说这本书一定是市场上最烂的。这个事情可能在技术界或这说在技术出版界有那么点小波澜。这算是一次，不过我觉得有些事情还是要去有人去做的。另外可能有几次吧，比如有时候会有技术上的争论。 像前面说的，我是不太喜欢说你好我也好的话，我认为其实技术问题是需要有争论的。讲一个例子吧，我有一次去听别人的演讲：我问他说为什么你选择了这个工具，没有选择了另外一个工具呢。他说觉得适合我嘛。我说那为什么适合你的呢。他说就是适合我嘛。然后这个问题就无疾而终了。作为一个对技术有追求的人来说，我认为我们需要刨根问底的精神，我们不能因为自己觉得好就好，要能告诉别人好哪里。

很多时候如果我们去看前端做的一些工程类的事情，其实是需要这样的追问的，因为我们在这个方面本身思考的并不够多，而前端本身在这个方面的时间也不是很长。从05年算起的话到现在也才10年，跟整个的软件工程比起来的话我们还很年轻。它里面有很多问题我们现在可能是不知道的，并且前端又是一个特殊的位置，它和普通的开发还是有非常大的区别的。因为它出在一个很大的交叉领域中，受到各方面的影响。在整个开发链条上，它处于一个中点的位置，上下左右前后他都要考虑，与设计师，与业务，其实是很难做的地方，当然这是站在前端的角度说的。它的困难不是在于说本身的技术，而是在于整个工程上它有多少挑战，所以我们要有意识的去问为什么。可能有很多前提条件，比如团队的人人构成，组织结构，你的流程和你的能力。如果我们不把这个前提讲出来的话，单纯因为你说这个工具好，这是废话，甚至可能是错误的话。大家知道我有时候会批评某一些方法论，特别是一些CSS的方法论。所谓方法论存在是有原因的，不知道原因就说好或者不好我觉得是不恰当的，所以大概会有这些。可能最近还有一些关于讨论promise的，跟一些同事争论他们自己写的一些其他的异步的处理方法。我今天分享里也讲了，promise已经变成标准了，一个东西如果变成了标准，首先要知道的一点是，跟着标准走是有很多好处的。更不要说这些实践还没有它好。promise这个标准经过了社区的大量实践，而且有语言专家的研究，它确实比现在大部分的异步方案都要好。当然了，现在有些异步方案的需求promise还没有满足，但是它构成的是一个基础，其他的东西是要基于它的。

InfoQ：好，感谢你接受我们今天的采访。