I know that node.js is said to be "event-driven I/O" server-side javascript hosted on V8 Javascript engine. I visited the node.js website, and then read the wikipedia entry, but cant quite get the whole idea of where to use it and how it will be useful. "Event-driven I-O"? "V8 Javascript engine"? In some context though, I see that using "server-side" javascript as a little overkill..I take for instance this piece of code in the wikipedia entry of node.js:
var http = require('http');
http.createServer(function (request, response) {
response.writeHead(200, {'Content-Type': 'text/plain'});
response.end('Hello World\n');
}).listen(8000);
console.log('Server running at http://127.0.0.1:8000/');
I have been thinking, is there really a significant purpose in running a server that particularly serves javascript files that are executed in the front-end part of the application?
I also forked the node.js repo in github to learn more about how it works, and it turns out that some of its modules are written in C++. So it is not a javascript after all then?
Can somebody give me a clear explanation about all this? Sorry if the question is not clear or something, I am just a beginner. Will appreciate any input/suggestions. thanks
The node.js server is, in simple terms, a replacement for something like the Apache web server - but it is largely written in JavaScript which runs on the server (executed by the V8 engine) rather than on the client side. It can be extended with 'native code' modules (written in e.g. C++) wrapped in a JavaScript interface to add functionality, but AFAIK most node.js modules are pure JavaScript.
"Event driven I/O" is just a term that describes the normal asynchronous callback mechanisms you're used to in JavaScript. In node.js you supply callbacks for all sorts of things, and your function is called when the relevant event occurs.
Depending on how many modules you add, a node.js server is relatively lightweight compared to something like Apache, and in some ways a lot simpler.
The two main advantages to node.js I see are:
It allows you to write both the server-side and client-side parts of a web application in the same language. In some cases you can use the same code on both sides.
It makes server-side coding accessible to all those web developers out there that know JavaScript without having to learn a more common server-side language like PHP or Java.
Here's an article I just came across that might also shed some light: What is Node.js?
While I can't add much to what #sje said, I will repeat that blog link he shared, as that is the best resource that I've found to explain nodejs quickly:
http://radar.oreilly.com/2011/07/what-is-node.html
Also note that it's from OReilly, who most of us know as being the publisher of the best references for programmers on the market in general ;)
I have been thinking, is there really a significant purpose in running a server that particularly serves javascript files that are executed in the front-end part of the application?
This is totally wrong. This is the most wrong assumption about node you could make. Node runs the javascript on the server much as ruby or php or asp.net code is run. The fact that the browser can also run javascript has no bearing on node.
Granted, you can share modules between the server and the client (for instance, validation routines for form data) but by and large the codebases are different as they are intended for different things.
I also forked the node.js repo in github to learn more about how it works, and it turns out that some of its modules are written in C++. So it is not a javascript after all then?
Yes, node is a server that interprets javascript using the V8 engine. It has to be written in something. I'll give you a comparison: Microsoft .NET code is mostly written in .NET on top of .NET, but the main code that actually does the work, the runtime (the CLR as most people refer to it) that manages the managed-code, that code is written in C. The same thing with node. Yes, most of it (as you saw) is written in javascript, but the core libraries that run everything else are written in C.
Can somebody give me a clear explanation about all this? Sorry if the question is not clear or something, I am just a beginner. Will appreciate any input/suggestions. thanks
I hope this helped clear it up in part. There's a lot to cover, and without going into evented-io (which involves understanding processes and threads and io access and a lot of other stuff) this is pretty much the basic high-level answer to this question. I invite you to the nodejs room on the chat server here if you like, for more random discussions that are fluid. https://chat.stackoverflow.com/rooms/642/node-js
As to the first question you asked:
Where does it fit in?
The same place ruby and php and perl and python and asp.net do. On the server, generating code that the client receives.
I haven't seen anyone give a simple answer to this yet.
Node.js is:
the v8 javascript engine
an event loop
some c++ bindings, among other things, that give v8 IO capabilities (both network and file IO)
It's important to note, Node doesn't necessarily have to be used for web development either. It's purpose is, "evented IO".
Related
Can I write my web-site only in JavaScript being sure that my code is concealed from anyone? In this respect, is Node.js, like Apache, can be given access to through an Internet-provider?
The answer to both of your questions is yes.
Node.js can completely replace Apache (assuming you are willing to re-write all of your PHP as JavaScript). If you have your Apache running in reverse-proxy mode between your server and client, you can even handle some requests in Node.JS while handing others in PHP. This will allow you to maintain original functionality while changing the code out, and also allow PHP to handle more mundane tasks.
While you cannot prevent raw JavaScript from being read through any means of obfuscation, you can prevent people from reading your code by note making use of standard JavaScript at all. You can use a NativeExtension for Node to add an extension handler for encrypted JavaScript files:
require.extensions[".jse"] = function (m) {
m.exports = MyNativeExtension.decrypt(fs.readFileSync(m.filename));
};
require("YourCode.jse");
This will convert your JavaScript code to a .jse, which you would then package for production. Considering the encryption is done inside the native extension, the encryption key wouldn't be revealed.
Hope this helps! :)
Yes, you definitely can. It may, however, take a while to transition existing code, and if this is for a corporate institution, you'll have to ask your coworkers and your boss/supervisor. Good luck, and remember, always document your code in JavaScript (no types) all languages.
NodeJS is much faster: http://www.hostingadvice.com/blog/comparing-node-js-vs-php-performance/
Many more libraries: http://npmjs.org
Only need one language for everything
Comparing PHP with another technology like Node.js which is meant for an entirely different type of task, comparer must mention the difference of use-case/context in which one is suitable over others.
Let's talk about in terms of a different area of execution because we can not Disgrace any of them and both have its own priority.
If you talk about in terms of Application Domain.
PHP :
CMS (Content Management Systems) like WordPress, Drupal also use PHP which makes it possible to be used in creating blogs, websites, e-commerce sites, etc.
Used in developing CPU-intensive applications like meteorology applications and scientific applications.
should be used in applications in which the client does not have to interact with the server again and again
PHP 7 is based on the PHPNG engine that speeds up PHP applications more than the previous PHP interpreter (Zend Engine 2.0). Thanks to PHPNG, your apps see up to the 2x faster performance and 50% better memory consumption than PHP 5.6.
NodeJs:
Nodejs is ideal for developing highly scalable server-side solutions because of its non-blocking I/O, and event-driven model.
Used massively in Real-time applications like chat applications, blogs, video streaming applications.
Used in developing single-page applications like resume portfolios, individual websites.
Node.js should be used for the applications which require a lot of interaction between client and server.
For some tasks, Node.js may be faster than the “standard” web server with PHP because it runs as a single thread with non-blocking IO for each connection, hence there is no memory overrun. Due to this, Node.js is useful when there is a need to process data in real-time (chats, games, video, big data streams without logic)
PHP is Still alive and he has learned its lessons from Node.JS
ReactPHP enables developers to write PHP-based socket server to process requests constantly as well as Node.js does it (yes, Node.js is faster, but the fact is that PHP can also do it). The same thing with Workers (the classes responsible for running asynchronous jobs and synchronizing their results) or Amp (libraries that are used for writing non-blocking asynchronous code). Hence, it is easy to create long-running processes using PHP. Additionally, there are a lot of tools for supporting and managing these processes (such as supervisord).
So, the same tasks may be performed either with PHP or with Node.js. The question “what tool to use” is a question of personal preferences. you can use Node.js for tasks involving big data flows and PHP for tasks involving complex logic, high-load tasks, for dealing with external utilities, applications, and OS.
From the scalability perspective, there are no big differences between PHP and Node.js, it is more important to consider the project’s architecture.
Dayle Rees (a Laravel Framework contributor and developer): For a long time PHP was the butt of many language jokes, but I honestly feel that it’s becoming not only a popular language but a powerful one. PHP7 is great. The speed boost is one thing, but having optional support for full type hinting is a game changer. We’ve also got modern tools like Laravel and Composer, breathing new life into the language and its supporting community. With this in mind, I think it’s unlikely that Laravel will move from PHP. I think it’s more likely to gain further integration with front-end tools to provide a complete application building platform. That’s where I see it heading in terms of future expansion. I’m sure the Node will continue to excel when dealing with microservices and threaded applications.
The most important and most awaited News from PHP is, PHP is scheduled to receive a Just In Time (JIT) compiler in its next major version PHP-8 (most probably in sep-2021).This is going to boom the php and it breaks all his limitation due to JIT.
Wrap up
To wrap up Both have some pros, both have some cons but the amazing thing is both are created by intellects to make the web development better. While selecting the technology the question shouldn’t be which one is better but which one can serve your project needs in a better way. Understanding your project and business logic can give you a clear idea about selecting the right technology for your project.Moreover, one more important thing to consider is the skills and proficiency of the developers using the technology, how they use them and apply to the project.
I am working on app where I need to pass messages between a C++ application and a Javascript web app.
Certainly I could write sockets code myself in either language and I have done this in the past when necessary.
What I would really like is a higher-level message posting or message queueing API that does a lot of the work for me. Does anyone know of such an API?
I have looked at ICE, and it doesn't appear to have Javascript bindings. I have also looked at Boost message queue, but it only caters for the C++ side of things. If necessary I might roll my own Javascript bindings for either of these technologies.
UPDATE: Sorry should have mentioned this before, I want to run this in a browser.
To give a more complete story what I want is a simple browser-based app that is used to configure and display logging for a C++ application.
I know there are other ways of doing this, but I am specifically interested in a high-level library in both C++ and browser-based Javascript that builds a message queue ontop of the sockets API (if there isn't one then I might consider implementing it myself and writing up a code project article).
ALSO: I'm not bothered about portability in terms of the web browser. Eg if there is a high-level IPC Javascript library that only works in Chrome, I'll be happy with that.
With JavaScript I assume that you are running it in a browser? In this case your C++ application needs to provide a webserver and some kind of JSON based webservice that you can call. On the JavaScript side you just use AJAX to communicate with that webservice.
An alternative would be websockets which might be a little harder to implement on the C++ side though.
To simply answer your question: No, there is no IPC implemented in ECMAscript out of the box.
But you actually answered you question already. If you try to communicate with Javascript that runs in a browser, you indeed should use (web-)sockets connections to pipe date in either direction. Of course you could write a simple HTTP server in C++, but I guess that is overkill and does not have the capabilitys of bi-directional sockets.
It's still some work to implement a web-socket connection in C++ from the scratch (the specs were in flux for a long time), but I guess there are some librarys out already.
If you're trying to communicate with node.js, this is an almost trivial task using real sockets/pipes.
I have found a solution that meets my needs. It isn't exactly perfect but I think it works well enough.
Some people suggested using HTTP and ajax. That turned out to be a useful idea and after some prototyping I think it solves my rather basic needs.
To be more specific I am using the Mongoose HTTP server embedded in my C++ application and I am using the jQuery ajax function to pull data from the server. The jQuery client polls the server continously for new data, not particularly efficient but I think it will do the job good enough for me.
Once my implementation is complete I'll write an article explaining how to do this in detail and then I'll update this answer.
You could try DBus, it has very simple mechanism to define, query and use interfaces, and there are some components for XPCOM and webkit based browsers (for example http://sandbox.movial.com/wiki/index.php/Browser_DBus_Bridge and http://code.google.com/p/v8-dbus/). Also DBus is opensource and cross platform.
For a server side or non-browser implementation how about named pipes?
Yes it's vintage technology and the usage depends which OS you use, but as long as your server side js environment has ability to read and write files it may work, and it fits the description 'high-level' inter-process communication.
The most common theme I read about why to use node.js is for high scalability due to it's evented, non-blocking I/O model. I'm trying to understand other non-scalability uses cases (and aside from being used as a general server-side javascript engine).
Does node.js have other use cases if scalability isn't a concern of mine?
If yes to #1, what are they?
Is node.js usage appropriate for any particular type of application architectures? E.g. similar to how some key/value (nosql - ugh I hate that term) databases are useful other than for scalability reasons.
My reason for trying out node is the fact that it is incredibly easy to send JSON data between the server and the client for ajax requests.
If you use something like MongoDB, which stores data as JSON object too, you never have to worry about translating or parsing your data.
If your site uses a lot of ajax, and you're sending your data as JSON objects (rather than XML or plain text) then node.js will save you a fair bit of effort.
I think this blog posts sums it up quite well:
http://debuggable.com/posts/understanding-node-js:4bd98440-45e4-4a9a-8ef7-0f7ecbdd56cb
In short (pro node.js):
Speed
Javascript (especially if you know it already)
Efficiency
node.js is really great. Give it a try! :)
I can think of one reason, but its not very deep. Basically, If you are developing an RIA, your entire stack can be javascript. That might have some value.
But Ill question my own answer, namely the thought is, even if it makes the server side code more accessible to client side developers, they still need to understand how their server stack works. So there is still some learning to.
To be accurate, I think the general server-side JavaScript engine in your question would be V8, while according to its creator Node was built for "scripting network programs."
Based on many of his comments I don't believe he views it as broadly as many of us do, but recognizes where it can go. [I can't speak for anyone else--that's just my interpretation based on the writings and presentations I've seen.]
So it approaches things from a somewhat lower level, makes HTTP a first-class citizen and just happens to be really cool, which I think makes it enough of a "use case" for most of us. ;)
It does have a learning curve and isn't the most stable platform to build on due to its rapid development. I believe time will tell where it's most useful.
For now people are using it for "real-time" apps due to its lightweight, asynchronous nature, as well as general Web development, though IMO its sweet spot remains with its originally stated purpose.
What I like about node.js aside from non-blocking I/O model, scalability and all that "primary reasons" stuff:
Lightweight nature of it's framework. Basics are easy to learn.
Developer community building tons of useful modules and libraries on github which are expanding node.js lightweight core and it's capabilities.
It's really easy and fast to build server side and real-time systems (for example http or socket based) without the knowledge of complex libraries.
I like to use NodeJS to write testing harness because you can write a stub/server/client really quickly. And you can drive your application, with ease. I can easily script a third party back-end server to do performance testing on my application. I also use it to drive my application. I can perform complex client server scenarios using setTimout to cause multiple events to be trigger based on any logic I want and test them at scale.
I'm currently looking for a new web stack to build a hobby project on and would like it to be powered by JavaScript. I've had a quick look at Nitro, NarwhalJS etc. but was wondering if anyone had any solid recommendations or experience of an entire end-to-end javascript/json architecture ( jquery, middleware, standard libraries, db etc.) that they could share.
I'd prefer it to be a stack that you think is going to grow and is actively being looked after, documentation, community of nice like-minded individuals etc.
Thanks in advance.
Caveat: This answer somewhat fails to meet your basic requirement of personal experience with the resources listed. :-)
Off-the-cuff, there's Jaxer from Aptana and Chrome Server (which, despite the name, isn't related to Google Chrome AFAIK). Speaking of Chrome, though, there's an Apache CGI module that supports server-side scripting using JavaScript via Google's V8 engine, but that doesn't help you much with DB connectivity and such.
I'll also plug Java and Rhino, which I have used a bit. Via Rhino, you can compile JavaScript into Java bytecode (which, if you're using the Sun runtime, is JIT-compiled to machine code by Hotspot). That means you can run JavaScript in any servlet container (Tomcat, Resin, etc.). The joy here is that all of the huge array of goodies available for Java is instantly available to you via JavaScript -- so, MySQL connectors, image manipulation libraries, just about anything you can imagine. It's also amazingly easy to access those resources from JavaScript via Rhino. To give you an idea:
importPackage(java.io);
var f = new FileWriter("test.txt");
f.write("Testing 1 2 3");
f.close();
...and we've just written a file on the server via JavaScript, using Java's java.io.FileWriter class. You can also execute dynamic scripts at runtime via the javax.script package, which (for JavaScript) uses Rhino under the covers, although I'm not immediately coming up with a use case for doing that. :-)
For the database part of the stack:
Couchdb uses JSON and REST to store data in a document format. It uses PUT,DELETE for storage - I'm not sure how that would work with Javascript.
Helma should work well as a web server layer. It streamlines the use of Rhino as the web tier logic language.
I'm building a new service called PageForest that helps developers write totally client-side javascript programs, with PageForest providing storage and user management. Here's a sample page:
http://pfsamples.googlecode.com/svn/trunk/SAMTable/index.html#mckoss_16
This is still a work in progress, but I'd love to get some feedback on the approach. You can find more samples at the pfsamples.googlecode.com site.
Check out JScript / Windows Scripting Host(wsh) and possibly HTA's. HTA's can actually be served via a webserver and act as a locally running application with extended rights. If you want pure web development you can use WSH and some IIS tweaking to process server requests on the back end with pure javascript code in a WSF file. WSH also provides access to the file system, ODBC compliant databases and a slew of other COM exposed applications via the ActiveX model. We're not talking blazing speed, but you're programming in javascript to begin with.
Here are some links on the "stack"
http://msdn.microsoft.com/en-us/library/ms536496(VS.85).aspx
http://msdn.microsoft.com/en-us/library/15x4407c(VS.85).aspx
How about using
GWT-Spring-Hibernate-MYSql
Is the use of server side javascript prevalent? Why would one use it as opposed the any other server side scripting? Is there a specific use case(s) that makes it better than other server side languages?
Also, confused on how to get started experimenting with it, I'm on freeBSD, what would I need installed in order to run server side javascript?
It goes like this:
Servers are expensive, but users will give you processing time in their browsers for free. Therefore, server-side code is relatively expensive compared to client-side code on any site big enough to need to run more than one server. However, there are some things you can't leave to the client, like data validation and retrieval. You'd like to do them on the client, because it means faster response times for the users and less server infrastructure for yourself, but security and accessibility concerns mean server-side code is required.
What typically happens is you do both. You write server-side logic because you have to, but you also write the same logic in javascript in hopes of providing faster responses to the user and saving your servers a little extra work in some situations. This is especially effective for validation code; a failed validation check in a browser can save an entire http request/response pair on the server.
Since we're all (mostly) programmers here we should immediately spot the new problem. There's not only the extra work involved in developing two sets of the same logic, but also the work involved in maintaining it, the inevitable bugs resulting from platforms don't match up well, and the bugs introduced as the implementations drift apart over time.
Enter server-side javascript. The idea is you can write code once, so the same code runs on both server and client. This would appear to solve most of the issue: you get the full set of both server and client logic done all at once, there's no drifting, and no double maintenance. It's also nice when your developers only need to know one language for both server and client work.
Unfortunately, in the real world it doesn't work out so well. The problem is four-fold:
The server view of a page is still very different from the client view of a page. The server needs to be able to do things like talk directly to a database that just shouldn't be done from the browser. The browser needs to do things like manipulate a DOM that doesn't match up with the server.
You don't control the javascript engine of the client, meaning there will still be important language differences between your server code and your client code.
The database is normally a bigger bottleneck than the web server, so savings and performance benefit ends up less than expected.
While just about everyone knows a little javascript, not many developers really know and understand javascript well.
These aren't completely unassailable technical problems: you constrain the server-supported language to a sub-set of javascript that's well supported across most browsers, provide an IDE that knows this subset and the server-side extensions, make some rules about page structure to minimize DOM issues, and provide some boiler-plate javascript for inclusion on the client to make the platform a little nicer to use. The result is something like Aptana Studio/Jaxer, or more recently Node.js, which can be pretty nice.
But not perfect. In my opinion, there are just too many pitfalls and little compatibility issues to make this really shine. Ultimately, additional servers are still cheap compared to developer time, and most programmers are able to be much more productive using something other than javascript.
What I'd really like to see is partial server-side javascript. When a page is requested or a form submitted the server platform does request validation in javascript, perhaps as a plugin to the web server that's completely independent from the rest of it, but the response is built using the platform of your choice.
I think a really cool use of server-side Javascript that isn't used nearly often enough is for data validation. With it, you can write one javascript file to validate a form, check it on the client side, then check it again on the server side because we shouldn't trust anything on the client side. It lets you keep your validation rules DRY. Quite handy.
Also see:
Will server-side Javascript take off? Which implementation is most stable?
When and how do you use server side JavaScript?
Javascript is just a language. Because it is just a language, you can use it anywhere you want... in your browser, on the server, embedded in other applications, stand-alone applications, etc.
That being said, I don't know that there is a lot of new development happening with "Server-Side Javascript"
Javascript is a perfectly good language with a self / scheme prototype style base and a C style syntax. There are some problems, see Javascript the Good Parts, but in general it's a first rate language. The problem is that most javascript programmers are terrible programmers because it's very accessible to get started.
One team at google built out Rhino on Rails, which is an MVC framework like Ruby on Rails which is written in javascript and runs on Rhino a javascript interpreter for the Java VM. In this case they had a requirement to use the Java VM, but wanted to get a language which was fast (javascript is fast), supported duck typing, and was flexible.
Another example is something like CouchDB, a document oriented database which uses json as it's transport format and javascript as it's query & index language. They wanted the database to be as web native as possible.
Javascript is good at string and dom (xml) manipulation, being sandboxed, networking, extending itself, etc... Those kind of features are the thing you often do when developing web applications.
All that said, i don't actually develop server side javascript. It's not a bad idea, but definitely less common.
We use javascript on the client because it is there, not because from a list of languages it was our choice. I wouldn't choose it for any chore on the server.
You can run any language you like on the server, in fact, as many as you like.
javascript is reliable and easy to use, but it is just too labor intensive for common tasks on the server.
I have used both Javascript (NodeJS) and compiled languages (such as Java or C#.NET). There are huge discussions on the internet about which is preferable. This question is very old (2009). Since then the Javascript world has changed considerably, whereas honestly the Java world has not changed much (relatively).
There have been huge advancements in the Javascript world with Typescript, amazing frameworks (such as Next.JS), reactive programming, functional programming, GraphQL, SSR etc.
When I look at compiled code, especially Java code it all still seems to be the same old tools - Spring (maybe SpringBoot) and Jackson. .NET has advanced server side, but not to the extent of the JS world.
Sure my list there can be used with several languages, but I believe Javascript has improved the software engineering world considerably.
Server side development with Javascript, Typescript and NodeJs is engaging, fun and productive. Use it and enjoy it. Like millions are today.