這是一段?Oleg Podsechin與NodeJS主程序員Ryan Dahl之間的訪談錄。雖然不是NodeJS的教程，但是從訪談之中可以看出關于NodeJS的一些情況，幫助我們理解NodeJS之所以存在的前因后果。
???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? Frank.

OP:?第一個問題就是介紹一番了。你是如何做出 NodeJS 來的？你以前有 JavaScript 的經驗嗎？你是什么時候開始 JavaScript 的，還有就是事件驅動的項目？The first question is an introduction really. How did you arrive at Node? Did you have experience with JavaScript before? When did you get started with JavaScript? And also event driven software?

Ry:?我曾經接觸過一些 C 項目，各種各樣的服務端 C 程序，有些也是事件驅動的。個中經歷使得我明白，許多代碼都是一樣的，我只是在反復寫啊又寫。C 本身很好用，不過我還是希望通過腳本以同樣的方式來控制那些服務端。I was a contractor and I was doing various little C projects usually involving server and event driven software and I realized that I was doing this same code over and over. C is a nice language to work in, but I wanted something I could script in the same way that I was programming these servers.

OP:?你做過前端的 JavaScript 嗎？Had you done any front end stuff in JavaScript?

Ry:?做過。在 RoR 里做過一些，那時候我在不斷地寫前端代碼。寫前端之余我還寫過一點的 Ruby 服務端程序，叫 Ebb，意思是更快的 Mongrel。那些代碼就是 NodeJS 的前身啦。A little. I used to work a lot with Ruby on Rails – so I’d often be dealing with front-end code. Back then I wrote a little Ruby web server called Ebb that was meant to be a faster Mongrel. That code was the starting point for Node.

OP:?Ebb應該用C寫的吧？那么整個順序下來，就是，打一開始時 Ruby 寫的，然后用 C，最后落實 idea 的時候就是 JavaScript 了吧？Ebb was mostly in C right? So you went from writing it in Ruby, then writing it in C and now you’re sort of ending up writing it in JavaScript?

Ry:?是的。最初過程是從 Ruby 到 C。有段時期我想寫個小巧服務端，就是一個 C 庫，僅僅是想想而已，因為后來發現，要用 C 完成一切的事情的話，那難度太高了。有一日我靈光一閃，“JavaScript 不是絕佳我想要的好語言嗎？”。記得這是發布 V8 之后的幾天內想到的。Right. So what originally was Ruby turned into C. For a while I toyed with the idea of having a small web server C library – but it’s hard to get anything done in C. One day I had this epiphany: “JavaScript is exactly the language that I’m looking for here.” That happened shortly after V8 being released.

OP:?你說你總是離不開兩門語言：C 和 JS。那么，JavaScript 作為一門通用的編程語言，您對此有何看法？You’ve?said that there are two languages that will always be around: C and JavaScript. So, what are your thoughts on JavaScript as a general purposed programming language?

Ry:?JS在某些方面，的確與其他的動態語言相當地不同。它沒有線程。并發的模型完全基于事件。僅此一點就和別的主流動態語言區分開來，比如 Ruby 和 Python。至少在解決某些問題的方面上，我覺得 JS 有它的長處的，比如寫一個 IRC 服務器的時候，我就覺得寫起來很輕松。JavaScript has certain characteristics that make it very different than other dynamic languages, namely that it has no concept of threads. Its model of concurrency is completely based around events. This makes it rather different than other general purpose dynamic programming languages like Ruby and Python. At least for certain classes of problems, I’ve found JavaScript to be much easier to program in—for example when writing an IRC server.

OP:?你覺得 JS 前景如何？是否認為 JS 會日益流行，包括服務端和桌面上運行？How do you see the future of JavaScript? Do you see JavaScript becoming increasingly more prevalent, not only on servers but also on desktops?

Ry:?JS已經在描述 GUI 的領域干得不錯了。我認為像瀏覽器 API 風格的 JS 程序會在桌面大行其道。JavaScript is already doing a great job describing GUIs. I think with a familiar browser-like API JavaScript could also make a good desktop application language.

OP:?JS 很容易亂，人們都在復制、粘貼 JS 的代碼……JavaScript is quite unstructured, so people just copy paste JavaScript code …

Ry:?半點沒錯。缺乏一個模塊系統肯定是致命的不足。還有 JS 鼓勵人家多用全局變量，把一切都扔到全局變量中去。這真是 JS 該批評的地方，雖然有補救的辦法克服不足。Yeah, not having a module system doesn’t help. JavaScript really encourages people to dump everything into global variables. That’s a real detractor for JavaScript but in the end better practices can overcome that sort of thing.

OP:?那么，你有留意 ECMAScript4 、ECMAScript5 和它們的討論嗎？So, did you follow the whole discussion around EcmaScript 4 and EcmaScript 5?

Ry:?我同意 Crockford 對語言的看法，就是保持精簡。而?JavaScript?其中一個可愛的地方，就是其簡潔性。我自己來說，對怎么弄好一件事情沒有太多的預設性的看法，自由一點好——好比 I/O 的問題上。恰 好ECMAScript 4 并不包含 I/O 的內容，并讓我由頭搞過。新版本變化很大，而我想說的是，ECMAScript 5 功能上會更好一些。?I like Crockford’s opinion that the language should be kept simple. One of the best things about JavaScript was its simplicity. It didn’t have many predefined ideas about how to do stuff – particularly for I/O. Although EcmaScript 4 didn’t define any I/O, it did define a lot. It did make a lot of breaking changes. That said, I wish EcmaScript 5 did have a few more features.

OP:?比如呢？?Any particular ones in mind?

Ry:?那個叫什么？反構分配？如果右邊有個數組，左邊有個多個變量，那么就一次性定義，不錯的功能。What’s this called? Destructive assignment? If you have an array on the right and a list of variables on the left, and they can be define that way. That would be nice to have.

OP:?Rhino 里已經有，V8 里沒有。That’s included in Rhino, but not in V8

OP:?嗯~咱們說說 NodeJS。在設計這個項目的時候，你遇到了哪些最困難的地方，需要你認真地做出決定？So let’s move on to Node itself. what is the most difficult design decision you made with regards to the project?

Ry:?比較難的部分……嗯……我接觸到的……我初衷是做的一個純粹的非阻塞系統，而不用去考慮模塊等的這樣大頭的問題。瀏覽器中通過 Script 標簽加載 JS 都是非阻塞的。你不知道那些腳步究竟何時下載完畢，完畢了的話會觸發 onLoad 事件。樸素地說，這點與NodeJS類似。你以模塊形式 load 一堆 JS，也不知道他們何時解析完畢（interpreted, fully evaluated），除非有一個 “loaded” 的標志，通知已經加載完畢。這樣搞的話就有點麻煩了。你不光需要 “require” 加載你所需要的包，而且還要準備好回調以等待完畢的時刻執行。Something that was very hard for me was … my original idea was that it was going to be purely non-blocking system and I’ve backed out of that a big in the module system and a few other areas. In the browser load JavaScript from a script tag is non-blocking. You don’t really know when the scripts are completely evaluated until an onLoad callback is made. Originally Node was similar. You would load a bunch of module files and you wouldn’t know that they were fully interpreted, fully evaluated, until a “loaded” event was . This made things a bit complicated. You couldn’t just do “require” and start using that stuff right below it, you had to wait for the callback to do that.

OP:?連 Hello world 程序運行起來有一個縮進。The hello world app would have one more indentation.

Ry:?是的。Right.

OP:?不少人喜歡 JS 的一項特點是，既可在瀏覽器中寫 JS，又可在服務端中寫，這不是一舉兩得嗎？呵呵。但 CommonJS 的模塊標準好像又無法在瀏覽器中應用，那么既如此，是怎么另辟蹊徑使得 Framework 可以達到異步加載的目的的呢？But it’s funny because people say that one of the benefits JavaScript offers is that you can use it in the browser as well. You can run the same validation logic on the server and browser, but the CommonJS module spec doesn’t work within the browser, so there are these efforts to try and make frameworks with asynchronous module loading.

Ry:?是的，這就是設計上所謂困難的地方，我設想 NodeJS 是類似瀏覽器那樣的，盡管方法可能不太一樣但是結構是一樣的，這樣移植的時候就會方便些，連方法縮寫也參照瀏覽器命名的。最初的時候 NodeJS 的確如此——完全是瀏覽器那樣子的，甚至連 “window” 對象都有。于是，我靜下慢慢細想，反倒覺得也沒啥必要讓它們太一致，服務端還是服務端的。因此我使用 CommonJS 的模塊系統就自然而然了。大伙考量 CommonJS 的甚多，替我們費心，結果使得開發者可以省時省力。require 是阻塞的，另外 NodeJS 中一些小的地方也是阻塞的。不過沒關系，只是一些小地方非阻塞不可，全盤估量 NodeJS 99% 都秉持非異步編程模式去倡導的，——但哪怕是到處都是同步的操作，也是可以正常工作的。如果同步加載模塊對于服務端編程問題則不大。Right, so in terms of difficult design decisions, I wanted Node to be browser-like. Maybe it didn’t use the same methods but the same structures could be ported easily, aliasing methods to the browser ones. Originally Node achieved that—it was totally browser-like. Originally, it even had a ‘window’ object. I slowly backed off that API as it became clear it wasn’t necessary to have the server-side environment be exactly the same. So I went with the CommonJS module system which was rather reasonable; the CommonJS people had put a lot of thought into it and I didn’t really want to worry about modules so much. So yeah, require is blocking and there are some other minor things that are blocking in Node. Generally this pragmatic approach of being non-blocking 99% of the time, but allowing a few synchronous operations here and there has worked out well. It probably doesn’t matter for a server-side program if you load modules synchronously.

OP:??既然 CommonJS 涵蓋那么多的主題，是否也有一些您是在跟進著并不時參與討論的？So on the topic of CommonJS, are you following any of the APIs or any of the discussions on the list?

Ry:?嗯，是的。Yeah, sure

OP:?最吸引你的是什么主題？And which ones are you most interested in?

Ry:?恕我直言，CommonJS 的規范良莠不齊。一些規范真的只是預規范，規范而已，沒有實現。結果我發現我錯了。有一個規范指示服務端 JS 的接口已經很難得的了，因為如要要在不同 API 上花時間，實在太痛苦，有標準就好。二進制規范對 JS 來說尤其重要，原因是 JS 根本沒有一個處理二進制的機制。CommonJS 模塊規范不錯、asset 規范不錯，至于其他模塊則待考查。CommonJS has some good specs and some less good specs. Some specs are rather prescriptive without any implementation – which I find wrong. I do like the idea of having a common server-side javascript interface – I just think it’s going to take some time to experiment with different APIs. A binary spec is quite important because JavaScript currently lacks a way of dealing with raw binary in any reasonable way. The module spec is good, the assert spec is good, the others are questionable.

OP:?包的規范呢？What about the package spec?

Ry:?Oh yeah，看上去很贊。我覺得里面仍有不少可圈可點的地方，但我不打算插手包系統，了解得不算多。Oh yeah, it also looks good. I don’t want to work on a package system, so I’m not following it super closely, but I think that there’s a lot of good ideas there.

OP:?作為一個用戶必然使用包系統，那么你會采用哪一種呢？As a user you must use a package management system. Which ones do you use?

Ry:?玩 NPM 比較多，有不少 bug，可還是能用。I’m playing around with NPM. It’s OK, kind of buggy, but you can use it.

OP:?看來還是涉及到包，還是會對 Node 核心產生重要的影響，但如果是外置的包，如 XML 解析，你覺得還有沒有漏掉重要的包？So with regards to packages, obviously there’s some stuff that’s going into the core of Node, but external packages, like XML parsing, are there any packages that you think are important that aren’t there already?

Ry:?亟待改進的 MySQL 解決方案，如 libmysql_client，libmysql_client 會導致阻塞所以仍稱不上是一個方案。尚有其他的方案也仍有不少 bug。對于那么多人使用MySQL，卻是用起來還是不順，就是一大障礙。這是其中一個問題。有一段時間我很渴望一個不錯的JavaScript HTML解析器，但居然也搞掂了；我也想有個 DOM實現居然也有了。我較傾向用 Thrift 的方式（thrift屬于facebook.com技術核心框架之一，使用不同開發語言開發的系統可以通過該框架實現彼此間的通訊）訪問Cassandra，不過就還沒有弄好。There needs to be a better MySQL solution, libmysql_client, the library that comes with MySQL is blocking so that is not a solution. There are other solutions, but they seem kind of buggy. A lot of people use MySQL and it would be a hindrance for them if they couldn’t access that easily. That’s one.?
For a long time I was lusting after a good JavaScript HTML parser, but it seems that has solved. I also wanted a DOM implementation and it seems like that’s been solved too. I would really like a way to access Cassandra, which uses Thrift – that’s not been done yet.

OP:?似乎當前尚無一個 JS 的 Thrift 庫。There aren’t really any decent JavaScript Thrift libraries

Ry:?由于有項目正在使用 Thrift，所以我們也有一定了解，就是發現 Thrift 里面的一些問題，不是太到位。如果可以切入綁定 Thrift（binding ） 就最好。Thrift is a piece of crap but unfortunately some projects are using it so we’ve got to interface with it. Some sort of Thrift binding would be good.

OP:?下次發布之中，他們期待出現 RESTful 的接口？I think in the next release they’re looking to have a RESTful interface.

Ry:?據說他們正在引入基于 Avro 的接口，一種新型的 PRC 消息序列化。我不清楚 Avro 到底可以表現得有多好。Avro 可以綁定到 Casandra，光看這一點很不錯。那么是否代表可以取代 Thrift，我想也不是一概而論的。AvroI’ve heard they’re introducing an interface based on Avro, a new message serialization RPC thing, but I’m not sure how good the Avro support is. Avro seems a lot better than Thrift so just binding to Avro would be the best way go for talking to Casandra – I don’t know.

連接數據庫無論對那個用戶都是很重要的，不用多說，故所以 MySQL 的還是屬于大頭問題。Being able to connect to databases is important for users. If it’s not there, then it’s a total roadblock for a lot of people. So, MySQL is a major one.

OP:?另外一方面，有一大趨勢，就是透過服務端的JS可以看出它與非關系型數據庫將是一種“天作之合”。如果你愿意，你可以連接不同類型的數據源在一起，Nodejs 在這方面還很出色。CouchDB 的家伙正是深諳此道。你有哪些想法，是否覺得這方面大有可為呢？A slight aside, but a big trend, aside from server side JavaScript is non relational databases and Node seems like the perfect glue, if you will, to connect these different data stores together. CouchDB guys are using it for that purpose. What are your thoughts, can you see an opportunity there?

Ry:?沒錯，Node 恰好填充了代理層和認證層，介乎于后端存儲與客戶端之間。所以沒錯，我覺得還好而且同意 CouchDB 的思想，就是封裝的應用程序可以放置到數據庫中去。保存的東西都可以在 Couch中，而 NodeJS 就是來回處理其中的代理數據，進進出出。Exactly, Node perfectly fills the proxy and authentication layer, between the storage backend and client. So yeah, I think it’s a good sort of glue and I agree with the CouchDB philosophy that the bulk of the application can kind of sit in the database. All the hard stuff can be back in Couch and Node can just proxy data back and forth.

OP:?那么接著談談你喜歡的 Node 包，進入核心和考查項目的構建方式，你對領導開源項目有何心得？So talking about the packages you’d like in Node, moving into the core and looking at the way the project is being built, what are your thoughts on project leadership in open source projects? What do you think is the right way to do it, which things shouldn’t you do? What’s your personal approach? Because you used to post little challenges for people to get them excited and get them contributing a little bit. Can you talk more about that?

Ry:?自問，我在項目中比較強勢。我是唯一的提交者，我有權決定 NodeJS 應該長什么樣子，因為我認為這是 NodeJS 此階段比較適合采取的做法。NodeJS 一直在成長，我們打算為此成立一個委員會來決定許多事情。如果有用戶不但貢獻了項目，而且還持之以恒去維護，這就相當重要了。部分角色不接受我可以維護的 change，也就是 Reject 了很多好的代碼。主要原因是代碼不能夠吻合我所謂的“核心Node”的概念。有用戶貢獻過包管理的代碼，但卻沒有時間去維護它。I have a strong arm in the project. I’m the only committer and I dictate how things go and I think that’s a good approach for Node at this stage. At some point, hopefully, Node will grow up and we’ll a committee that decides on things. But at the moment having somebody that’s dedicated to the project and who will make sure that any changes that go in will be maintained is important. Part of that roll is not accepting changes that I can’t maintain myself, and so it means rejecting a lot of good code – just because it doesn’t fit into my contrained idea of what “Node core” is. There are users who would have contributed, for example, package manager code, but it’s not something I have time to maintain.

OP:?做對的事情……Nudging them a little bit in the right direction …

Ry: Yeah.

OP:?按照大家對項目的了解，都是說你。你現在是供職于 Joyent，還是全職搞 Node？Moving on, with regards to commitment to the project, you’re saying that you’re fully behind (it and so on and so forth,) so you’re currently employed by Joyent? and working 100% on Node?

Ry:?嗯，NodeJS 的項目主頁就是在 NodeJS 上面跑的。Yeah – Node and projects based on Node. It’s great.

OP:?估計關于 NodeJS 的商業文化和商業化 NodeJS 有文章可做。很明顯 Joynt 作為一個主機供應商表現得饒有興趣，不知您有沒有了解到這些圍繞 NodeJS 的商業生態系統的逐漸形成中。要是這樣，將會是一個什么情形的商業模式？I guess the question is more about the commercial nature of Node and commercialization of Node. Clearly Joyent have an interest in it, being a hosting company, but do you see an ecosystem of businesses emerging around Node at some point and if so what types of businesses are these likely to be?

Ry:?很明顯這些業務不單 Joynet 在做，另外也有別的人在實踐著，如 Herku 在做的也是差不多的。NodeJS 的誕生，對于要求實時的網站，它打開了與別不同的一扇窗，提供了一種獨立的思路，由此也營造了別致的生態系統。One obvious thing is hosting of applications in an simple way like Heroku is doing. Node opens the door to independent contractors making little real-time websites for people — so there’s that ecosystem.

OP:?你有沒有興趣圍繞 NodeJS 構建咨詢服務嗎？還是喜歡維護核心項目多些？You don’t have an interest in building a service on top of Node? Rather you wish to maintain the core project?

Ry:?我在Joynt上班，幫他們搞產品，但是我最終的興趣是 NodeJS， 讓用戶接受它，用得開心。NodeJSI work for Joyent, so I work on products for them, but my main interest is making Node perform well and make users happy.

OP:?到尾的可是幾個抽象的問題了。第一個是關于 NodeJS 的異步其本質的問題。你是否認為將來的 Web 程序更多地往事件驅動這方面發展？不特 NodeJS，而且引申到其他 Web 程序的范圍在內。So the last couple of questions are a bit more abstract. The first one is about the asynchronous nature of Node. Do you see event driven webapps becoming more prevalent in the future? Not only Node, but asynchronous webapps in general.

Ry:耶……沒有錯。無須等待數據對于性能的增益很大——每個 TCP 流數據包會小很多。我們需要可以應付多數連接為空閑連接的程序。但是我覺得，正常的連接于異步下的安排也是有必要的，事關對性能提升都有好處，即使不太明顯。總之異步服務端節省系統資源的優點不能忽視。?Yeah, definitely. Not waiting for a database is a big win in terms of performance – the amount of bagage associated with each TCP stream is just much smaller. We need that for real-time applications where many mostly-idle connections are being held. But even for normal request response websites I think we’ll see more asynchronous setups just because of the performance wins – even if it’s necessary. It’s clear that asynchronous servers perform better in almost every way, it’s difficult to ignore that.

OP:?我認為JS的回調和縮進是異步編程的一大障礙，但比起其他語言 JS 還更輕松些。I guess writing callbacks and indentation in JavaScript is one hurdle towards asynchronous programming, but JavaScript is much easier for doing such stuff than other languages.

Ry:?綠色線程固然有效率得多，調度得更快，而且還有一個好處是，寫異步的代碼跟寫同步的樣子差不多。舉個例子就是 Eventlet，但是為什么我對 Eventlet 有保留？因為我覺得其不足之處是了漏掉了抽象層面，沒有回調函數的抽象，也就是把操作系統的基礎設施直接翻譯過來就是了。There are of course efficient green thread and coroutine implementations which allow you to write asynchronous code in a synchronous looking way – Eventlet for example. I’m not convinced that’s the right approach, I think it’s a leaky abstraction. There’s no abstraction with callbacks – it’s a rather direct translation from the interface the operating system gives.

Ry:嗯，在我個人眼中看來，多數的程序，包括我們在為大型程序寫的一部分，可視作為其他對象所服務的代理（proxies），我們從數據庫的數據代理到 Web 瀏覽器，其中的過程首先是讀取模板然后進行一些 HTML 的處理，同樣大體來說 ，也是把數據從一個地方傳送到另外一個地方。NodeJS 負責把數據從一個地方傳送別的地方，NodeJS 就是擔負起這種任務，并且要十分高效的，這就必須設定好一定的數據節流 (data throttling)。 如果從數據庫中很快地讀取數據，你可以先停止讀取流。為什么？假設在 TCP 連接中，你可以先不讀取數據源的內容和填入到 Response的 對象中，先不這樣做，而是讀出模板的開始部分發送到 Web 瀏覽器中，然后才做讀取 DB 數據庫的事情。因此你不需要馬上讀取全部表格，裝進模板。這應該是能夠貫穿整個系統，流狀形態的，所以以特定的方式去構建一個符合這種流形態的環境，就是一個問題了，并且是十分重要的難題。我們尚未達到這種水平。但我理想中的 NodeJS 應該是這樣子的。文件描述器交接到下一步流的過程中，就有頻密的數據交互，不需要緩沖大量數據。Yeah, I think most of the programs, or a large part of the programs that we write, are just proxies of some form or another. We proxy data from a database to a web browser, but maybe run it through a template first and put some HTML around or do some sort of logic with it. But largely, we’re just passing data from one place to the other. It’s important that Node is setup to pass data from one place to the other efficiently and with proper data throttling. So that when data is coming in too quickly from the database, that you can stop that incoming flow. Suppose it’s over a TCP connection, you can just stop reading from that data source and not fill up your memory with the whole response. Start sending out the first part of the template that you’re sending to the web browser and then pull in more data from the DB. You know, it must properly shuffle the data through the process without blowing up the memory if one side is slower than the other. You shouldn’t have to pull down the entire table, put into a template and then send it out. It should just be able to flow through your system, so creating an environment where it’s easy to setup these flows in the proper way is important. We’re not there yet, but that’s kind of my vision of what Node will be. Lots of shuffling of data from one file descriptor to the next, without having to buffer a ton of data.

OP:?NodeJS 的名字源自哪里？你是怎么想到用NodeJS的這個名字？So in a way you can look at different Node instances talking to each other, forming a graph with directed edges between the different nodes? Is that where the name Node comes from? How did you come up with the name?

Ry:之所以采用 Node 的名稱因為我感覺它是屬于大型程序其中的一部分。沒有進程（process）的程序，一個程序就是一個數據庫加一個應用邏輯（application ）加一個負載平衡，接著 NodeJS 便是其中的一個節點（node）。不需要太多的? NodeJS實例，一對 node.js實例加上其他東東就可以。?I used the name “Node” because I envision it as one part of a larger program. A program is not a process, a program is a database plus an application plus a load balancer and Node is one node of that. It’s not necessarily a bunch of NodeJS instances but a couple Node.js instances plus some other things.

OP:?不錯！感謝您花出寶貴時間接受采訪。Sounds good! Thank you for taking the time to chat.

來源：http://dailyjs.com/2010/08/11/ryan-dahl-part-1?http://dailyjs.com/2010/08/11/ryan-dahl-part-2?翻譯有些微刪節。

轉載于:https://www.cnblogs.com/solq/archive/2012/12/02/2797921.html

總結

以上是生活随笔為你收集整理的主程Ry访谈录的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。