Ask Slashdot: Node.js vs. JEE/C/C++/.NET In the Enterprise?

theshowmecanuck writes "I'm working at a small- to medium-sized company that creates software for mobile devices, but came from a 'large enterprise' world before. I see node.js being used increasingly in smaller companies (including ours) or in web/mobile related software. Meanwhile we see languages like Java/JEE, C/C++, and .NET continue to be used for medium-to-large enterprise corporate software. Compared to the status quo in the enterprise (JEE/C/C++/.NET ... and yes, maybe even COBOL) maybe Slashdotters can chime in on how they see Node.js in this role. I'm thinking of things like complexity of business logic (dependencies, workflows, linear processes, etc), transaction support (for processes in general and database support), messaging services, etc. Also, what is the state of Node.js in terms of paradigms like application containers, where much of the 'plumbing' is already set up for you (one of the main benefits of JEE application containers)? But there is also the question of maintainability, deployment, and ongoing operations. What say you, Slashdot?"

Comments

Who you gonna call?

[skovnymfe]

When node.js goes to shit and your enterprise class software worth millions or even billions of dollars is ruined, who you gonna call? Nobody, that's who. That's why node.js isn't for enterprise use.

Re:Who you gonna call?

[Kjella]

And when your Java application goes to shit you're going to call Oracle? Reality is that for enterprise code it's more about longetivity than anything else (no "ancient VB6 app nobody knows how to touch anymore") and by the looks of it Javascript is here to stay. Sure sounds a lot better than many of the other fads out there.

Re:Who you gonna call?

[Tridus]

And when the Oracle .net driver goes to shit, who you gonna call?

Hint: Microsoft and Oracle will blame each other and it'll take six months to get a fix. My day job is dealing with both of them, and it does happen sometimes. I don't care for node.js much at all, but the idea that it's somehow inherently more dangerous than stuff from big companies is just nonsense.

Re:Who you gonna call?

[angel'o'sphere]

I reply to you, not the followups that are similar brain dead.

What is node.js? It is a server software you can download.

Then you have a bash script and some config files to start it. And perhaps a book from O'Reeilly.

When you write your code against it, you figure if it is "good enough" for you.
When you deploy it in your enterprise you very likely consider to stick stable to the current version/release for YEARS.

So, meantime node.js is no longer maintained. WHO CARES?

You stick to your old version, and you are good. If you need new features that belong into node.js and not into your software you hire one for it. Or you write it yourself.

BTW: do you really believe if it is no longer maintained it won't become an Apache project?

What about all the other software out there that once was open source and was used by enterprises and is no longer maintained? I never heared about a company going bankrupt because of this.

Re:Who you gonna call?

[sproketboy]

That's much less likely to happen with Java apps. skovnymfe's point (since it flew way over your head) was that node.js is not backed by a big company so if you're doing important development you probably would want to use something safer.

Re:Who you gonna call?

[sproketboy]

WTF are you talking about? Oracle .net driver? You mean you're using .net with an oracle database instead of mssql? Well there's your problem. M$ doesn't like other databases except theirs.

Re:Who you gonna call?

[Tridus]

Yes, because there's never been a bug that manifested in some weird situation after everything had been live and working for months. Nope!

Re:Who you gonna call?

[mystikkman]

So, meantime node.js is no longer maintained. WHO CARES?

You stick to your old version, and you are good. If you need new features that belong into node.js and not into your software you hire one for it. Or you write it yourself.

And then you get hit by a vulnerability.

http://blog.nodejs.org/2012/05/07/http-server-security-vulnerability-please-upgrade-to-0-6-17/

Re:Who you gonna call?

[rioki]

First you chose the right tool for the job at hand. node.js is not intended for serious number crunching, but neither is Java or .Net. If you need multi-threading in node.js you are doing it wrong; node.js efficiently handles many thousand parallel executions, in one thread. Node.js is very efficient at waiting and reacting to input. One node.js instance can get up to 99% on one CPU core, something that is really hard with a Java or .Net application that happens to do I/O. If your needs extend one core you can always use cluster and thus spawn multiple node.js processes working the same program. node.js is awesome, since in almost all applications this approach results in a very easy solution to scaling out.

So far with npm, I have found everything I can possible want under the sun and all with permissive licenses, such as MIT. I don't see the issue here.

Finally if you really need the raw power, use C or Fortran, seriously. Java and .Net are the last places to look for performance.

Re:Who you gonna call?

[s122604]

Finally if you really need the raw power, use C or Fortran, seriously. Java and .Net are the last places to look for performance.

actually the > 1.6 incarnations of Java are fast and only getting faster, and there are real time implementations of the JRE if you really need them. As far as "power" (however that is defined), folks are doing some really interesting (especially in the news lately) things with large data set analysis and manipulation with products like Hadoop.

Re:Who you gonna call?

[ttucker]

The JIT compiler frequently optimizes code to run faster than than C++ because it knows statistical things at run-time that a static compiler could never know.

Re:Who you gonna call?

[DickBreath]

> Java and .Net are the last places to look for performance.

You obviously do not know about Java.

Since others have addressed other points, let me touch some not yet mentioned.

There are production servers running Java workloads with heap sizes in the tens or even hundreds of Gigabytes of memory, with 10 millisecond GC pause times. I mention that because someone always brings up GC. But JavaScript (node.js) has GC, so instead I'll ask whether you think node.js garbage collector can do that?

The JVM (java virtual machine) is one of the most amazing pieces of software engineering on the entire planet. It has some of the most sophisticated code ever written. It's JIT is an amazing dynamic compiler whose source language is the JVM binary code emitted by the Java compiler.

Now, imagine if your node.js could do this.

The VM notices that a particular function (A) is getting more than it's fair share of CPU, so the JIT compiles it to native code. During compilation, if function A calls function B many times, such as in a loop, function A may inline function B.

Now, on the JVM you can dynamically replace and reload binary classfiles in a running system. So suppose the binary file containing function B is reloaded. But now the compiled version of function A has inlined an out of date function B. No problem, the JVM ditches the compiled version of function A, and very shortly, based on real time continuous performance monitoring and statistics, it will notice that function A deserves to be compiled to native code, and repeat the whole process.

The JVM is perhaps one the best runtimes available for many different programming languages. It provides a huge number of highly evolved services right out of the box. GC. Binary portability. Native compilation at runtime, thus making the JVM bytecode portable. Choice of GC algorithms. Choice of JVM vendors, including ones with real commercial support for your Billion dollar business application. Remote monitoring tools and consoles.

Pick the right tool for the right job.

node.js has a very serious issue

[etash]

it's trying to be both a backend language and a HTTP server. like being both a chef and a waiter. Why would anyone want to re-implement a full fledged http server and pass through all the difficulties and ironing out bugs that commercial http servers went through ( apache/nginx ). IMHO it should just act like PHP and all other backend languages do and not try to do everything, leaving page serving to real web servers. It's just that they (joyent) are trying to sell ( "evangelize" ) their solution as better when it's not.

Re:node.js has a very serious issue

[gl4ss]

node.js is strong when you don't actually necessarily want nginx or apache sitting in between. for web services and alike it's nice. for serving the actual site you might want to go with nginx.. as for serving, it doesn't exactly do all that much so there isn't that much to configure or iron out.

Re:node.js has a very serious issue

[effigiem]

Nodejs is not trying to emulate PHP, because its intended usage is completely different - if you want to provide REST services for the frontend written in JS, why would you need to bother with passing stuff through apache? Not to mention that you can pass node through nginx. And in what world are the open source servers 'commercial http servers'?

Re:node.js has a very serious issue

[Xest]

I'm not really a fan of node.js (because it's redundant) but I think you misunderstand the point of node.js. If you're reimplementing a full fledged HTTP server with it then you're really using it wrong because it's not meant for tasks that heavyweight and really uses a different request processing model than that.

But I take issue with it because even in that role you can configure technologies like IIS, various JAS' and WCF to work in pretty much the exact same manner but with the benefit of being able to use languages and tools more well designed for large scale development on top whilst also having the benefit that these technologies automatically scale better than node.js and perform better to boot. WCF for example can be run in single threaded mode but such that it automatically uses a thread per core or processor, whilst with node you have to set up clustering to make it do this. Most of node's advocates make inflated claims of it being better than these sorts of server products for no other reason than they are inexperienced with these products and don't understand them and their flexibility.

Effectively node.js allows inexperienced developers to do something that people who understand IIS, many Java Application Servers, WCF, or even raw sockets programming have already been doing for many years already.

So to answer the OP's question I think as I say that in the enterprise node.js is really quite redundant. It doesn't do anything that can't already be done with better performing, more tried and tested, more scalable more enterprise friendly technologies already.

Effectively it's become popular because Javascript developers have had to start working on the server side and it's an easy jump for them, but what server side developers already have is much more secure, much better performing, and much better for development.

About the only valid argument I've heard for node.js is it means you can share code between server and client and write once as a result, but I'm not sure how useful this is in practice given that you'll normally be doing different things server side to client side and hence having different data structures and processing needs anyway. Technologies like Java and .NET make serialisation/deserialisation to/from JSON happen automagically anyway so it's not as if getting data structures between the two is any kind of chore.

If you already have server side developers who know their stuff then use them and don't waste your time with node. If you only have Javascript developers then use node.js until you can't. I say can't because Javascript's language design and node.js' limitations do make it increasingly more difficult to write anything of any real complexity after a point whereas C, C++, Java, C# all allow a much greater degree of scalability. It all depends on what developers you have currently and how far your needs are going to scale as to whether the deficiencies of node.js and Javascript will become a problem.

Re:node.js has a very serious issue

[Xest]

As the AC said I'm talking about code scalability - the ability for a codebase to grow without becoming unmanageable. This is difficult to achieve with Javascript because it's prototype approach and lack of decent support for things like namespaces, libraries and so forth coupled with the inherently greater difficulty of capturing many classes of bugs in a dynamic language and Javascript in particular means it's a nightmare getting a Javascript codebase to scale beyond a point when compared to something like C#, Java, or C++.

I think...

[gigaherz]

My oppinion is that Javascript is not bad as a scripting language, but we are abusing it and twisting it beyond its original purpose. The main issue is actually that Javascript is too flexible. Untyped code has an habit of hiding mistakes in hard-to-debug ways. But once you add types to Javascript, it's not Javascript anymore.

So, if you are working on a "pure" Web App, and you want to use one common language for the client code and the server code, then go on, use Node.js, add some packages for web services, database access, etc. and get it done. But if you want an environment that detects the mistakes as soon as you type them, runs relatively fast, can be statically verified, and still manages to keep a decent amount of flexibility, then there's nothing that compares to C#/dotNET.

I can not speak about anything more enterprise-oriented, but I assume the more oriented something is, the more rigid it becomes at thinking anything out of it's "ruleset" must be a mistake.

C++ is what it is. It's fast, mature, complicated, and flexible. If you want something done ASAP, don't use C++. If you want the result to be easily portable to other platforms, don't use C++. If you want the code to be safe (against hacking) without much effort, don't use C++. If you want the code to be easy to maintain, don't use C++. But in the end, it's your choice.

Re:I think...

[serviscope_minor]

Well, obviously the right answer for the OP depends on precisely what he wants to do. That notwithstanding...

C++ is what it is. It's fast, mature, complicated, and flexible.

Going for the less mature end of things, C++11 is now pretty much done (GCC has almost full support, LLVM is close and amazingly even VisualStudio has most of the goodies).

It also ain't you father's C++.

It has taken great strides in the areas such as making the safe thing easier and quicker to write and generally less hassle and less faff all around. Additionally, the quality of implementation of things like the standard libraries has improved beyond measure. In the areas of security, other than making the secure things easier to write, between address space randomization, getting GCC to instrument pointer accesses and the NX bit, the space for exploitable (but not obviously DOSable) holes has shrunk considerably.

C++ has changed immeasurably immeasurable since what was practical in 2003. That's not to say of course that C++ won't let you do bad things. Of course it will. But they're not all the easiest way of doing things now :)

Still, like any material (I have seen an excellent argument that languages are more like materials than tools) one has to choose an appropriate one for a particular job. Given that I can't really tell what the OP is trying to do, it would be hard for me to commit to a given language...

I'm not going to claim C++ is simple. That would be silly, but a rather fun fact is that the despite Java being promoted as simpler than C++ for so many years, the latest Java language spec (excluding libraries) is shorter than the latest C++ spec (excluding libraries).

Re:I think...

[gigaherz]

I must assume you have never used C# 4.0, at least not in any serious way. The language, the class library and the VM are all vastly superior in performance, features, and flexibility. Yes, Java has some advantages, mostly that there's a java VM for any device (although Java lost the ME market share, so the number isn't as big as it used to be), over overall? It can't compare.

Errmmmh ... what was your question?

[Qbertino]

Sorry, your rambling - that is supposed to be a question I presume - is a tad incoherrent. But I do think I catch your overall drift, so I'll chime in:

I think the overall issue is basically about programming languages. Wether it's some software runtime enironment or the other - in the case of JS Node.js just happens to be the first to revive JS on the serverside.

To the case:
Wether or not a PL takes over is dependant on things that usually have nothing to do with the PL itself. Once a PL is sufficient enough .... ok, scratch that. Take for instance PHP. PHP was a joke when it becam popular. 2 guys had a thing called Zend engine and they decided to craft it around a Perl based templating "language" that was becoming popular - mostly because Perl is quite bizar to handle and it was the most popular web scripting language back then. They built PHP 3 based on the zend engine, then a mod-php was added for the popular webserver Apache and the rest is history. All things went web, as a result we have PHP pissing into serious Java territory today. I remember when PHP was a joke and JSP seemed to be posed to rule the webworld for decades to come. That didn't happen, mostly due to political reasons. ...
Had Netscape released their webserver as FOSS back in the mid-90ies, we'd all be using JS as serverside language ever since, since JS was the serverside language on the Netscape Enterprise Server.

I think compiled languages are impractical for web environments, for reasons everyone can come up with, so that rules out C and C++. For every environment that is set up from scratch I can't think of a single expert that would recommend .Net. .Net exists because it banked on the existing Windows/MS legacy. The MS CLR may be a neat feat, but it is a MS lockin trap, and today it's mostly pointless, since abundant server power, virtualisation and simular things have made optimisation concerning multiple runtimes on one setup a non-issue.

This leaves us with JIT/bytecode compiled or interpreted languages. Here I see Java vs. all the rest (Python, PHP, JS, Ruby, etc.). It's basically Java vs. FOSS languages. Java *is* a FOSS language by now, but the problem is that Oracle is a very bad herald for FOSS Java, and the FOSS alternative, OpenJDK/SDK is bad/slow.

For the future of web I do see Node.js gaining lead position. Google put serious cash into aquiring V8 technology, improving it and putting it into Chrome. Flash was killed by Steve Jobs/iOS, pushing brilliant no-Flash-allowed devices (iPhones and iPads) into millions of end-user hands, so Google had to come up with a serious alternative. Hence JS/V8.

Not being stupid - selling software is *not* Googles business - they released the impressive V8 engine as FOSS, and some smart people put in the effort to port that engine to the serverside, where it is about to kick PHPs and Rubys ass, simply because it's at least as good as either of those *and* it is the same primary non-lockin language on the serverside as is on the clientside. Mind you, clientside JS only became popular once a guy wrote a famous blog article in which he renamed "doing important smart things with JavaScript" into "Ajax", which is a cool name and thus made JS on the clientside popular with a lot of people who formerly had no interest in looking into JS seriously. We have the same effect when some smart guy decided that plain Java objects weren't used and other things like EJBs were more popular simply because regular Java objects didn't have a cool name. So he named them Pojos (Plain Old Java Objects) and solved the problem. Any serious respectable Java toolkit today uses Pojos at its heart.

Bottom line: Wether a tech or PL catches on, gains traction and becomes the next big thing is usually rooted in issues one would not think as relevant right away - things like 'Does the tech have a cool name?', among others. That sa

Re:Errmmmh ... what was your question?

[Capt.Albatross]

What's the V8 Javascript engine written in?

'nuff said.

Code it in C or get out of the way and let a real programmer finish the project.

What does the machine actually execute?

'nuff said.

It depends on what you have and what you need

[stikves]

The short answer is: it depends. The longer answer is slightly more complex. It depends on the problem you have, the knowledge of your programmers, and the server environment you'll deploy.

If most of the developers in your house are web developers, and have extensive knowledge on JavaScript, then node seems to be a more organic solution. However as others pointed, JavaScript has been abused to code everything from databases to ray tracers, but you should keep real world performance in mind. For most tasks node (backed by Google's V8 engine) will be 2x to 10x slower than an optimized C/C++ program in the real world. You're basically trading developer performance for runtime performance.

Additionally using a dynamic language, especially modern JavaScript requires discipline. If you do not have a proper packaging or testing systems you'll run into problems. Fortunately node community already prefers doing things the modern way, so this should not be a concern for most (sane) people.

On the other hand, one should never discount the performance benefits of C++. For our latest project we converted one of the smaller, but very CPU intensive services from PHP into C++. This offered an order of magnitude performance increase (going from a minute to a few seconds). So use your common sense, and all available tools on hand depending on situation.

As for Java, and C#, you'll have a performance similar to C++ (same to 2x slow), as long as you have sufficient amount of RAM (a recent paper I read cited 6x RAM requirement for a GC to function properly). The only concern is that for C#, you'll most likely want to stick to Microsoft ecosystem (Visual Studio is a great development environment, but you'll have to deploy to Asure, whereas you have more choices with Java, including Amazon and Google Linux clouds).

The bottom line is: look at the task at hand, and the people you have to choose the tools. And do not be afraid to experiment -- especially early on in the project.

Re:It depends on what you have and what you need

[stikves]

The paper is at the following link: http://www-cs.canisius.edu/~hertzm/gcmalloc-oopsla-2005.pdf

I ran into it while reading the discussion at http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/

Re:It depends on what you have and what you need

[mystikkman]

> The only concern is that for C#, you'll most likely want to stick to Microsoft ecosystem (Visual Studio is a great development environment, but you'll have to deploy to Asure, whereas you have more choices with Java, including Amazon and Google Linux clouds).

Err what? You can deploy to hundreds of hosting providers... including AWS.

http://aws.amazon.com/windows/

Re:My 2 cents on Node.JS

[Required Snark]

The Google V8 JavaScript engine used in Node has a JIT compiler that runs native machine code.

http://en.wikipedia.org/wiki/V8_(JavaScript_engine)

V8 compiles JavaScript to native machine code (IA-32, x86-64, ARM, or MIPS CPUs) before executing it, instead of more traditional techniques such as executing bytecode or interpreting it. The compiled code is additionally optimized (and re-optimized) dynamically at runtime, based on heuristics of the code's execution profile. Optimization techniques used include inlining, elision of expensive runtime properties, and inline caching, among many others.

I know that facts are not fashionable on Slashdot, but please make the minimum effort for a reality check before you mindlessly repeat whatever drivel you've been listening too. I don't know about the Python requirements, but given your misinformation about V8 you are most likely wrong about that as well.