Node.js is the software that allows you to run Javascript to create powerful server-side applications by using Google's V8 Javascript Engine. As a Node developer myself, I have always felt frustrated by seeing that Joyent, the company behind Node.s, was extremely conservative in terms of upgrading node to use the latest V8 version; the project was also struggling to get developers to actually contribute to code. This is why Fedor Indutny did the unthinkable: forked node and created IO.js. Today, the two projects are uniting possibly offering developers the best of both worlds
Original Submission
This discussion has been archived.
No new comments can be posted.
Interview with Mikeal Rogers: Node.js Fork that Ended up as a Giant, Unifying Step Forward
|
Log In/Create an Account
| Top
| 39 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(Score: 1, Touché) by Anonymous Coward on Sunday June 21 2015, @08:21AM
Interpreter everywhere. Compilers are for dinosaurs and terrorists. We have the technology to put every fucking thing into the browser. If it slow, THROW MORE CLOUD AT IT. That's the Hipster Way!
(Score: 0) by Anonymous Coward on Sunday June 21 2015, @11:22AM
Actually, I'm a nodeJs developer myself. That's rather the point of it, it is not slow and can act very much like a full desktop application inside a web browser.
There is overhead for a scripted language, but you should probably understand that a computer in 2001 was powerful enough to run this script. It is now 2015 and even cell phones now have the horsepower to run these scripts so your argument about slowness has never actually panned out in operation.
(Score: 3, Informative) by JNCF on Sunday June 21 2015, @04:19PM
Node is not inside the web browser. You can compile CommonJS (which node uses) into normal ECMAScript that can run in a browser, but the web browser definitely isn't running node. Processing power (and interpreter efficiency) has improved, but there is still a huge gap between ECMAScript in a browser and compiled C. Projects like asm.js and WebAssembly are trying to bridge that gap, but they haven't yet. The fact that they exist shows that there is a need for faster code execution than modern ECMAScript allows. We might as well be honest and up-front about this weakness. There are other reasons to use ECMAScript, and node.
(Score: 3, Insightful) by mtrycz on Sunday June 21 2015, @12:11PM
We've had interpreted languages for decades. It's faster to develop, and is a good pick if performance is not an issue. For example a rest service or a simple website. You shoudln't probably put in 5x the time to develop a microservice that isn't resource intensive.
"But it doesn't fit *my* usecase!". Choose something else, then.
In capitalist America, ads view YOU!
(Score: 3, Insightful) by VortexCortex on Sunday June 21 2015, @06:31PM
We've had interpreted languages for decades. It's faster to develop, and is a good pick if performance is not an issue.
This is precisely why my compilable meta language can also run as an interpreted. There is really no reason one can't make a scripting language that can also be compiled. Just make the interpretor / VM and (optional) bytecode compiler part of the language's standard library. That is to say: If the scripting language is designed for performance then it's a good choice even if performance is your goal.
If the compilable language is its own scripting language (as most interpreted languages are) then you can seamlessly call into and out of compiled and scripted code without a separate cumbersome API call (see: embedding Lua or JS in C). Transparent compilation permits any batch of code to be designated as compiled or scripted. The only difference between what is compiled and what is scripted is then which data you chose to compile or leave as a script. Done with rapid prototyping of some feature's code? Mark it for compilation to make it run faster. Want to fiddle with some compiled section of code at runtime? Mark it as a script. Prior to release, compile everything (except user scripts, such as configuration/customization scripts). Don't use eval() on mutable strings or runtime tainted input? Great! The VM/compiler library module doesn't have to be linked with the native program build -- you can produce a statically compiled program.
In other words: There's this huge false dichotomy that's cropped up between scripted and compiled languages. Granted, some languages are designed to make complete compilation nearly impossible (like Javascript / ECMAScript), but any compiled language can always become its own scripting language by deferring interpretation (lexing / parsing) and compilation to runtime (like some interpreted languages do, see: V8's Just In Time compilation). Language dynamism is a different issue altogether; However, there's nothing preventing a dynamic language from also being compiled. You just apply another level of indirection to data structures (allow all methods and properties to be "pure virtual" in C++ parlance -- an extra dereference per access / call).
There's really no reason not to have your dynamic interpreted script and compile it too, it's just that very few languages have been designed to facilitate this. Considering the "hybrid" approach gives you the benefits of both I expect to see much future development in this area, especially since many popular interpreted languages do some JIT compilation. So, when GP said, "Never Compile Anything, Ever!", it would have be more accurate to say, "Always Compile Everything, Everywhere!"
(Score: 2) by Nerdfest on Sunday June 21 2015, @06:48PM
You could do exactly this with Java at one point. I haven't looked at it lately as Java has actually been 'fast enough' for anything I've worked on.
(Score: 2, Funny) by Pino P on Sunday June 21 2015, @02:39PM
In other words:
Compilers are for luddites.
Modern web app appers app web apps using JavaScript apps! Apps!
(Score: 1, Disagree) by Anonymous Coward on Sunday June 21 2015, @08:37AM
Node.js is
thea software that allows you to run Javascript to create powerfulserver-sidecloudapplicationsapps by using Google's V8 Javascript Engine. As a Nodedevelopercoder myself, I have always felt frustrated by seeing that Joyent, the company behind Node.js, was extremely conservative in terms of upgrading node to use the latest V8 version; the project was also struggling to getdeveloperscoders to actually contribute to code. This is why Fedor Indutny did the unthinkable: forked node and created IO.js. Today, the two projects are uniting possibly offeringdeveloperscoders the best of both worlds(Score: 2, Interesting) by pTamok on Sunday June 21 2015, @09:24AM
Oddly enough, it tends to be* only non-native speakers of English that refer to a software or a hardware. Standard English tends to use more cumbersome phrases like 'a type of software' or 'a type of hardware'. Software and hardware are examples of uncountable mass nouns: http://www.dailywritingtips.com/is-software-a-mass-noun/ [dailywritingtips.com]
*of course there are exceptions. English is littered with exceptions. Natural languages are messy.
(Score: 5, Funny) by AnonTechie on Sunday June 21 2015, @09:36AM
Reminds me of something I recently read: (Author unknown to me)
English is One Strange Language ...
Albert Einstein - "Only two things are infinite, the universe and human stupidity, and I'm not sure about the former."
(Score: 5, Informative) by c0lo on Sunday June 21 2015, @10:09AM
There [wordsmith.org] - author is Richard Lederer [wikipedia.org] - aka "the Wizard of Idiom," "Attila the Pun," and "Conan the Grammarian." His blog may worth a visit from time to time, one may pick interesting facts on words (e.g. "Explode comes from the Latin explodere, “to chase away by clapping one’s hands.” In ancient Rome, disgruntled theatergoers would clap loudly to show their dissatisfaction with the performance on stage.").
Don't trust quite everything, hamburger has no fault for having nothing to do with ham, as this style of sandwich got its name from the city of Hamburg [wikipedia.org] somehow.
https://www.youtube.com/watch?v=aoFiw2jMy-0
(Score: 2) by AnonTechie on Sunday June 21 2015, @12:17PM
Thanks c0lo
Albert Einstein - "Only two things are infinite, the universe and human stupidity, and I'm not sure about the former."
(Score: 1) by Pino P on Sunday June 21 2015, @02:43PM
this style of sandwich got its name from the city of Hamburg somehow.
And it turns out they don't even know [wikipedia.org] where the "Ham" in Hamburg comes from.
(Score: 2) by c0lo on Sunday June 21 2015, @02:58PM
https://www.youtube.com/watch?v=aoFiw2jMy-0
(Score: 2) by stormwyrm on Monday June 22 2015, @05:51AM
Numquam ponenda est pluralitas sine necessitate.
(Score: 2) by c0lo on Monday June 22 2015, @06:22AM
Wasn't always so. Wikipedia entry [wikipedia.org]:
https://www.youtube.com/watch?v=aoFiw2jMy-0
(Score: 2) by aristarchus on Monday June 22 2015, @08:33AM
This doth gruntle me most couth. Etymology is not always what entymologists think it ought to be. Or bee.
(Score: 1, Touché) by Anonymous Coward on Sunday June 21 2015, @05:47PM
grammaticalword choiceserrorsdifferent from those I would have made, in summaryftfy
(Score: 2) by fleg on Sunday June 21 2015, @10:07AM
i have written code in a few languages, javascript is the only one i really loathed. as a result i dont keep up to date with it. its been about 5 years since i did any, has it got any better?
havent used node.js, the idea of writing non-trivial server side stuff in javascript blows my mind, anyone out there done it and care to share their experiences? whats node.js good for?
(Score: 3, Informative) by NCommander on Sunday June 21 2015, @10:20AM
My understanding its event processing done in JavaScript, which integrates nicely with AJAX frontend code. I'm not familiar with node.js itself, but flipping through the docs briefly, its the JS version of twistd from python. In short, a frontend server looks for an event (vs loading a specific script like in traditional CGI), and that event causes server-code to go; an ideal circumstance for AJAX queries, and the like.
Still always moving
(Score: 0) by Anonymous Coward on Sunday June 21 2015, @11:25AM
Well, normally you would have your apache.ini file which had to be edited, you would have your mysql server that would need to be setup, you'd have an SMTP server setup for mail, and the list goes on and on.
NodeJs takes all of that and crushes it down into a full webserver with all of that included 3/4 of a single page of script.
It is a vast improvement, and simplification of the entire process.
(Score: 0) by Anonymous Coward on Sunday June 21 2015, @11:28AM
If you want to see what the entire nodeJS index.js file (which runs everything) looks like you can head over to https://darrencaldwellwebdesign.ca/ [darrencaldwellwebdesign.ca] and check under articles. I wrote one there about nodejs and how to setup your first server (it takes about 10 minutes maybe, which is again a really big improvement).
(Score: 5, Informative) by deimios on Sunday June 21 2015, @11:59AM
I have a bit of experience with node.js and when it works it's the perfect fast prototyping platform for sites. Though coming from a JavaEE background I guess a dead turtle in superglue is faster at prototyping than JSF.
From my (arguably limited) point of view:
Pros:
You can get from 0 to functional webapp in minutes
The package manager is pretty good when it works, there are packages for almost everything
The async/ callback based coding style is interesting
Being JS based it works nicely with MongoDB and other JSON style NOSQL DBs
The community is HUGE and still growing
Extremely simple to configure some very complex stuff. Since you're on the same level as the webserver you can tweak pretty much anything.
Cons:
Singlethreading can mess up multiuser sites in interesting ways. Especially coupled with the "cluster" module which makes it multithreaded.
It's rapidly evolving, sometimes breaking modules or their dependencies. Lack of a "standard" way of doing things, since modules implement features first then the core catches up with an incompatible implementation.
Callback hell (it's so bad it has its own site: callbackhell.com)
Since you're working on the same level as the webserver you will need the boilerplate to actually fire up listeners on port 80 and all the other misc stuff.
(Score: 2) by fleg on Monday June 22 2015, @02:32AM
interesting, thanks.
i'm now wondering if node.js would be a good fit for something i may have to do.
i have a java command line which takes some images (3 or 4), does some processing on the images (takes upto 5minutes) and spits out a result image. at some point in the future we may want to put that command line behind/in a server and have people send the images they want and receive the result back.
i had been thinking i would have to go the route of ejbs and some sort of app server like say jboss (which i have used before), but it feels like overkill, so i'd been considering just writing a simple server which just sits on a socket waiting for requests. but now i'm thinking maybe node.js is worth investigating.
(Score: 2) by deimios on Monday June 22 2015, @04:05AM
If your image processing algorithm is non-blocking or can be rewritten to be non-blocking then go for it.
Just beware: node.js runs in a single thread so if you do any synchronous heavy processing, it will hang the main thread's event loop which will pretty much hang the whole stack. This means: no pages served, no logs written until the processing is done.
Take a look here: https://github.com/glenjamin/node-fib/blob/master/app.js [github.com] to see an example of node.js style heavy processing. It calculates the Fibonacci tree in a non-blocking way. (not my code)
(Score: 2) by fleg on Monday June 22 2015, @05:08AM
understood, thanks.
(Score: 2) by mtrycz on Sunday June 21 2015, @12:21PM
ECMAScript6 - the attempt to repay the technological dept of JavaScript - is due to come out this year. I don't expect it to "fix" Javascript, but thet's the best people are able to come up with, other than WebAssembly (precompiled blobs that run in your browser).
node is good for i/o intensive work, because of its asynchronous i/o model, but since it's singlethreaded, cpu-intesnive loads will hog up all interactions.
It's good for some quick web-related stuff, it's easy to pickup and fast to prototype in - for small projects where a bigger language or framework would be overkill. For bigger projects: with js it's way to easy to shoot yourself in the foot.
In capitalist America, ads view YOU!
(Score: 2) by mtrycz on Sunday June 21 2015, @12:24PM
Oh, and the hate node.js is getting, is because of it's userbase - fervent hipsters that just can't understand that people have other use-cases than their webdev stuff.
In capitalist America, ads view YOU!
(Score: 2) by mtrycz on Sunday June 21 2015, @12:28PM
Also, "cloud" companies tend to offer bandwidth for much cheaper than storage, cpu and ram. A small 1 core / 512 ram vps instance goes for as little as 5$ a month. If the application is actually i/o bound with small cpu overhead, then with asynchronous io you'll get better performance than with traditional (threaded) webservers.
Sorry, I just can't think clearly right now.
In capitalist America, ads view YOU!
(Score: 1) by Pino P on Sunday June 21 2015, @03:41PM
A small 1 core / 512 ram vps instance goes for as little as 5$ a month.
Is that with its own IPv4 address, or is it behind a NAT?
(Score: 2) by mtrycz on Sunday June 21 2015, @04:15PM
Digitalocean, which I am not affiliated with, but ofen use, gives you a public ipv4 (or ipv6 in some regions), and optional "private networking". Also, it's the most flexible I know (haven't tried most of the new ones like Heroku, tho), giving you the option to create and destroy "droplets" on the fly, and even programmatically with an API. The cheapest "doplet" is 5$ a month with hourly billing, and you can dispose of your "droplet" when you're done.
I think it wasn't actually invented for stable hosting, but dynamic prototyping and such, but the prices are good even as hosting goes, for the small instances. For VPS at least. I don't know how does it compare for big instances, since I have never used those... all my projects are small/low traffic.
In capitalist America, ads view YOU!
(Score: 1) by Pino P on Sunday June 21 2015, @02:54PM
ECMAScript6 - the attempt to repay the technological dept of JavaScript - is due to come out this year.
ECMAScript 6 is already "out" in the sense that it's been approved by Ecma [sdtimes.com].
(Score: 2) by arslan on Sunday June 21 2015, @11:55PM
Yes, it has improved. The latest version ES6 coming out will hopefully make you not have to touch prototypes at all as it will support classes and modules natively. Although to be fair depending on what you do you can pretty much avoid it today already with ES5 - traditional OO developers just get caught up too much by it when most of the time you don't really need it. Even the quirkiness with "this" has some enhancements in ES6 to lessen its quirkiness.
As for Nodejs, the whole point of it is to make "complicated" server side development simple. Like any other language, as the supporting libraries and frameworks increases, it can only get simpler to build functionality by cobbling together 3rd party libraries. However, given it is based on javascript there is some adjustment to get used to. For example, most IO by _default_ happens asynchronously but CPU compute does not, so concepts like promises (and the upcoming generators) play a bigger role than in languages like Java where execution are by default serial. Because of this fundamental nature of javascript, developing apps that are IO bound most of the time and can handle lots of concurrent request is pretty straightforward. So if you're developing a typical web app where you require a RESTful interface to bridge to a Database with some minor processing in between (typical web app) then it is pretty simple/straightforward to build and the performance is quite good
On the UI side (browser), I can honestly say it is much better than developing in Swing or even JavaFX (I've done quite a few years in the former). The tooling is excellent just with the Chrome browser alone. The upcoming Web Components will also alleviate some of the "workarounds".
(Score: 2) by fadrian on Sunday June 21 2015, @02:02PM
.. in 3... 2... 1...
That is all.
(Score: -1, Offtopic) by Anonymous Coward on Sunday June 21 2015, @02:24PM
I sort of lost my taste for it after several leftist manufactured controversies....
(Score: 0) by Anonymous Coward on Monday June 22 2015, @01:02AM
It happened!
https://gigaom.com/2013/12/02/slap-fight-in-node-js-land/ [gigaom.com]
Two major contributors to the popular server-side language are squabbling over whether they can nuke gender pronouns in the Node code and project, in general. The spat, because of the nature of open-source projects, spilled over on this Github thread. Long story short is that one major Node.js contributor, Ben Noordhuis, rejected a pull request that gender pronouns be eliminated. Project lead Issac Schlueter, a Joyent employee, over-rode that move.
Joyent SVP of engineering Bryan Cantrill weighed in on all of this in a “Power of a Pronoun” blog post over the weekend because he said Joyent was being blamed for Noordhuis’ move even though he is not a Joyent employee. Joyent launched and nurtured Node.js, so it is often associated with any and all moves involving the language. Cantrill backed up what Schlueter did and added that had Noordhuis been a Joyent employee, he would have been fired.
(Score: 5, Interesting) by darkfeline on Monday June 22 2015, @02:37AM
To sum it up as objectively as possible, the problem with Node is that it adds yet another interpreted language to the growing pile of interpreted languages, for no real benefit. We already have very good interpreted languages like Python and Ruby (Perl, Lisp, Clojure, for varying definitions of "interpreted"), and as a plus, these languages don't do things like
> '5' - 3
2 // weak typing + implicit conversions = headaches
> '5' + 3
'53' // Because we all love consistency
> '5' - '4'
1 // string - string = integer. What?
> '5' + + '5'
'55'
> 'foo' + + 'foo'
'fooNaN' // Marvelous.
> '5' + - '2'
'5-2'
> '5' + - + - - + - - + + - + - + - + - - - '-2'
'52' // Apparently it's ok
> var x = 3;
> '5' + x - x
50
> '5' - x + x
5 // Because fuck math
Yet all this manpower is being wasted in developing Node and developing software in Node. It's as if we collectively in the computer industry haven't done enough to create needless busywork, so we're creating even more busywork. Well, at least it'll keep the wheels of capitalism well-oiled.
Join the SDF Public Access UNIX System today!
(Score: 3, Interesting) by JNCF on Monday June 22 2015, @04:19AM
the problem with Node is that it adds yet another interpreted language to the growing pile of interpreted languages, for no real benefit.
I disagree. I think node provides a unique benefit in that it uses a language that already runs in the browser. If you use browserify, you can even write your client side in CommonJS. This lets you write modules that can be used on the server and the client (it also solves the global block scope issue if used correctly). And we have databases (like MongoDB, with all its flaws) that run on JSON (technically BSON), so that we can use the same object structures from our database all the way to the browser. ECMAScript is the only interpreted language we have that can really do that, and I see value in this.
That being said, ECMAScript is full of fuckery. You simply have to use a reasonable subset of it, and build up from there.
This is my favorite example:
8 === 010
// true because a leading zero makes ECMAScript use octal.
8 == '8'
// true because a double-equals makes ECMAScript coerce strings into number.
8 == '010'
// false because ECMAScript is crazy, and doesn't check to see if a number is in octal after coercing it from a string. That simply isn't in the standard.
10 == '010'
// true for the exact same reason.
(Score: 2, Interesting) by OwMyBrain on Monday June 22 2015, @02:16PM
Long ago, in the before times, the wizards of the Internet created the web browser as prison for Javascript. For those sages new the horrors that would be unleashed upon the world should Javascript ever truly be free. Alas, the years have passed and the treachery of Javascript hath been forgot. Javascript's prison is broken! Woe, woe, woe unto us! The shadow is spreading, and soon all the stack shall be covered in darkneses.