The article lost me at quotes like this one (both for content and persons position when talking enterprise) -- “Why go to Facebook and do PHP when you can go to PayPal and do Node.js”
- Bill Scott – Dir UX PayPal
Hip Hop, and "PHP" don't really share that much. Wordpress templating is what a lot of people think PHP is like. Zend Framework too. But saying PHP and Hip Hop are the same is kind of like saying Shakespeare and Flavor Flav both speak English.
Sure they both do a lot of Rhyming, but you'd have a hard time getting the two to understand one another.
(I don't like PHP particularly, but calling what FB does "php" is inaccurate)
PHP has the ability to be written "inline" basically all of PHP acts like a templating engine. That's not how FB makes its developers write. That's a big difference.
Also HipHop supports a subset of PHP's functions, which actually causes you to write better code because you can't lean on things like "eval" and dynamic defines. This makes your code better.
There is a lot of "this kind of stuff" that makes PHP very different from HipHop.
Is "Stockholm Syndrome" becoming the goto plug reply to anyone who doesn't agree with the hivemind? I have been noticing it a lot lately.
>Clearly you haven't suffered the misfortune of having to program in PHP recently.
If anything PHP has become a lot better than what it was half a decade ago. Clearly you haven't used it recently.
I find amazing that despite PHP being popular than all the other mainstream web languages combined, comments such as "Does anyone still use PHP?", "PHP is so bad no one ever uses it." show up. Its akin to close your eyes and what you don't like goes away.
I am not rooting for PHP, but comments like these are silly and adds no value to discussion.
My thought at that was "great, in 12-18 months PayPal will have a bunch of devs saying "why stay here and do Node.js when I can go to company Foo and do <current trendy language du-jour>."
For a number of reasons. "Web Scale deployments" like Linked-in and Pay-Pal aren't actually what most people call Enterprise. The line blurs a bit, but because they are Massive Scale Single Task solutions they aren't what the industry defines as enterprise.
Second. Node is use primarily in two places, Private Cloud. (like pay pal and linked in) where you want to run on hardware as a commodity, but don't want the overhead of a true VPS, instead you run in an "Engine" which is hardware independent. That's great if you are Huge. But it makes less sense in traditional enterprise... Which is why we come to number 3....
Third. Node isn't secure enough for Enterprise. Enterprise runs on well tested, secure, solutions, with strong support, because... You can't get hacked, you can't deal with your developer quitting, and you can't deal with the solution is no longer supported.
This piece is marketing hype, not "white paper fact" or even "Case study support"
Yes I expect lots of downvotes, happens every time I say something bad about node. But the truth of it is that Node is for Hackers, not for production. It is tech born from a poorly conceived language, running in an engine that was designed for clients not servers, and unless you have a team of security guys, and a strong proxy, and a bunch of other things, it is not "production safe".
Number of deployments doesn't equate to secure, or Windows 95 would have been considered Secure in 1996. (It's in good shape these days)
Most companies get Node to be "secure" by putting a Proxy in front of it. Doing a lot of packet inspection, and limiting interactions with the server to validated requests.
If you set something like this up you can make anything secure. But most people can't do this, they don't know how. Most enterprise don't do this because setting up packet inspection for validation requires a lot of planning, and so unless you are massive scale it isn't worth, so this remains in the realm of things only banks and financial institutions do.
> If you set something like this up you can make anything secure
I'm surprised there isn't an open source "secure" proxy service that you mentioned. It also makes sense to keep on top of updates.
Also, if security is an important requirement, then it makes sense for the organization to use someone who knows what they are doing to set up the network and own the security requirement. Audits would also be prudent.
Also, some proxy servers will prevent such attacks.
> Find anywhere the developer has used an "Eval" and exploit it.
Don't use eval. Just about every node.js dev knows that. If you have a developer using eval, they better have a damn good reason to do so. I can't think of any, unless you have some sort of web repl. But then, I doubt enterprise apps will have a requirement for a repl that allows arbitrary code to be executed on the server.
As the OP stated, there is a higher concentration of "good developers" with node. If someone programs in such a way, they probably should be fired.
@briantakita Node doesn't have a higher concentration of "good developers" that's easy to tell. "Good Developers" flock to research projects, and advancing the art. There isn't a single Node.JS project that is leading the industry in a field. Python, Lisp, Java, all have Language, AI, and Physics projects that are shaping science and advancing humanity, what does Node have?
Also a quick Ego Search of yourself would tell pretty quickly where you rank on the "good developer list". I wouldn't normally "bash" a person for their arguments, but when you say the developers make node good and then I search your name to find out if you are totally awesome, RipOff Report doesn't inspire confidence.
Gee thanks for the attack on my character! Yes, I had a lady extort me when I tried to help out one of my friends in the entertainment industry. She tried to charge for services that she didn't perform. I tried to send her a check for what we agreed on but she wouldn't give me an address and decided to attack me in public instead. I never met this lady nor talked to her before this incident happened. Btw, stay away from the entertainment crowd. Too much drama. Ripoff report also has great SEO.
Character assassination is great and totally fair, lol! One thing I have learned from this experience is to spot bullshit and call it out immediately. And some of the things you have said, and now some of your actions, smell like bullshit.
I'm sorry it upset you. Now can we stick to our actual discussion?
Anyways, I have over 12 years experience and have been contributing to open source for a while. Projects including RSpec & RR. I'm pretty disciplined (automation, testing, good practices, etc) been a lead dev on a number of projects. I've done full stack web development (front end & back end), devops, scaling, scientific computing, & embedded systems. I worked with a number of startups. I've spoken at conferences. Check out my Linked In & Github profile if you want to see my caliber.
What I meant by good developer is someone who is on the edge of technological movements. Yes, that even includes open source software.
I was an early adopter in the Ruby community. I've been blessed by being around innovative people. I've rubbed elbows with the founders of Github, Ward Cunningham, and the many innovative developers that make up a strong community. It had a great feeling of innovation because there were great people involved. I feel (yes, it's a feeling), that the same spirit of innovation has moved to the node.js community.
I agree that there is lots of innovation in the sciences. But that doesn't diminish the contributions of the many open javascript (& node.js) developers out there.
What has been done in node.js? Keep your eyes open because it's unfolding before you right now. Yahoo, Google, Github, Walmart Labs, Twitter all seem to like it and they are doing a good job in "advancing the field". Your FUD can't do a thing about it.
What have you done? You seem to be the "expert" on this manner, even though you can't even support your argument without ad hominem attacks.
> Most companies get Node to be "secure" by putting a Proxy in front of it.
To build on this, every company I know of runs a proxy in front of every application server (across all languages).
Further, there's also SSL termination which also happens before hitting the application server, plus normally the edge of network security sits out in front of the app server.
Running these services in front of an app server is par for the course.
>We're dedicated to Node.js
nearForm was founded in 2011 by Richard Rodger and Cian Ó Maidín with the vision to help Node.js to become a mainstream technology.
If all you're building is a service proxy to a database, node will get you very far really fast. Its thin layer will allow you write a clean REST api that consumers can reliably call.
Javascript does not scale well though when a project grows to hundreds of thousands of lines of code, but that shouldn't stop you from investigating TypeScript, Dart, or even Coffeescript.
I am a proponent (and user) of CoffeeScript, but it won't help you very much with maintainable architecture. It's mostly just syntactic sugar over normal JavaScript.
I work on a large web application that sits currently at 50k lines of CoffeeScript and spans 10+ feature branches at all time.
No, it does not scale. Especially true when the project also spans that many branches. Everyone merging up and down the branches. You get to have backend people merging frontend codes without much problem because it's all dynamic. Then you found out it was a bad merge in production because CoffeeScript doesn't care.
The fact that CoffeeScript makes braces optional causes a lot of problem because when it fails, it fails silently. Bad merge happens, but you'll want it to fail loudly when it does happens.
Out of Dart, TypeScript and CoffeeScript, I recommend TypeScript for large scale projects. Dart is good if you have a lot of man power to build in house components, but it has a very closed ecosystem that does not play well with other JavaScript libraries.
> Dart is good if you have a lot of man power to build in house components, but it has a very closed ecosystem that does not play well with other JavaScript libraries.
You mean "JavaScript libraries", not "other JavaScript libraries". Dart is a language one of whose implementations is a compiler-to-JS, but it most assuredly is not, and does not pretend to be, a JavaScript library.
It sounds like you've got an organizational problem if merging and the lack of a staging server are the main source of issues for you. How does a bad merge get onto production? Why are "backend people" working on frontend code? Do you have a testing framework? Do you use a module system like CommonJS or AMD? Is your team trying to treat JS/CS like a strongly-typed OOP language?
TypeScript seems good if you come from an enterprise/Java background and are used to OOP with static typing.
Bad merge get into production all the time :) I think the best example is the recent Apple SSL issue.
Backend people don't work on the frontend code, but they do perform catch up merge from master branch. These merges may conflicts and can result in bad merge.
Testing only helps to a certain point, not everything is testable. I don't see how module system can make merging issue go away, but I do think static-typing will make these things fail faster and louder.
I do have a bit of Java background. I moved from strictly typed Java world to less strictly typed ActionScript world to now even less strictly typed JavaScript world. I dabbled a bit of Haskell while working with JavaScript. Coming from Java to JavaScript, the dynamic type system of JavaScript is a breath of fresh air. But it is Haskell that made me starting to truly appreciate static type system.
What are you basing "Javascript does not scale well" on? If you are careful about delegating to worker nodes and avoid blocking, Node.js scales quite well for CPU intensive problems. If you have a really CPU intensive problem, you can invoke an external program to do heavy calculations for you.
> Node.js is a platform built on Chrome's JavaScript runtime for easily building fast, scalable network applications. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices.
You wake up in the morning and say, "I wish I had a Samsung Galaxy S5".
Async: you tell your personal assistant to go get you one. You continue your day, eat breakfast, build a shrine to hold your new phone and he comes back and says "they were out, I'm sorry, do you want me to go back and get an iPhone instead?"
Non-Blocking: you try to click the buy it now on Amazon and it says, "Out of stock. Would you like to order and have fulfilled when back in stock?" you click yes. You eat breakfast, write the next Flappy Bird, and get actual work done. 4 days later it comes back in stock and your new phone arrives.
If you missed the difference, Async, is "fire and check back later". Non-blocking is "error instantly, Perform later or in parallel".
There are other differences but this is an easy analogy, that shows how the two are not synonyms.
Node.js is said to run an a single-threaded "non-blocking" event loop. Whenever i/o is performed, you give a callback which is invoked when the i/o is completed, either with success or error.
commonjs modules are a great abstraction. I have a codebase in the 10^5 magnitude of LoC. It's a pleasure to work with. I don't see any code maintenance issues with scaling 1 or 2 orders of magnitude. Maybe memory issues? But then, it probably makes sense to break up your services.
Honest question - this is like the 4th NodeJS related article to make it to the first page in the last couple of days after a period of quiet. Is there something in the Node ecosystem prompting this?
Hmm, I work for a company that processes insurance claims. That's enterprisey, right? Let me tell you you'll get a blank/'are you crazy' type stare if you suggest node.js here (rightly or wrongly). We use programs written in COBOL running on AS/400. That's insurance/banking enterprise software. The very thought of running some trendy hipster WWW-popup-box-turned-server-side "programming language" like JavaScript for anything -- anything at all -- is likely to be met with disgust. Like I said, this might not actually be the right attitude to take, but rest assured the "nobody ever got fired for buying IBM" attitude still prevails in the truly enterprisey enterprise.
56 comments
[ 4.2 ms ] story [ 126 ms ] threadEven if I was 99% certain everything would go fine that's just too much of a risk to take.
Unless some kind of show stopping issue was happening I'd wait until after cyber monday or plan the release way before hand.
(I mean, Node's okay, not my favorite, but PHP is still as much "training wheels without the bike" as it ever was.)
Sure they both do a lot of Rhyming, but you'd have a hard time getting the two to understand one another.
(I don't like PHP particularly, but calling what FB does "php" is inaccurate)
PHP has the ability to be written "inline" basically all of PHP acts like a templating engine. That's not how FB makes its developers write. That's a big difference.
Also HipHop supports a subset of PHP's functions, which actually causes you to write better code because you can't lean on things like "eval" and dynamic defines. This makes your code better.
There is a lot of "this kind of stuff" that makes PHP very different from HipHop.
HipHop has near full support for PHP 5.4, including the "create_function" and "eval" functions.[1]
Yes, PHP and HipHop are different, because one is a language and the other is a virtual machine.
[1]http://en.wikipedia.org/wiki/HipHop_for_PHP
>Clearly you haven't suffered the misfortune of having to program in PHP recently.
If anything PHP has become a lot better than what it was half a decade ago. Clearly you haven't used it recently.
I find amazing that despite PHP being popular than all the other mainstream web languages combined, comments such as "Does anyone still use PHP?", "PHP is so bad no one ever uses it." show up. Its akin to close your eyes and what you don't like goes away.
I am not rooting for PHP, but comments like these are silly and adds no value to discussion.
I take issue with a quote from a Director of UX being used to back up how NodeJS is taking over the Enterprise.
For a number of reasons. "Web Scale deployments" like Linked-in and Pay-Pal aren't actually what most people call Enterprise. The line blurs a bit, but because they are Massive Scale Single Task solutions they aren't what the industry defines as enterprise.
Second. Node is use primarily in two places, Private Cloud. (like pay pal and linked in) where you want to run on hardware as a commodity, but don't want the overhead of a true VPS, instead you run in an "Engine" which is hardware independent. That's great if you are Huge. But it makes less sense in traditional enterprise... Which is why we come to number 3....
Third. Node isn't secure enough for Enterprise. Enterprise runs on well tested, secure, solutions, with strong support, because... You can't get hacked, you can't deal with your developer quitting, and you can't deal with the solution is no longer supported.
This piece is marketing hype, not "white paper fact" or even "Case study support"
Yes I expect lots of downvotes, happens every time I say something bad about node. But the truth of it is that Node is for Hackers, not for production. It is tech born from a poorly conceived language, running in an engine that was designed for clients not servers, and unless you have a team of security guys, and a strong proxy, and a bunch of other things, it is not "production safe".
It's time for you to move on and bash a newer, emerging, "unproven" technology.
In the mean time, have fun with cobol, cause that's the only "proven" technology out there :-,
Most companies get Node to be "secure" by putting a Proxy in front of it. Doing a lot of packet inspection, and limiting interactions with the server to validated requests.
If you set something like this up you can make anything secure. But most people can't do this, they don't know how. Most enterprise don't do this because setting up packet inspection for validation requires a lot of planning, and so unless you are massive scale it isn't worth, so this remains in the realm of things only banks and financial institutions do.
I'm surprised there isn't an open source "secure" proxy service that you mentioned. It also makes sense to keep on top of updates.
Also, if security is an important requirement, then it makes sense for the organization to use someone who knows what they are doing to set up the network and own the security requirement. Audits would also be prudent.
"How to Hack a Node.Js" for
Send multiple pipelined HTTP requests via a single connection.
Find anywhere the developer has used an "Eval" and exploit it.
Those are the quick 2 that fit easily in a HN comment.
That DoS attack vector was fixed.
http://blog.nodejs.org/2013/10/22/cve-2013-4450-http-server-...
Also, some proxy servers will prevent such attacks.
> Find anywhere the developer has used an "Eval" and exploit it.
Don't use eval. Just about every node.js dev knows that. If you have a developer using eval, they better have a damn good reason to do so. I can't think of any, unless you have some sort of web repl. But then, I doubt enterprise apps will have a requirement for a repl that allows arbitrary code to be executed on the server.
As the OP stated, there is a higher concentration of "good developers" with node. If someone programs in such a way, they probably should be fired.
Character assassination is great and totally fair, lol! One thing I have learned from this experience is to spot bullshit and call it out immediately. And some of the things you have said, and now some of your actions, smell like bullshit.
I'm sorry it upset you. Now can we stick to our actual discussion?
Anyways, I have over 12 years experience and have been contributing to open source for a while. Projects including RSpec & RR. I'm pretty disciplined (automation, testing, good practices, etc) been a lead dev on a number of projects. I've done full stack web development (front end & back end), devops, scaling, scientific computing, & embedded systems. I worked with a number of startups. I've spoken at conferences. Check out my Linked In & Github profile if you want to see my caliber.
What I meant by good developer is someone who is on the edge of technological movements. Yes, that even includes open source software.
I was an early adopter in the Ruby community. I've been blessed by being around innovative people. I've rubbed elbows with the founders of Github, Ward Cunningham, and the many innovative developers that make up a strong community. It had a great feeling of innovation because there were great people involved. I feel (yes, it's a feeling), that the same spirit of innovation has moved to the node.js community.
I agree that there is lots of innovation in the sciences. But that doesn't diminish the contributions of the many open javascript (& node.js) developers out there.
What has been done in node.js? Keep your eyes open because it's unfolding before you right now. Yahoo, Google, Github, Walmart Labs, Twitter all seem to like it and they are doing a good job in "advancing the field". Your FUD can't do a thing about it.
What have you done? You seem to be the "expert" on this manner, even though you can't even support your argument without ad hominem attacks.
Seriously?
To build on this, every company I know of runs a proxy in front of every application server (across all languages).
Further, there's also SSL termination which also happens before hitting the application server, plus normally the edge of network security sits out in front of the app server.
Running these services in front of an app server is par for the course.
[0] http://en.wikipedia.org/wiki/FIPS_140-2
http://www.nearform.com/about-us
Explains the article. And founding a company to promote a development stack? I don't get it.
Javascript does not scale well though when a project grows to hundreds of thousands of lines of code, but that shouldn't stop you from investigating TypeScript, Dart, or even Coffeescript.
No, it does not scale. Especially true when the project also spans that many branches. Everyone merging up and down the branches. You get to have backend people merging frontend codes without much problem because it's all dynamic. Then you found out it was a bad merge in production because CoffeeScript doesn't care.
The fact that CoffeeScript makes braces optional causes a lot of problem because when it fails, it fails silently. Bad merge happens, but you'll want it to fail loudly when it does happens.
Out of Dart, TypeScript and CoffeeScript, I recommend TypeScript for large scale projects. Dart is good if you have a lot of man power to build in house components, but it has a very closed ecosystem that does not play well with other JavaScript libraries.
You mean "JavaScript libraries", not "other JavaScript libraries". Dart is a language one of whose implementations is a compiler-to-JS, but it most assuredly is not, and does not pretend to be, a JavaScript library.
TypeScript seems good if you come from an enterprise/Java background and are used to OOP with static typing.
Backend people don't work on the frontend code, but they do perform catch up merge from master branch. These merges may conflicts and can result in bad merge.
Testing only helps to a certain point, not everything is testable. I don't see how module system can make merging issue go away, but I do think static-typing will make these things fail faster and louder.
I do have a bit of Java background. I moved from strictly typed Java world to less strictly typed ActionScript world to now even less strictly typed JavaScript world. I dabbled a bit of Haskell while working with JavaScript. Coming from Java to JavaScript, the dynamic type system of JavaScript is a breath of fresh air. But it is Haskell that made me starting to truly appreciate static type system.
Not understanding this leads to pain and suffering on a massive scale.
http://nodejs.org/
> Node.js is a platform built on Chrome's JavaScript runtime for easily building fast, scalable network applications. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices.
Async: you tell your personal assistant to go get you one. You continue your day, eat breakfast, build a shrine to hold your new phone and he comes back and says "they were out, I'm sorry, do you want me to go back and get an iPhone instead?"
Non-Blocking: you try to click the buy it now on Amazon and it says, "Out of stock. Would you like to order and have fulfilled when back in stock?" you click yes. You eat breakfast, write the next Flappy Bird, and get actual work done. 4 days later it comes back in stock and your new phone arrives.
If you missed the difference, Async, is "fire and check back later". Non-blocking is "error instantly, Perform later or in parallel".
There are other differences but this is an easy analogy, that shows how the two are not synonyms.
http://en.wikipedia.org/wiki/Non-blocking_algorithm
Node.js is said to run an a single-threaded "non-blocking" event loop. Whenever i/o is performed, you give a callback which is invoked when the i/o is completed, either with success or error.
BTW did you mean to say "Node.js scales quite well for CPU intensive problems."? If so, that is very incorrect. I/O intensive yes, CPU intensive no.
I have no strong feelings about Node either way, but people who value Node should downvote stuff like this into oblivion.
I've seen more substance in copy for a Herbalife ad.
And bad programmers get turned into good programmers with the mainstream technology X.
I never thought I'd live to see it, but, finally, after all these years... A silver bullet has been found, gentlemen!
Hmm, I work for a company that processes insurance claims. That's enterprisey, right? Let me tell you you'll get a blank/'are you crazy' type stare if you suggest node.js here (rightly or wrongly). We use programs written in COBOL running on AS/400. That's insurance/banking enterprise software. The very thought of running some trendy hipster WWW-popup-box-turned-server-side "programming language" like JavaScript for anything -- anything at all -- is likely to be met with disgust. Like I said, this might not actually be the right attitude to take, but rest assured the "nobody ever got fired for buying IBM" attitude still prevails in the truly enterprisey enterprise.