Troll. Post made no sense and came to no conclusion.
"The content server should not need to do hardly any IO. Why would an HTML content server need to write to the filesystem?"
This just shows a blatant lack of knowledge about what constitues IO. FYI, network is IO, writing to console is IO, logging is IO. The point of an evented system like node (and others based around the 'select' or 'epoll' type calls is that you can use one thread to do other things when you are waiting for the kernel to tell you your socket is ready.
Yes, I too get frustrated when 'front-end' people think they are systems engineers or super server coders, but that doesn't mean I am going to write a blog post that goes nowhere about it and completely misses the point of an evented system like this.
Post also shows a blatant lack of knowledge about what an event loop is. Node and Tornado (two event-loop based servers) are by design single-threaded. This is because for certain setups, having a separate thread for each connected client (the norm for something like Apache) can destroy your server.
IMO the main problem that event loop systems were designed to solve was the "I have a ton of people connected concurrently but the majority of the time these connections are idle". Think if you were building a chat application. Your users are connected to your service constantly (they want to get messages as soon as they arrive), but most of the time they AREN'T receiving or sending data. If you had a thread for every connected client your server would melt due to the ram overhead, even though most threads aren't doing any work 99% of the time. In an event-loop based system, you don't have this issue because everything gets handled by one thread.
Yes and no. The problem solved by event loops is the problem solved by select(): You never want to wait for a single person to do something; you want to wait for anybody to do anything.
I guess I don't understand - is this meant to be an object lesson or warning to people against using the wrong tool for a given application?
The author self-identifies their problem as: "The problem I have is processing a lot of data quickly"
Clearly, then, don't use node. But why write a blog post about not using something? A post involving a lesson learned ("I tried using node for processing a lot of data quickly, and it was terrible!") would have been more valuable.
I fully offer up the idea that I may have missed the point.
Someone should tell the Nginx guys that blocking IO is not a problem that web servers actually have. I'm sure they will be thrilled to not have to do complicated event programming anymore.
Node was created to provide an event-based web server programming model
This is not true, and it's probably why the author seems confused. Node was not primarily designed to be a web server, nor is it particularly good at that. It is much better as a server that keeps sockets open, like for a chat application.
I think the author was dead on despite some confused points - the number of problems that node is the best solution for is a fraction of what its currently being used for. It seems obvious that it's popularity is tied to server side javascript.
I was about to extract a few quotes showing a blatant lack of understanding whatsoever. In the end it got too lengthy. Looks like a Ninja stepped on the wrong land today.
All the references to threads are probably the most difficult to understand for me. Node is single threaded and one can't spawn a new one. The author seem to be using it as some sort of magical artefact.. it's beyond comprehension.
Exactly, node is useful for solving problems that you don't have. So you wouldn't use node for them, then. The answer to your own question is your own statement.
Node makes it possible to do completely new things that would be difficult to do otherwise.
I take exception to this statement: "Node enthusiasts are front-end coders not wanting to do server coding." The number of engineers who only do server-side programming these days are few and far between. I haven't worked a job in the last 4 years where no one touched the frontend at some point or vice-versa. Sure, we usually have niches where we do the majority of our work, either front or backend. But at no point are they exclusive.
Node has been a blessing for me, as a frontend engineer, because I can finally code servers in the same mindset as I write client-side javascript. We (frontend folks) live in an asynchronous world. We eat parallel requests, xhr, and async callbacks all day. It turns out that when you apply those same concepts to the server, it opens up a whole new world of possibilities.
Parallel requests and async callbacks have been hallmarks of server programming for decades. You'd have to be pretty young to think this is novel. Good protocol library designers have always exposed some mechanism for kernel-assisted polling (such as the file descriptor for the TCP socket of an LDAP connection).
So, Node solves problems we've already solved, only now using the second most poorly designed common production language available today (first place is reserved for PHP).
With that attitude we should have stopped at FORTRAN. What next, drive a Model T instead of a Civic?
Nobody knowledgeable has said that async coding is novel. What matters is that node.js is a simple(r) and effective means of writing asynchronous applications.
Uhmm, I've been writing server side code for the last decade. I've also been writing front facing code for just as long.
JavaScript works well for Node because it is a language that has evolved to be asynchronous. Not because some front-end web monkey n00bz know JavaScript. Although that is certainly a plus.
Node.JS shines when you need to write network applications. It was advertised for this purpose by its creator. That is its stated goal.
Traditional server-side solutions SUCK at this. Try writing a non-blocking server-side WebSocket server in PHP and distribute the load across all of the cores. Yeah. Exactly.
Don't get me wrong, I love PHP. But for every job, a proper tool.
Node.JS takes care of the network server and hands off the work to PHP via FastCGI. That's how it should be. Node.JS solves real problems right now. If it isn't doing that, you're trying to hammer in a nail with a screwdriver. Stop it.
Traditional server-side solutions SUCK at this. Try writing a non-blocking server-side WebSocket server in PHP and distribute the load across all of the cores.
Wouldn't the traditional way to do it server-side be to just write it in C/C++ or Java with a thread pool? Or if you prefer the evented model, Python+Twisted isn't old enough to really be traditional, but is pretty widespread; and some Java server-side apps have been moving to an async model as well.
> Wouldn't the traditional way to do it server-side be to just write it in C/C++ or Java with a thread pool?
I was a bit vague. What I should have said was that dynamic language solutions are bad at it. Certainly you can pull out C/C++, Java, Erlang, etc. but at that point, you need to compile and recompile when you change your code. You are dealing with dependencies, libraries, binary compatibility, and the usual complexities that come with compiled languages.
> Or if you prefer the evented model, Python+Twisted
Well, Node.JS isn't the only game in town, certainly. Competition is a good thing.
I don't actually think anyone should be using PHP. Just like MySQL gives relational databases a bad name, PHP does the same for server side programming. And yes actually trying to write a server in PHP would be ten times more insane. Node.js might be nice for writing servers but so is Twisted or straight Python, Erlang, C, even java with threads as someone mentioned.
I already do that. If I need to write a more traditional kind of page, I use Django and Python. Easy to setup, excellent framework and language to work with.
I use node for new cutting edge things which Django and Python can handle, but not as easily as node.
For rather small values of "massive" perhaps (i.e. single-server?).
Once you reach into realms where the label "massive" comes into play the importance of per-host performance is usually dwarfed by attributes like robustness and maturity.
"""Exactly, node is useful for solving problems that you don't have. So you wouldn't use node for them, then. The answer to your own question is your own statement."""
You'd be surprised how many people take the wrong answer, then. I've seen tons of posts touting Node from people with needs and problems that would be better served by other technologies.
"""Node makes it possible to do completely new things that would be difficult to do otherwise."""
Really? Like what? Besides running server side js (something that Netscape did back in the mid-nineties), Node offers nothing that one of the tons of evented servers/libs around could not previously handle. .
I personally like the Mongrel2 approach --combined with some non-blocking framework you got all the Node goodness, plus traditional server goodness, plus messaging, plus language agnosticity.
If you don't need node than don't use it, and yes it's not for serving static pages, but more for interactive real-time web applications. And the part where he says that focusing on serving the HTML is less important because it's just 3% of the content seems flawed, because if serving html is slow then the other contents too will be loaded later (the HTML is what requesting them).
"The problem I have is processing a lot of data quickly"
It seems that the author needs something like super performant Hadoop++. Node doesn't address these problems.
"Node enthusiasts are front-end coders not wanting to do server coding"
I think he missed the point there. Using Javascript as a server side language, node has bridged a gap so many web programmers have been crossing. With node and mongodb, JSON is a language native to the entire webstack -- which is a very powerful idea. We are able to sync datastructures across server and client now.
This rant sounds very similar to "NoSQL DBs will never reach the competence and performance of the RDBMS".
> With node and mongodb, JSON is a language native to the entire webstack -- which is a very powerful idea. We are able to sync datastructures across server and client now.
Honest question here -- outside of not calling input and output transforms to or from JSON and native array/list/whatever, what is the new ability and the powerful idea? Aren't the two transforms pretty insignificant in practice?
Agreed. But even "not calling input and output transforms" is incorrect. JSON, just like XML or the next thing we will come up with, has to be parsed to be any use. This may happen under the hood but this is still happening.
I guess what mikescar finds attractive is the illusion that things are "integrated" and talking to each other in a format that doesn't look like one (it seems to be part of the programming language).
"""This rant sounds very similar to "NoSQL DBs will never reach the competence and performance of the RDBMS"."""
Well, performance wise NoSQL DBs are faster. In anybody doubting that?
As for the competence part, well SQL DBs (by which I don't mean MySQL) are based on a little something called Relational Algebra. Which is math. Which is a (formally) proven and coherent set of methods for data representation and querying.
You have solved a problem that didn't exist -- XML and HTML were both reasonable linguafrancas prior to JSON's invention.
JavaScript as a server-side langauge is not a good thing; JavaScript is not a good systems language. We've already had an era of a poor systems language (PHP) being predominant in the web application space, and the conclusion was that there are better languages which can more effectively represent both general systems tasks, and specialized web tasks.
NoSQL databases will never be relational DBs because they explicitly eschew the relational algebra that powers the latter. Similarly, Node isn't a serious server-side solution explicitly because of its reliance on JavaScript.
Finally, I should point out that JSON isn't a subset of JavaScript. This means that you can't exec it as JavaScript in all cases, and even if you could, exec/eval is massively dangerous and should be avoided. This means that you're parsing JSON, which means that you no longer have an advantage over other languages -- Perl, Python, and Ruby all have very strong JSON support. (Python even has it in its standard library now.)
- XML and HTML are good ways to structure data...sometimes. Other times, they're godawful. Especially if you're trying to pass data from one piece of code to another piece of code in order to do RPC-like things (server->client, for example). There's a reason that JSON is popular, and it's not because "it's the cool thing to do".
- JSON is a strict subset of Javascript syntax. You can always eval() a JSON string to convert it (not that you should). Many browsers support native JSON parsing now, so it's also very fast. I'm not sure what the downside is there.
JSON isn't a strict subset of JS. Moreover, no, you should never eval() things which are untrusted. Do you really trust everything the browser tells you? No? Then why trust JSON?
I'm not anti-JSON, I'm anti-JS. Browsers don't support other languages (except for VB, which bites, and Fx nightly support for Python, which I wish would become more widespread) so there's no choice in a browser. On the server side, though, you have a chance to use real languages, so you really should.
Oh, and also, you do know that XML-RPC, bless its ill-specified heart, is still around, right? There's a whole world of enterprise that isn't prepared to accept JSON-RPC.
s/PHP/JavaScript/g in any other conversation about PHP; the same reasons all apply, including ease of learning curve, deployment inertia, etc. There's a massive amount of parallel community and language development between PHP and JS, and I feel that it's worth pointing out.
"JSON is a subset of the object literal notation of JavaScript. Since JSON is a subset of JavaScript, it can be used in the language with no muss or fuss."
http://www.json.org/js.html
I agree that js does support the async paradigm for the reason you mentioned; however, at the risk of sounding like I'm speaking for the op js would not be my first choice for system or server side programming. The simple reason being that javascript's behavior is often near inexplicable, many examples can be found here: http://wtfjs.com. I'm tolerant of that strangeness while manipulating the DOM but really only because there are no other choices.
Every language has it's own WTFs. Many of the ones in Javascript are shared with Ruby, Python and other interpreted languages. They hardly bite anyone in a real project.
If by real you mean yours fine; however, your projects are not everyone's. If you'd like you could respond with specific cases you've used javascript for system or server level programming.
Your friend might not be nodejs, but it might be .... Javascript. One way to speed up data processing on the server is to avoid processing it as much as possible and delegate such processing to the client side. Hence, Javascript is your friend there.
His biggest problem seems to be the "community". There's certainly some people doing projects in node who would probably benefit from doing it with something else. But to judge the framework by some "community" is silly. The node community seems friendly and helpful and have created a large library to help do things node is good at.
"The content server should not need to do hardly any IO. Why would an HTML content server need to write to the filesystem?"
This just shows a blatant lack of knowledge about what constitues IO. FYI, network is IO, writing to console is IO, logging is IO. The point of an evented system like node (and others based around the 'select' or 'epoll' type calls is that you can use one thread to do other things when you are waiting for the kernel to tell you your socket is ready.
Yes, I too get frustrated when 'front-end' people think they are systems engineers or super server coders, but that doesn't mean I am going to write a blog post that goes nowhere about it and completely misses the point of an evented system like this.