1   Node package manager

npm is the package manager for Node.js. It was created in 2009 as an open source project to help Javascript developes easily share packaged modules of code. [5]

Node comes with npm installed. However, npm gets updated more frequently than Node does, so you'll want to make sure it's the latest version:

npm install npm@latest -g

There are two ways to install npm packages: locally or globally. If you want to depend on the package from your own module using something like require, then you want to install locally, which is the default behavior of npm install. On the other hand, if you want to use it as a command line tool, then you want to install it globally.

A package can be downloaded with the command:

npm install <package_name>

This will create the node_modules directory in your current directory (if it doesn't exist) and will download the package to that directory. If there is no package.json file in the local directory, the latest version of the package is installed. If there is a package.json file, the latest version satisfying the `semver rule`_ declared in package.json for that package (if there is any) is installed.

Once the package is in node_modules, you can use it in your code. For example, if you are creating a Node.js module, you can require it.

npm, Inc. is the company that hosts and maintains npm the open source project and the npm registry. [5]

The company was incorporated in 2013 and is based in Oakland, California.

Node package manager installs to node_modules.

To update a single dependency to its latest version without having to manually open the package.json and change it, you can run:: npm install {package-name}@* --save. To update a single dev dependency, add --dev.

A typical application, such as a website, will depends on dozens or hundreds of packages.

{
  "name" "my-package",
  "version": "1.0.0",
}

2   History

Ryan Dahl created Node.js in ????. Dahl stepped aside in 2012, and gave control of the project to Issac Schlueter. [4] Schlueter managed Node until 2014. [4])

On March 23, 2016, Azer Koçulu unpublished more than 250 of his modules from NPM because one of the modules was called Kik and that apparently attracted the attention of lawyers representing the instant-messaging app of the same name. One of those dependencies was "left-pad". It pads out the lefthand-side of strings with zeroes or spaces. And thousands of projects including Node and Babel relied on it. With left-pad removed from NPM, these applications and widely used bits of open-source infrastructure were unable to obtain the dependency, and thus fell over. Thousands, worldwide. Left-pad was fetched 2,486,696 downloads in just the last month, according to NPM.

To fix the internet, Laurie Voss, CTO and cofounder of NPM, took the "unprecedented" step of restoring the unpublished left-pad 0.0.3 that apps required. Normally, when a particular version is unpublished, it's gone and cannot be restored. Now NPM has forcibly resurrected that particular version to keep everyone's stuff building and running as expected.

3   Modules

module.exports is the object that is returned from require() calls. It is automatically created by Node.js. The exports variable is assigned the value of module.exports before the module is evaluated.

module.exports.add = function(a, b) { return a + b};

4   Further reading

• Brian Meckman, Ryan Dahl, Brendan Eich, Joanathon Gay. http://nodesummit.com/media/the-evolution-of-javascript/

  Explains the origins of Node.

• Douglas Crockford. http://www.yuiblog.com/blog/2010/08/30/yui-theater-douglas-crockford-crockford-on-javascript-scene-6-loopage-52-min/

• After a year of NodeJs in production. http://geekforbrains.com/post/after-a-year-of-nodejs-in-production

5   References

• Bring in data from different sources
• Deliver data concurently
• Event-ed IO architecture => Node
• Methodology
• Callbacks
• Promises

• Apache vs. NGINX

  • Requests/sec

    • Apache handles less requests per second as connections increase
    • NGINX can handle roughly the same number of requests even as the number of connections increase

  • Memory

    • Apache uses more memory as concurrent connections increase
    • NGINX uses constant memory

  • Difference?

    • Apaches uses threads
    • NGINX uses an event loop

• For massive concurrency, OS threads do not work

  • Context switching is not free
  • Execution stack takes up memory

• Green threads or coroutines can help, but threaded concurrency is a leaky abstraction

  • TODO: What is a green thread?
  • TODO: Why do coroutines help?

• By using callbacks, the program can return to the event loop immediately rather than block or uses another execution stack

  • So coroutines instead of threads?

• Why isn't everyone using event loops, callbacks, and non-blocking IO?

  • Cultural reasons

    • Thinking with callbacks is hard and considered non-intuitive / overly complex

  • Infrastructural reasons

    • man pages don't state if a function will access disk
    • database queries do not provide support for async queries

    • libraries that do work are often hard to use with other libraries

      • requires expert knowledge about non-blocking IO

• JS was designed explicitly to be used with an event loop

  • Culture already geared toward event programming

• node.js

  • Purely evented, non-blocking IS to script highly concurrent programs

  • Design Goals

    • No functions should perform IO. Always use callbacks.
    • Low level
    • Stream everything-- never force buffering of data
    • Do not remove functionality at the POSIX layer
    • Bulti-in support for most important protocols
    • API should be familiar to client-side JS programmers and old school UNIX hackers

[1]: http://s3.amazonaws.com/four.livejournal/20091117/jsconf.pdf "JSConf 2009"

---

# Fibers and Threads

The main difference between fibers and real threads is on the scheduling side: threads use implicit, preemptive scheduling while fibers use explicit, non-preemptive scheduling.

[2]

Node barely has much of a standard library.

On npm, small modules have become the norm, with users like substack and Sindre Sorhus publishing upwards of 685 and 760 modules respectively, each following the UNIX way of doing one thing and doing it well. Modules such as array-union, which returns the union of two arrays, and svg-create-element, which provides a great API for creating SVGs in the DOM, seem so absurdly obvious and small that they ought to ship with the language or platform.

Even the incredibly popular Express web framework is distributed as the kernel of a web application. In contrast to large frameworks like Ruby on Rails or Django which come bundled with templating, ORMs, csrf protection, and other features, Express only ships with middleware to host static files. Instead, the application developer is free to use whichever implementation of these features they like, and compose them together to create their application.

As a result, small modules — and apps composed of them — tend to have extremely large dependency graphs (Bitbucket's frontend, for example, contains more than one thousand JavaScript modules — many internal and many from npm).

In contrast to this, existing APIs in JavaScript and the web platform are frozen solid. Iterations to the JavaScript language, which cannot have any backwards-incompatible changes lest they risk breaking every existing site, must have entirely additive changes. After the performance woes of the Mutation Events API, for example, Mutation Observers were introduced to smooth things over. WebSQL was deprecated in favor of the lower-level, but more awkward IndexedDB. Application Cache is being phased out in favor of the lower-level and more versatile ServiceWorker. Object.observe, an ES2016 proposal which allowed observation of an object's properties, was recently withdrawn after React's preference for unidirectional data-flow and immutability took the web by storm.

Proponents of the Extensible Web Manifesto want to make the web resilient to userland trial and error the same way that Node is. Their mission is to have the platform provide as many low-level building blocks as possible, so that libraries outside of the browser can experiment freely and avoid the costly and lengthy process that formal standardization must follow. One such low-level primitive is the set of APIs for web components, which provide developers with the means to create dynamic custom elements and attributes through JavaScript, complete with encapsulation2. It's no secret that libraries, big and small, have implemented dialog functionality, but now the iteration of the API can be handled in userland, rather than needing to get it right the first time in the platform. With the low-level primitives in place, userland is free to explore higher-level abstractions in the form of small modules. In other words, no more AppCache.