I'm more excited to see that Ben Noordhuis is still working on Node.JS core.
And yay! for the round robin cluster scheduler. Got bitten by this myself. We currently use different ports on each child process and distribute traffic on our reverse proxy server (varnish) in front of node.
They also tend to word much of their social outreach in ways that imply they are releasing it, not the community. I know they have some talented people who work hard on core, but their marketing is pretty slimy and purposely misleading in my opinion.
well I don't have anything to say regarding the marketing group, but Ben and Bert are legit. the contributions to node-inspector are great and the scaling work is much appreciated.
Interesting on the corking stuff. I looked at this a long time ago (http://baus.net/on-tcp_cork/) and found it could make a significant difference for event driven applications.
They arent actually using TCP_CORK though (its not portable), they are just constructing a cork-like behaviour, using writev to write all the parts at once.
Understood. It certainly is better to coalesce data with writev() than to use TCP_CORK.
BTW, from my link:
"If you need to write multiple buffers that are currently in memory you should prefer the gather function writev() before considering TCP_CORK with multiple calls to write()."
Slightly off-topic, but I've basically missed out on the entire Node train and I'd like to get on it. What's the best way to get started? Official docs?
StrongLoop has a few good videos to help you get a fundamental understanding of what node.js is and how it works, highly recommend spending a few minutes watching these:
My screencast [1] covers it, but if you're comfortable just diving in, the official docs are very good. Choose a simple task (like implementing a bare-bones HTTP server) and dive in.
I started looking over it again literally just yesterday. I found Express exceptionally helpful for the project I am working on (a chat server, imagine that), and the first answer on this stack overflow thread helpful as well:
I started the book "Node.js in Action" recently and its been solid; haven't finished and maybe a seasoned node dev can give better comment, but my pros:
- Well written
- Covers multiple aspects of Node (e.g. not just its use in Web Applications)
- doesn't try to teach you programming at the same time (e.g. aimed at intermediate to advanced audience)
Find tutorials,videos and books on express and connect framework to get started. Frankly the official docs suck,they are very confusing if you are used to good readable api docs.
NodeJS core is tiny, and if you understand networking and linux processes , you should be able to master NodeJS quickly, since it is basically a scriptable server.
it's important to choose the right libs too, as there is a lot of unmaintained crap on npmjs.org. check express, connect, mocha, chai, request, mongoose, commander and grunt.
Ok, I'm going to seem incredibly blunt and perhaps ignorant here. Hopefully someone can help me understand. I don't understand Node.js. Why do I care about being able to write javascript on the server? I can just as easily write a python script which, in my humble opinion, is much easier to read than javascript. I don't want to turn this into a language bashing session as I realise the argument can somewhat become a religous one. Is Node.js faster? Is it easier to hook into a web server? Why?
Node's package manager is very, very good - which I attribute to the fact that it's been able to learn from the mistakes of those before it.
Also the whole streaming/evented approach to web development is really cool. I know it's nothing new, but being able to require() a few modules and write a file upload component in 10 lines is pretty nifty.
That's interesting. I've used gem, npm, pip and luarocks. With my limited experience I'd say they're all pretty similar and all have their pros and cons. I usually resort to my OS's package manager instead. Is there a specific reason people think npm shines over the others?
Can't speak for all package managers, but I know that some do not handle multiple versions of the same package well. In contrast, NPM handles this very well. Publishing packages is also much easier than pip or Packagist (PHP) in my opinion.
- If you're building a web app (perhaps a single page web app), it might be useful that you can share client side code and server side code. Take input validation as an example -- you can use the same `validateEmailAddress` function on the server and on the client -- guaranteed to be consistent.
- Javascript is a fascinating language.
- Maybe others can contribute some performance numbers? My impression is that V8 is very fast -- can JS outperform other scripting languages?
- The whole Node.js approach to concurrency is very different than using threads -- it's fascinating, as well.
IIRC, V8 is the fastest engine for scripting languages out there, with perhaps the exception of LuaJIT and PyPy, but I'm unsure about those two. If you just compare it to canonical scripting language implementations then yeah, it's definitely faster -- some of that is down to the really advanced JIT, some of it is down to the async-everywhere design and culture.
- Provides npm (a state-of-the-art package manager which introduced a number of innovations)
- Built on V8, which is possibly the best dynamic language compiler made to date, in terms of performance
- Provides a well-done streaming I/O and event model, which many languages fail at
- Provides an extremely powerful and high performance async/concurrency model, which is set to improve as promises and other concurrency patterns mature
- Has a well-tested, high-performance, properly layered standard library (most of the time)
- Has a nice C++ extension framework
- Has a very active (though sometimes rough around the edges) developer community
The downsides are:
- It's Javascript, which has some serious design issues as a language
- Currently still suffers from callback spaghetti, which is set to improve as per point 4 above
- Can be very hard to debug in the face of its async model because of insufficient built-in debug facilities
I have to disagree with the Javascript design issues.
I've used both Python and Javascript for years, and the more I use Javascript the more I realize how ad hoc Python really is. So many of it's features (metaclasses, raising an exception to break iteration, the MRO, the import behavior, etc.) seem to be hacky solutions to problems of it's own making. Javascript is a much smaller, and therefore simpler language.
To each their own. I really dislike Javascript, and while Python is not perfect, at least it has the right set of core values and a community process that results in tangible improvement. I mean, you're complaining about the finer points of Python OOP - to me, Javascript OOP is broken, and there is no community standard to fix it.
What's wrong with raising exceptions to break iteration or with the import behavior?
Silly question: while I love promises as a way of avoiding callback hell when dealing with an all-async-all-the-time language and standard library, does Node give you actual concurrency/parallelism (compare and contrast with Go, or Erlang)? Or is it just the (admittedly still very powerful and useful) async setup that matters? If so, why?
In my oppinion, one of the coolest things about Node is the ability to share code between server and client. Especially for validation, this is awesome.
As someone who switched from python to node.js, I can give a few reasons.
1. npm is extremely easy to use and has a lot of traction. Language X is going to be a tough sell if it lacks good libraries.
2. node.js devs tend to be religiously adherent to the idea of small modules. While not everyone like this, and some would prefer large frameworks, it is definitely a more flexible model.
3. Speed. I happen to write mapping and geospatial analysis software. Most of the existing solutions are python based. I spent months optimizing one particular algorithm in python and was able to get processing time down to 70 seconds. This was not acceptable for a web app, so I wrote a new geostatistical engine from scratch in node.js. New operating time: 35ms. Sure, there were probably ways to optimize the python code further, but it was never going to touch the node implementation.
4. In data analysis type applications like this, async IO is a huge help. More connections with less servers means huge cost savings.
5. Syntax is just syntax. When I was a python dev I would look at javascript and cringe, now I find myself doing the reverse. I fully expect to look back at both and cringe when I am a few years into my next language. We all experience that feeling when we see something different than we are used to.
NodeJS is usefully to write tiny servers working together for specific purposes (nodes).
It was never designed to replace rails or django in what they do best : classic web apps with a lot of static pages served from server-side templates.
So if you are designing an online news paper, a blog or e-shop ,you shouldnt be using it.
However,you might want to send 100000 mails to your customers each week. Node can help you with that.You might want to fetch loads of data from a 3rd party api, Node can help you with that, or add real time functionalities... Node can be a component of your setup(like a RDBMS,a proxy,...),it doesnt have to be the core.
The real issue is not Node,it's all the craze around it that makes people give up solutions that work for the new hotness,so you get people trying to port rails or django to node, which is stupid.
So please dont bash Node because of the way some people try to sell it to everybody for everything.
These people will go away soon and jump in the next bandwagon,but NodeJS is here to stay.
My understanding, as an outsider, was that the birth of node went like this:
"Evented, async, processing is faster than threads in many cases. What if you had a platform/language that you could only do async IO in? Well we could take an existing language and replace the IO layer, or we could just take javascript that has no-IO layer and add it in. Thus in node it's impossible to write blocking code. (Let me knoe if I'm wrong on that last bit)."
Then it went from interesting experiment to useful, and thus to popular very quickly. Either because V8 is so very fast, or because lots of people know and like javascript, or because callbacks are not that bad :-). Not sure which.
Does anyone know of a resource tracking the remaining todo's left before Node.js 0.12 is released?
Every time I ask what the projected release date for 0.12 is I always get a "When it's ready" response. That's fine, I understand the uncertainty of software development like everyone else. But there really should be a continually updated todo list of line items that when done will mark the release of the next version.
I'm excited about generators and Koa. I just want to get an idea as to whether I'm looking at a month, 6 months or a year before I can use them in a stable environment.
48 comments
[ 2.6 ms ] story [ 110 ms ] threadAnd yay! for the round robin cluster scheduler. Got bitten by this myself. We currently use different ports on each child process and distribute traffic on our reverse proxy server (varnish) in front of node.
For _official_ messaging around Node.js, you should definitely be looking at http://nodejs.org/ and http://blog.nodejs.org/ instead!
BTW, from my link: "If you need to write multiple buffers that are currently in memory you should prefer the gather function writev() before considering TCP_CORK with multiple calls to write()."
https://www.codeschool.com/courses/real-time-web-with-nodejs
Same question on SO
http://stackoverflow.com/questions/2353818/how-do-i-get-star...
http://strongloop.com/developers/videos/#a-video-intro-to-no...
http://strongloop.com/developers/videos/#a-video-intro-to-ho...
For professional consulting, training and certification, check out http://strongloop.com/node-js-consulting/strongexpert/ as well.
[1] http://www.letscodejavascript.com
http://stackoverflow.com/questions/8144214/learning-express-...
- Well written - Covers multiple aspects of Node (e.g. not just its use in Web Applications) - doesn't try to teach you programming at the same time (e.g. aimed at intermediate to advanced audience)
NodeJS core is tiny, and if you understand networking and linux processes , you should be able to master NodeJS quickly, since it is basically a scriptable server.
it's important to choose the right libs too, as there is a lot of unmaintained crap on npmjs.org. check express, connect, mocha, chai, request, mongoose, commander and grunt.
Apologies in advance for any trodden toes.
Also the whole streaming/evented approach to web development is really cool. I know it's nothing new, but being able to require() a few modules and write a file upload component in 10 lines is pretty nifty.
- If you're building a web app (perhaps a single page web app), it might be useful that you can share client side code and server side code. Take input validation as an example -- you can use the same `validateEmailAddress` function on the server and on the client -- guaranteed to be consistent.
- Javascript is a fascinating language.
- Maybe others can contribute some performance numbers? My impression is that V8 is very fast -- can JS outperform other scripting languages?
- The whole Node.js approach to concurrency is very different than using threads -- it's fascinating, as well.
It's also javascript, (which has some really nice properties, and a few bad ones) and ubiquitous in web development already.
The real reason for it's popularity is that a lot of the ruby guys seemed to have jumped to Node.js :)
I think it's because a lot of front-end developers jumped to Node.
[1] https://github.com/TechEmpower/FrameworkBenchmarks/tree/mast...
Advantages of node.js as I see them:
- Provides npm (a state-of-the-art package manager which introduced a number of innovations)
- Built on V8, which is possibly the best dynamic language compiler made to date, in terms of performance
- Provides a well-done streaming I/O and event model, which many languages fail at
- Provides an extremely powerful and high performance async/concurrency model, which is set to improve as promises and other concurrency patterns mature
- Has a well-tested, high-performance, properly layered standard library (most of the time)
- Has a nice C++ extension framework
- Has a very active (though sometimes rough around the edges) developer community
The downsides are:
- It's Javascript, which has some serious design issues as a language
- Currently still suffers from callback spaghetti, which is set to improve as per point 4 above
- Can be very hard to debug in the face of its async model because of insufficient built-in debug facilities
I've used both Python and Javascript for years, and the more I use Javascript the more I realize how ad hoc Python really is. So many of it's features (metaclasses, raising an exception to break iteration, the MRO, the import behavior, etc.) seem to be hacky solutions to problems of it's own making. Javascript is a much smaller, and therefore simpler language.
What's wrong with raising exceptions to break iteration or with the import behavior?
You don't have to.
I agree some parts of python are hackish though. Maybe because of legacy reasons. And py3k didn't fix all of them1. npm is extremely easy to use and has a lot of traction. Language X is going to be a tough sell if it lacks good libraries.
2. node.js devs tend to be religiously adherent to the idea of small modules. While not everyone like this, and some would prefer large frameworks, it is definitely a more flexible model.
3. Speed. I happen to write mapping and geospatial analysis software. Most of the existing solutions are python based. I spent months optimizing one particular algorithm in python and was able to get processing time down to 70 seconds. This was not acceptable for a web app, so I wrote a new geostatistical engine from scratch in node.js. New operating time: 35ms. Sure, there were probably ways to optimize the python code further, but it was never going to touch the node implementation.
https://github.com/morganherlocker/turf
4. In data analysis type applications like this, async IO is a huge help. More connections with less servers means huge cost savings.
5. Syntax is just syntax. When I was a python dev I would look at javascript and cringe, now I find myself doing the reverse. I fully expect to look back at both and cringe when I am a few years into my next language. We all experience that feeling when we see something different than we are used to.
It was never designed to replace rails or django in what they do best : classic web apps with a lot of static pages served from server-side templates.
So if you are designing an online news paper, a blog or e-shop ,you shouldnt be using it.
However,you might want to send 100000 mails to your customers each week. Node can help you with that.You might want to fetch loads of data from a 3rd party api, Node can help you with that, or add real time functionalities... Node can be a component of your setup(like a RDBMS,a proxy,...),it doesnt have to be the core.
The real issue is not Node,it's all the craze around it that makes people give up solutions that work for the new hotness,so you get people trying to port rails or django to node, which is stupid.
So please dont bash Node because of the way some people try to sell it to everybody for everything. These people will go away soon and jump in the next bandwagon,but NodeJS is here to stay.
"Evented, async, processing is faster than threads in many cases. What if you had a platform/language that you could only do async IO in? Well we could take an existing language and replace the IO layer, or we could just take javascript that has no-IO layer and add it in. Thus in node it's impossible to write blocking code. (Let me knoe if I'm wrong on that last bit)."
Then it went from interesting experiment to useful, and thus to popular very quickly. Either because V8 is so very fast, or because lots of people know and like javascript, or because callbacks are not that bad :-). Not sure which.
Every time I ask what the projected release date for 0.12 is I always get a "When it's ready" response. That's fine, I understand the uncertainty of software development like everyone else. But there really should be a continually updated todo list of line items that when done will mark the release of the next version.
I'm excited about generators and Koa. I just want to get an idea as to whether I'm looking at a month, 6 months or a year before I can use them in a stable environment.
Also, NPM is an excellent package manager and makes code-reuse and API integration so much easier than other languages.