#NodeSummit: Large Scale Web
Mark Mayo had been at Joyent when Node.js was being bootstrapped into existence. Joyent had been building their own PAAS service based on JavaScript on the server, but a different peculiar platform, and saw Node.js as a big improvement. Large parts of Joyents stack use Node.js today.
Bruno (at Yahoo) .. several teams at Yahoo had played with JavaScript on the server, most important would be YQL and Pipes. Over time they got the idea that is now Manhattan and Mojito. Manhattan is a new application hosting platform Yahoo is developing for use on their web properties. They looked at many different options before choosing to use Node.js.
Sean (i.TV) .. Needed to pick an application language. Started as a "TV Guide" app, with a Python implementation. Realized they needed to change the model of what they're developing. Many new kinds of applications. Needed better scale, allow engineers to work on both client and server side.
Googler .. Not aware of anything that's publicly facing that is Node.js based. Google's "Go" language is an alternative to Node? A lot of interesting alternatives. Most focus on performance advantages .. what might be more interesting is the constraints imposed by Node, and its advantages.
Mozilla is using Node which is curious because they have their own JavaScript interpreter. Browser ID is the project at Mozilla that's based entirely on Node.
How is Node holding up in the kind of scale where 500 million firefox users are hitting the Browser ID service. They chose Node because of memory footprint. Better than even Python/Django. Their service relies on cryptography on both ends, and they had a good advantage from having the same cryptography code on both ends of the pipe.
For scaling - Node has an amazing capability to produce I/O. The guy from i.TV says they never found where Node itself interfered with their ability to scale the service. Instead they found limits such as in using Nginx, and when they removed nginx from the stack the performance improved.
Is Node at a "nascent" or "immature" stage? Not really? There are serious issues with debuggability in a Node program. Compared to other platforms, you don't have much of a stack to trace back, you have a zillion anonymous functions, anonymous objects, little option for the normal debugging practices to work.
Found that Node with anonymous javascript functions all over the place, could be easily refactored with no refactoring tools. Compare with Java where refactoring is a feature of the IDE. This led to debuggability through modularizing in small tight modules that could be more easily tested.
In order to debug applications, had to divide down to small chunks.
Isn't yet a set of best practices for optimum code organization practices.
Node is great when you want to just lay down code and see where you can go. The features of other platforms like static typing that supposedly helps developer code safely, this isn't useful while you're in the exploration phase, but is more useful in later phases where it's in maintenance mode.
Google is approaching the JavaScript issue from multiple angles. Gmail, 400k lines of hand-rolled JavaScript code. Another part of Google develops based on GWT where you have Java compiling to JavaScript. Another part has a JavaScript-to-JavaScript compiler that also offers some guarantees and assistance. Another part of Google has developed Dart that is a JavaScript-like language with optional typing.
Because Node lacks debuggability features - forces the developer to rely on unit and function tests more strongly than they would in other systems.
One thing we might be immature on in Node is the best practices and tools for scaling Node to 10's of thousands of servers.
Because it's so easy to write a proxy server in Node, it lets you ignore for example using Squid or Traffic Server as the caching proxy. Instead you write your own caching server in Node. This means the whole project could be living in one code base, built using one toolset, instead of having dependencies on external systems or languages.
Using frameworks like Express rather than write your own?
Express is great. At Yahoo they started to use Express but then went in a different direction to implement their own framework, Mojito, that will be open sourced in a couple weeks. Issue from Yahoo is that Express and other Node tools are more like a framework to develop a webserver, than providing the webserver for you. With Express and other Node things the app developer in some ways has to go all the way back to the metal of understanding the HTTP protocol, where in other frameworks they do not.
Should the developers have to grok HTTP?
What about in the near future when SPDY starts supplanting HTTP? That is, what if the protocol layer changes out from HTTP 1.1 to something else? If your code is tied to HTTP 1.1 it'll be harder to shift to a newer protocol. It would be better to abstract the protocol away a bit.