epubjs
Version:
Render ePub documents in the browser, across many devices
59 lines (58 loc) • 5.14 kB
HTML
<html xmlns="http://www.w3.org/1999/xhtml"><head><title>Foreword by Ryan Dahl</title><link rel="stylesheet" href="core.css" type="text/css"/><meta name="generator" content="DocBook XSL Stylesheets V1.74.0"/></head><body><div class="preface" title="Foreword by Ryan Dahl"><div class="titlepage"><div><div><h1 class="title"><a id="forward"/>Foreword by Ryan Dahl</h1></div><div><div class="author"><h3 class="author"><span class="firstname">Ryan</span> <span class="surname">Dahl, creator of Node.js</span></h3></div></div></div></div><p>In 2008 I was searching for a new programming platform for making
websites. This was more than wanting a new language; indeed, the details of
the language mattered very little to me. Rather, I was concerned about the
ability to program advanced push features into the website like I had seen
in Gmail—the ability for the server to push data to the user instead of
having to constantly poll. The existing platforms were tightly coupled to
the idea of the server as something that receives a request and issues a
response sequentially. To push events to the browser, the platform needed to
be able to constantly handle a number of open and mostly idle
connections.</p><p>I knew how to make this work at the system call layer, in C. If I used
only nonblocking sockets, the overhead per connection was very small. In
small tests, I could demonstrate a server that could handle thousands of
idle connections or pretty massive throughput. I knew that this was the
optimal way for a user-space Unix server to be implemented. However, I
didn’t want to work in C; I wanted the beautiful fluidness of a dynamic
language. Although it was possible to issue the exact system calls I wanted
in every programming language, it was very ugly and was always the
“alternative” method of socket programming. My theory was that nonblocking
sockets were not actually difficult at all, as long as everything was
nonblocking.</p><p>Google announced Chrome and its new JavaScript engine V8 in late 2008.
A faster JavaScript engine made for a faster Web—and V8 made the Web
<span class="emphasis"><em>a lot</em></span> faster. Suddenly there was this idea of a
JavaScript arms race between Google, Apple, Mozilla, and Microsoft. This,
combined with Doug Crockford’s book <a class="ulink" href="http://shop.oreilly.com/product/9780596517748.do"><span class="emphasis"><em>JavaScript:
The Good Parts</em></span></a> (O’Reilly), shifted JavaScript from the
language everyone despised to an important language.</p><p>I had an idea: nonblocking sockets in JavaScript! Because JavaScript
has no existing socket libraries, I could be the first to introduce this new
and hopefully better interface. Just take V8 and glue it to my nonblocking C
code, and I should be done. I quit my contracting job and began working on
this idea full time. Once I made the very first version available, I
immediately had users who reported bugs; I started fixing those bugs, and
then three years passed.</p><p>It turns out that JavaScript jibes extremely well with nonblocking
sockets. This was not clear from the start. The closures made everything
possible. People were able to build very complex nonblocking servers in just
a couple of lines of JavaScript. My initial fear that the system would be
unusably niche was quickly alleviated as hackers from all over the world
began to build libraries for it. The single event loop and pure nonblocking
interface allowed libraries to add more and more complexity without
introducing expensive threads.</p><p>In Node, users find a system that scales well by default. Because of
the choices made in the core system, nothing in the system is allowed to do
anything too terrible (such as block the current thread), and thus
performance never degrades horribly. It is an order of magnitude better than
the traditional blocking approach, where “better” is defined as the amount
of traffic it can handle.</p><p>These days, Node is being used by a large number of startups and
established companies around the world, from Voxer and Uber to Walmart and
Microsoft. It’s safe to say that billions of requests are passing through
Node every day. As more and more people come to the project, the available
third-party modules and extensions grow and increase in quality. Although I
was once reserved about recommending it for mission-critical applications, I
now heartily recommend Node for even the most demanding server
systems.</p><p>This book gracefully takes the reader through a discussion of and
guided exercises for Node and many third-party modules. By learning the
material covered here, you go from basic familiarity with JavaScript to
building complex, interactive websites. If you’ve used other server-side web
frameworks in the past, you’ll be shocked at how easy it is to build a
server in Node.</p></div></body></html>