> Node is a tool for running Javascript on the server. Your desire to use it will stem entirely upon your desire to write javascript to perform server side tasks.
Now that's often what people think of Node.js, but that's not really why Node.js is interesting. It's not just "JavaScript on the browser".
Instead, you should think of Node.js more like a JavaScript binding to `libuv`, which is the C library that provides the event-driven I/O core (event loop / queue). (An example for a `libuv` binding in another language, Lua would be `luv` [1].)
Reasons why JavaScript was picked for Node.js: 1) It already dealt with events due to its usage in browsers and 2) a fast existing JIT runtime, V8.
To answer the original question: You might want to use Node.js if your problem is a good fit for the Reactor pattern [2]. For example, scalable network services that "mediate" between a lot of (async) I/O. Not number crunching. Nginx uses the same core concept (Reactor).
I agree, the crawling / indexing problems you describe are definitely true for Linked Data. But there are still other use cases for semantic web technology.
> The use case many people have is that they want to use and API to get some particular bit of data out and that's it.
In theory, that's what SPARQL and SPARQL endpoints are for. Plus you get things like federated queries and an open data model (RDF), that allows to combine multiple data sources without "wrapping" schemas.
But well, this is kind of utopia and yes, I doubt it will ever be "a thing".
> That said, C++/Java-style class-based o.o. is no panacea either and having both things in a single language is just crazy.
Actually, there is just prototypal inheritance. The whole `new` operator thing (as well as ECMAScript 6 classes) is just syntactic sugar over prototypal inheritance.
But yeah, it's crazy that this had to be put in just to attract users (in the 90s, to make it look more like Java; along with method names etc).
I'm surprised no one mentioned single page web applications -- that's where I see JavaScript's strength at the moment, compared to the other server-side frameworks you named.
JavaScript: While Node.js is awesome, it is definitely not the best choice for everything -- not everyone needs its features (despite the hype). But if you want to build web apps on the client side, you have to either use JavaScript, or compile to JavaScript.
A client side web app however still needs a back end API. The good thing is, if your front end runs (mostly) on the client side, you can pick almost any language / framework for the back end you want (e.g. Python).
> I am a die hard Python lover, but I do not know what do to at this situation.
Now if you don't know Django yet, my suggestion would be to learn both Django (given your Pyhton background) and one of the client side JavaScript frameworks, e.g. Ember.js, Angular.js, React.js or maybe Meteor (depending on your use case). (And if you learned both Ember.js and Django, you probably get an idea of what Ruby on Rails is like …).
Now that's often what people think of Node.js, but that's not really why Node.js is interesting. It's not just "JavaScript on the browser".
Instead, you should think of Node.js more like a JavaScript binding to `libuv`, which is the C library that provides the event-driven I/O core (event loop / queue). (An example for a `libuv` binding in another language, Lua would be `luv` [1].)
Reasons why JavaScript was picked for Node.js: 1) It already dealt with events due to its usage in browsers and 2) a fast existing JIT runtime, V8.
To answer the original question: You might want to use Node.js if your problem is a good fit for the Reactor pattern [2]. For example, scalable network services that "mediate" between a lot of (async) I/O. Not number crunching. Nginx uses the same core concept (Reactor).
[1]: https://github.com/luvit/luv
[2]: https://en.wikipedia.org/wiki/Reactor_pattern