It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 9 years ago.
Ok this is probably a little blunt and to the point, but what is the point/need for Node.js
I've noticed it mainly through CloudFoundry but just not too sure what its supposed to be doing. However I am guessing its probably something pretty big as why else would VMWare be supporting it.
Thanks in advance.
It's an...
Efficient and 100% event driven IO framework,
flexible enough to use the best underlying OS features it can find,
presenting an API in a high-level programming language (the same language your client-side will most-likely use),
implemented on top of the best available intepreting engine for that language, and
supporting more and more third party libraries with each passing day.
Effecient in server side api, avoid using for CPU intensive operation
:)
Node.js does IO right. It's asynchronous and non-blocking and the beauty of using js is that it does not have a standard blocking IO.
It's fast (v8 is a beast), it scales well, It's got a vibrant community and it's popular.
There are lots of wonderful libraries that run on node like now and socket.io.
It excels at real time communication and highly concurrent websites.
It also has the added bonus of less code duplication. You can write the same MVC code on the client as the server and easily support non-js users.
Further reads:
Usages of Node.js - What obstacles is it aiming to provide a ramp for?
Why and when to use Node.js?
What so different about Node.js's event-driven? Can't we do that in ASP.Net's HttpAsyncHandler?
What is Node.js?
Node.js is an event based,
asynchronous I/O framework that uses
Google's V8 JavaScript engine. Node.js
is commonly used for heavy
client-server JavaScript applications.
The node.js tag has some more background information to point you in the right direction: https://stackoverflow.com/tags/node.js/info
Node leverages Javascript's first class functions to allow you to program the server in a dynamic scripting language while getting very competitive performance.
Node isn't as fast as Haskell, Erlang or Go. But it is competitive with Java, and it outperforms Ruby, Python and PHP.
Haskell, Erlang, Go, Java, Ruby, and Python all have evented IO webframeworks, but they also have blocking libraries to serve as pitfalls.
Despite it's warts, Javascript is the lingua franca of the web and since browsers are evented, not only is Javascript built for evented style programming, most web developers are used to writing evented Javascript.
Also check out this register article: http://www.theregister.co.uk/2011/03/01/the_rise_and_rise_of_node_dot_js/
This post might help:
Why Developers Should Pay Attention to Node.js
Related
Kotlin vs Node JS for REST Api's
I couldn't find any proper explanation regarding the differences b/w Kotlin and Node JS for REST APIs
Which is better in performance wise?
Let me set the context. Its Kotlin/JVM vs JS/Node.js. We cannot blindly say that this language is better. In general Kotlin is supposed to be faster since it compiled language compared to JS which is interpreted language.
Irrespective of the language used, we will discuss on the API architecture. Serving the APIs can be implemented in either blocking or non-blocking way (I am not going to explain about what it is). Traditionally before a few of years Java/Kotlin with Spring have been using the blocking architecture which delivered performance X. On a contrary, Node.js is based on non-blocking architecture which gave us better performance than the blocking architecture and architecture style is the only reason why Node.js performed better. Later Spring released a newer version of the framework to support non-blocking architecture. The non-blocking style is called as Reactive programming/Spring Webflux.
So now both of the languages support non-blocking architecture. In terms of raw language performance, Kotlin will be better since its compiled language. Also in theory interpreted languages are supposed to be slower. But we cannot say which is better without any testing.
Personally I am fan of Java/Spring because of OOPS and later at one point I started using TS/Node.js. TS eliminates most of the runtime issues with its type checking. But still we cannot compare it with the type system available in Java/Kotlin. As a language I feel Java/Kotlin is superior and one thing I like most in JavaScript is handling objects/JSON. Checkout "Kotlin for JavaScript" as well which lets you write in Kotlin and transpile to JS. Ignore this "Kotlin for JavaScript" feature, I am planning to try Kotlin/Spring in non-blocking architecture for my future projects. If you have usecases with WebSockets, I think Node.js will perform better and I am not sure If there are any libraries in Java/Kotlin since I havn't explored it.
One disadvantage in non-blocking style is that I need to pass the login context object to almost all the methods in the project. In blocking architecture we will add the login context information in thread local so that we can access it anywhere until the request is completed.
I am sure that I did not answer your question completely. But I hope that the information what I have give is useful.
Correct me If I am wrong in any of the aspects.
Unfortunately JavaScript is the only programming language I have experience with. So naturally my gut instinct is to wonder why you wouldn't use write a programming language (in this case Node) in JavaScript?
Why C? What benefits are you getting?
C is a low-level language suited to systems programming--i.e. the construction of operating systems, database engines, and other code that must be highly efficient (in both time and space used to complete a given task). C is "close to the bare metal," compiling every effectively into machine code and CPU instructions.
You can certainly write compilers and middleware in higher-level languages than C. While there can be a speed-of-development advantage for doing so, they will almost always run slower and consume far more memory. Many languages (Python, PHP, JavaScript, ...) are implemented in C (or C++) as a result.
If you wanted to implement something like Node in another language, you would probably best look to another language that majors on systems programming, such as C++, C#, Rust, D, ...
Node.js is built on chrome's V8 engine(which allows it to execute javascript), so you should ask that why was v8 written in c++?
This answer on Quora might help you for the 2nd question
Node js is created using JavaScript language which can be run in the desktop to create application. Node js is also written in C++ because when the web server needs access to internal system functionality such as networking.
C++ has many features that let it directly interact with the OS directly
JavaScript does not! So it has to work with C++ to control these computer features.
Referring to client and server side architecture example . (Here Mick is the client) Mick's Mac/Windows needs access to a website which is hosted in the internet somewhere in a server which basically a computer.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I'm feeling a bit confused, there are so many frameworks out there for Node.js related 'stuff'. Would someone be able to give me an overview of What are the differences between Backbone.js and Node.js? And which is best? Thanks in advance.
I am quoting it from a couple of sources here:
Firstly, to quote from the stack overflow question here:
Most of the things you listed are related only because they are
written in or otherwise use JavaScript. Comparing them is much like
comparing apples to oranges. It's like asking what the difference is
between a Toyota Camry and a V6 engine. They are related, but do
different things.
Node
Also known as Node.js, Node is the JavaScript environment on which we
run our server-side JavaScript code. It is based on the V8 JavaScript
engine. All of the JavaScript code you write, or install and run
from packages from NPM, GitHub, etc. is executed by the Node runtime
environment.
Backbone
Backbone can be likened to as a Model-View-Controller
framework for JavaScript. I believe it was originally written for the
browser; it helps keep your client-side JavaScript clean by
implementing most common MVC patterns (as well as a couple other
things), allowing you to more easily connect your client-side
JavaScript to your server-side code.
Also, this is from an answer for the same question on Quora. Credit goes to Drew Harry:
They're almost completely unrelated. Traditionally, Backbone.js is a
client library and Node.js is a way to write server-side applications
in Javascript. Backbone aims to be a model + view system for binding
data models with DOM elements that represent that model visually in a
web page. Backbone also provides Collections of Models, as well as a
bunch of utility functions for synchronizing those models with their
server-side representations.
Node.js is just the v8 Javascript run-time environment packaged with a
standard library to do useful server-side things with Javascript.
There are lots of packages designed for Node (check out npm for ways
to easily install those packages, Backbone included) that extend it to
do all sorts of interesting things. It's possible to use Backbone.js
with Node.js, but Backbone isn't particularly designed with use on the
server in mind.
Go and upvote the above answer(s) if you find the material helpful.
Pretty much the only things those two have in common is that they're Javascript based and have a lot of hype surrounding them (not undeserved though).
node.js is a framework for Javascript server applications. It includes the V8 Javascript engine developed for Chrome. It's asynchronous and event-driven, so it's ideal for serving large numbers of small requests.
backbone.js is a framework for client-side web applications, specifically for so-called "single page web applications" where only a single HTML page is sent to the browser at the beginning, and every interaction thereafter is handled by AJAX requests and Javascript logic that transforms the page.
This means that the two can also work effectively together: an app implemented using backbone.js for the frontend could have its AJAX requests handled by a server part using node.js - a rather popular combination since it allows you to have an entire web app using only Javascript.
Backbone.js is a javascript library, similar to jQuery or YUI but addressing different needs.
Node.js is a javascript interpreter, similar to Internet Explorer or Firefox or Safari but addressing different needs.
I don't know much about backbone.js but I believe you can use it with Node.js since it uses regular javascript. You may need a DOM emulation layer for the DOM related stuff though.
Additional answer:
A bit of googling reveals that there are people out there using Backbone on Node.js. The advantage of this is obviously you'll be able to use the same framework and reuse code on both client and server.
See: http://nerds.airbnb.com/weve-launched-our-first-nodejs-app-to-product
More additional answer:
With regards to semantics I see that some people disagree what some terms in computing means. While the terms are loosely used, and while they are somewhat interchangeable, they do have fairly well defined meanings.
In general, an interpreter is an executable, that is, a program that takes as input some data and executes it as a program. V8 is not this. It cannot take javascript by itself and run it. It needs to be compiled into another program, an interpreter in order to run javascript.
V8 does ship with example code to build an interpreter though. That interpreter shipped with V8 is called V8-shell.
An engine is a library that implements an interpreter. This is exactly what V8 is.
The two terms above are somewhat interchangeable because the word "interpreter" can also validly be used in place of "engine" to describe what a library implements. But that usage of the word is similar to the usage of "MVC framework" or "UI toolkit" in that it is used as an adjective. So it is correct to say that an "interpreter" is a kind of library.
But the word was originally used to mean the binary that executes a programming language. When used this way one uses it as a noun as it refers to something on the file system. Used this way is similar to the usage of the "compiler". For example one would call clang a compiler in this sense and one would call llvm, the library used by clang, a compiler in the previous sense.
Lets take a look at something that is not javascript as an example:
tcl is a programming language
tcl is also the library that implements the interpreter for tcl. In other words the engine.
tclsh is the tcl interpreter
Let's take a look at another example:
ruby is a programming language
RubyC is one of the many engines for ruby
ruby is the interpreter that uses RubyC
Nobody uses the word "framework" when referring to the binary executable interpreter for the above two languages. It just sounds silly.
But wait you say, Node.js refers to more than just node.exe. It truly provides a bunch of additional features that can be used as a good foundation to write great programs. In other words a framework.
Well, yes. That being true does not make the usage of the word "interpreter" to refer to node.exe automatically invalid. Just as using the word "earth" to refer to the planet does not make using the word to refer to soil automatically invalid.
Besides, those extra functionality? That's true for tcl and ruby as well. It's also true for C. Those extra functionality like fs and http on Node.js are traditionally called standard library. While the Node.js project calls it a framework that's their choice. Almost nobody else calls their interpreter + standard library a framework. PHP for example is distributed exactly like Node.js with a bunch of very high level standard libraries but nobody would call PHP a framework. It's also a bit silly when people write actual frameworks on top of node - frameworks for a framework. But I'm not going to say they are wrong because they choose to call it that. It's just their way to describe what they've created. More power to them.
What I am saying is that people who say that node.js is not an interpreter is ignoring the usage of the word throughout the history of computing. I don't know. Coming from an asian background it's natural to me to assume that everything belongs to multiple categories. Maybe it's a western idea that things belong strictly to specific categories that I don't quite get.
So here are the facts:
Node.js is not simply a javascript library. You need node.exe to use the standard libraries that node ships with.
Backbone.js is on the other hand a standard javascript library. It is not an executable.
Node.js is the only example where an interpreter + library is called a framework so far. All other examples of framework I know of in programming refer to libraries that implement a design pattern.
Calling something "B" does not automatically make calling it "A" invalid.
One final thing: web browsers also come with a very large high level standard library for javascript. It's called the DOM (there's also a bunch of other stuff like Math and XMLHttpRequest but the DOM is the biggest). Accordingly one should call Internet Explorer and Firefox javascript frameworks but nobody does that.
Node.js :
Javascript for backend side. ( like : php, ruby on rails, python, etc. )
Backbone.js :
Javascript for frontend side ( running on the browser of your client )
backbone.js also uses jquery , more frameworks of javascript for client side are :
1. mootools
2. ExtJS
3. dojo
4. prototype
and many more ...
Both are javascript related but totally different.
Node is a interpreter/platform to execute javascript code in the server such as JDK or Ruby. To put it simple, you need NodeJS installed to interpret Backbone based script on the server.
When it comes to server side MVC., Geddy, RailwayJS, Express etc., considered to be serving the purpose better than Backbone.
Whereas Backbone is a champion MVC framework in the client side.
Node.js is a server-side platform designated for building network applications. It is built on Google's V8 Javascript Engine and uses asynchronous event-driven approach for building applications. Backbone.js is a simply javascript client library that makes it easier to create and maintain client-side code and comply with MVC pattern. Hence, they cannot be compared.
Backbone.js has a lot of alternatives that use slightly different approach to achieve the same goal. Most known are: knockout, ember.js and others. And it also can be plugged into node.js application.
Our new project will get a lot of concurrent requests. I don't have a lot of experience with this. Any suggestions? I've looked at NodeJS, Twisted, EventMachine & Tornado but I don't have any way to measure how suitable they will be.
Any suggestions?
Ask yourself the following questions (at least) and then decide:
What language do I (or/and my colleagues) know? If you know Python you could choose Twisted, if you know Ruby you can choose EventMachine or if you are really good with JavaScript you could choose Node.js. (only Erlang wouldn't have an advantage here)
Do I want to use a language construct (Erlang, Node.js) or a library (Twisted, EventMachine)?
Do I need a lot of resources, community support, books etc? Check out for yourself how big are their channels on IRC, you'll make an idea. (I may be biased, but I see tons of people on the Node.js channels and they are really helpful)
How mature do you want the framework to be? (Node for example has 2 years, Erlang has been officially released in `98, etc)
What companies/products are using what async frameworks? (for example CouchDB has been built with Erlang, Node.js is used by Github, Linkedin and others, EventMachine is used by PostRank, 37 signals etc)
The suitability of specific non-blocking framework may be dependent on certain aspects, such as:
Preferred language/platform - someone can be versed in specific language which might speed up the development. Also finding a skilled people might be a problem.
Availability of non-blocking libraries for your framework - for example most of the node.js modules are by default non-blocking compared to other frameworks where you might run into a problem of finding a non-blocing version of library which offers desired functionality.
Documentation and community support is essential.
As others say - you should go with the one that has the non-blocking libraries (e.g. DB drivers) you need and, if possible, uses the language your team knows. Popularity may also be an advantage.
If you're programming in Python, gevent might also be a good option. There is even a Socket.IO implementation.
Develop a metric to measure suitability, then use that metric. How can anyone here tell you which one is the most suitable if you don't provide any basis for evaluation?
Wait, scratch that. Twisted is the most suitable for everything, always, no matter what.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I see a lot of potential of doing Node.JS-like development on the JVM, with its heavily optimized runtime.
At this moment in time, I see three projects that aim to bring a node.js-like style of development to the JVM:
Apache Deft
Webbit
Vert.x (formerly Node.x)
Should these projects team up?
What are their relative strengths and weaknesses?
Which project has the most momentum?
Disclosure - I'm the vert.x guy :)
Vert.x is a fully fledged platform for building polyglot, scalable, asynchronous web-enabled applications.
It is heavily inspired from node.js but goes further than node.js and provides a distributed event bus which reaches from the server right into client side JavaScript thus creating a super simple model for so-called "real-time' web applications. We also ship with a mailer and a mongodb persistor. There's a full tutorial here http://vertx.io/tutorials.html
But the probably the main thing that sets it apart from other async frameworks is it's polyglot nature. The same (or similar) API is available in Java, Ruby, JavaScript and Groovy (with Clojure, Python and Scala support to follow).
Vert.x really takes advantage of true multi-threading on the JVM to provide scalability and performance than node.js cannot touch.
If you don't want the whole platform. Vert.x can also be used as a library for providing HTTP, TCP, websockets, sockjs, eventbus, etc support in your Java or Groovy application.
For more info pls see the website http://vertx.io
Disclaimer: I'm the Webbit guy
There is definitely a lot of overlap between the 3 projects. When I built Webbit I was not aware of the other two - had I been, it may well not exist, or I may have spent my time contributing to the others.
I can talk a bit about Webbit...
It is not a multi-purpose evented IO framework. Or network protocol toolkit. Or filesystem abstraction. Webbit only does a small fraction of what the others do.
Webbit is also not a full-featured web-framework. Like Node.JS or the Servlet API, it provides the core building blocks for building higher level frameworks, but leaves this to external projects (like Webbit-EasyRemote or Webbit-REST).
What Webbit focuses on is being a simple, embeddable, non-blocking, HTTP and WebSocket server.
Because it takes the 'do one thing and do it well' approach, it has also been designed to be used in conjunction with other libraries. It allows external java.util.concurrent.Executors to be passed in and avoids singleton thread contexts, making it particularly well suited for integrating with Actor style concurrency libraries such as Jetlang and HeySync.
Vert.x and Deft bring complete frameworks for out-of-the-box Node style development. Webbit is just a small tool that can help HTTP/WebSocket enabled your application. There is a need for both of these and it really depends on your needs (and personal style) as to which is more appropriate.
Disclaimer: I'm an Apache Deft committer.
Apache Deft has more in common with tornado and twisted than to node.js, whereas vert.x is heavily influenced by node.js. Tim Fox from wmware is doing a great job with vert.x and the development speed is really impressive.
vert.x has a couple of examples available.
Some Apache Deft examples.
Apache Deft also has a bigger "demo application" that should give you an idea of how you could use the framework for other things than http.
AFAIK webbit is currently aiming to be a "WebSocket and HTTP server".
If they should team up? Absolutely :)