Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

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

Soulskill posted about a year ago | from the go-with-the-trendy-option dept.

Programming 304

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?"

cancel ×

304 comments

Sorry! There are no comments related to the filter you selected.

Who you gonna call? (5, Insightful)

skovnymfe (1671822) | about a year ago | (#44235501)

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? (3, Insightful)

Kjella (173770) | about a year ago | (#44235521)

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? (4, Informative)

sproketboy (608031) | about a year ago | (#44235897)

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? (1)

Anonymous Coward | about a year ago | (#44236215)

The day node.js has a multi-threaded memory model and the layers/services that .net or Java libraries provide - and a steadiness which guides features/bugfixes/regular development, it'll get there.

Re:Who you gonna call? (1)

skovnymfe (1671822) | about a year ago | (#44235523)

Unless of course you're sitting on a 100+ strong team of developers capable of forking the project off in the direction you want it to go, and then maintaining it for you. But then it's not really node.js anymore, is it?

Re:Who you gonna call? (0)

Anonymous Coward | about a year ago | (#44235549)

This argument didn't fly back in the MS anti-Linux FUD days and it doesn't fly now. More importantly its not even true, you have providers like StrongLoop, The Node Firm, and Iris NPM you can go directly to. I'm not a huge fan of node.js but your reasoning is worst reasoning...

Re:Who you gonna call? (0)

Anonymous Coward | about a year ago | (#44236221)

You can say it doesn't fly all you want, but that doesn't make it true. He's right.

Re:Who you gonna call? (0)

Anonymous Coward | about a year ago | (#44236271)

Actually it does, or more accurately did, fly. That's why companies like Red Hat and The Node Firm exist.

Re:Who you gonna call? (1)

gl4ss (559668) | about a year ago | (#44235563)

you're not gonna call anybody except your own guys. you can contract companies for node.js if you think that covers your ass.

and an answer to the plumbing question.. go check npm. plenty to choose from and that's maybe the problem, but there's plenty of different so called plumbing solutions should you need one. it's farm more likely that node.js just plays a front end role in any large solution and linear backend stuff that takes longer time etc happens elsewhere - or perhaps in another spawned node.js.

node.js is a handy scripting tool though.

Re:Who you gonna call? (0)

Anonymous Coward | about a year ago | (#44235601)

When node.js goes to shit and your enterprise class software worth millions or even billions of dollars is ruined, who you gonna call?

Ghostbusters!

Or maybe that should be FUD-busters.

Re:Who you gonna call? (3, Insightful)

Tridus (79566) | about a year ago | (#44235659)

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? (4, Insightful)

sproketboy (608031) | about a year ago | (#44235909)

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? (1, Interesting)

Xest (935314) | about a year ago | (#44235963)

He's probably talking about the .NET connector which allows Oracle databases to be consumed by .NET framework features like the EF or to integrate with tools in visual studio.

But either way what he says shouldn't ever happen. The .NET connectors don't just randomly break unless you upgrade to a version that's broken. If you test and integration test and everything works then don't upgrade without regression testing. If you upgrade and don't regression test and it breaks then it serves you fucking right.

The GP's problem is one of a poor development, testing and go live procedure.

Re:Who you gonna call? (4, Insightful)

Tridus (79566) | about a year ago | (#44236053)

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? (1)

Xest (935314) | about a year ago | (#44236355)

It's not like database communication is the sort of thing that's not well understood and isn't fairly easy to build a solid test suite for. It's even easier for the consuming developer to test their own use of the even smaller subset of the features their product requires too.

So yes these sorts of things tend to be extremely unlikely to result in bugs that just pop up out of nowhere. Where it is a possibility the occurrence is so small as to not be a factor in overall language/technology stack choice because there are much bigger factors to worry about.

If this is prominent enough to be a concern in your choice of technology/stack then yes you're definitely doing something wrong.

Re:Who you gonna call? (2)

Ugot2BkidNme (632036) | about a year ago | (#44236201)

A few weeks ago I got called in by a client to talk to a 3rd party vendor of theirs regarding some problems they were having. Turns out the 3rd party vendor was Oracle. interestingly enough Oracle was providing a .Net solution running on Oracle DB to our mutual client. I was a bit shocked. Turns out Oracle does a lot of .Net development. So given Oracle and MS mutual business interests I have no doubt .Net working with Oracle DB is a priority.

Re:Who you gonna call? (2)

dwpro (520418) | about a year ago | (#44236823)

It seems like a half-ass attempt at best by Oracle, though it's been getting better since Microsoft quit supporting the Oracle drivers themselves. You still have to install the fairly unwieldy Oracle Client on all front end servers to access the database (though I believe they are working on a portable library). The ODP.net client doesn't do automatic cursor mapping, and if you want to use it, Oracle seriously recommends to hand/hard code into your base configuration file xml mappings for cursor return types on stored procedures. And they still refuse to provide a boolean type (except in pl/sql). Quite annoying still, but better than the old days.

Re:Who you gonna call? (1)

NJRoadfan (1254248) | about a year ago | (#44236519)

Years ago I developed a .NET program that connected to a MySQL database using its ADO.NET connector. It was painful, but it worked. Hopefully things have improved since than.

Re:Who you gonna call? (4, Informative)

angel'o'sphere (80593) | about a year ago | (#44235857)

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? (1)

mjwalshe (1680392) | about a year ago | (#44236275)

well back in y2k days at British telecom Oracle was as much use as a chocolate teapot in a lot of cases and we paid a metric fuck ton of cash to them.

node.js has a very serious issue (4, Insightful)

etash (1907284) | about a year ago | (#44235531)

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 (3, Informative)

gl4ss (559668) | about a year ago | (#44235573)

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 (0)

Anonymous Coward | about a year ago | (#44235639)

or skip apache, nginx and node.js and go straight for lighttpd

Re:node.js has a very serious issue (0)

Xtifr (1323) | about a year ago | (#44236097)

Or skip having a separate, standalone server, and just embed libmicrohttpd [gnu.org] directly in your app.

Re:node.js has a very serious issue (2)

Flammon (4726) | about a year ago | (#44236273)

That's essentially what node.js does.

Re:node.js has a very serious issue (3, Informative)

effigiem (2558315) | about a year ago | (#44235577)

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 (2, Insightful)

Anonymous Coward | about a year ago | (#44235645)

IBM HTTP Server comes bundled with all versions of IBM WebSphere, and really, it's just Apache. So yeah, in our world free software is indeed used in the Enterprise (or: 'commercial http servers'). In OS-space you've got RHEL and Suse Linux Enterprise, at the very least.

In some cases, even in Enterprise solutions, it does make sense to use free software rather than roll everything in-house, especially when http-serving is not really your core business model.

Re:node.js has a very serious issue (2)

Zeromous (668365) | about a year ago | (#44236191)

Agreed. In enterprise it's not what you bought which determines support, it's who you bought it from and for how much.

Re:node.js has a very serious issue (5, Insightful)

Xest (935314) | about a year ago | (#44235933)

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 (0)

Anonymous Coward | about a year ago | (#44236641)

node.js is already near perfect horizontally scalable. I'm wondering what you mean by "scalability".

Re:node.js has a very serious issue (1)

FooBarWidget (556006) | about a year ago | (#44236007)

That is exactly the problem that Phusion Passenger [github.com] solves. It is a Node.js application server, built on Nginx, and not only provides world-class HTTP management but also things like auto-scaling processes, supervisoring, load balancing, resource management, etc.

I think... (5, Interesting)

gigaherz (2653757) | about a year ago | (#44235559)

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..Typescript is the answer (1)

Anonymous Coward | about a year ago | (#44235575)

Typescript is the answer here if you love JS.

Re: I think..Typescript is the answer (1)

MrBandersnatch (544818) | about a year ago | (#44235633)

I hate JavaScript but I've been using CoffeeScript for a project and I've been reasonably impressed at how it removes many of the worse parts of JS - how does TypeScript differ/improve on Coffee?

Re:I think... (0)

Anonymous Coward | about a year ago | (#44235587)

"use strict"

Re:I think... (0)

Anonymous Coward | about a year ago | (#44235641)

That does not give you type checking, but only that variables have been declared.

Re:I think... (4, Informative)

serviscope_minor (664417) | about a year ago | (#44235653)

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... (0)

Anonymous Coward | about a year ago | (#44235685)

C++11 certainly makes programming a lot faster. With Duetto [leaningtech.com] you can even compile it to JavaScript and have it talk to your C++ server.

Vert.x [vertx.io] is a project that is in between J2EE and Node.js.

Re:I think... (0)

Anonymous Coward | about a year ago | (#44235727)

My oppinion is that Javascript is not bad as a scripting language, but we are abusing it and twisting it beyond its original purpose.

I disagree [destroyallsoftware.com] with that sentiment. Like PHP [veekun.com] it gets used a lot and for that reason plenty people think it must be good for something, right?

Well, uhm, no. Wide availability and popularity do not a good language make. You have a point about the stretching but I disagree that it was any good to start with. Merely really, really widely available. And apparently well-suited for the kind of non-thinking that abounds in its niche. Which makes it enterprise-y [thedailywtf.com] , in a sense.

Re:I think... (1, Insightful)

Anonymous Coward | about a year ago | (#44235843)

If you want something done ASAP, don't use C++.

Neither C#. You'r better go with Python.

If you want the result to be easily portable to other platforms, don't use C++.

LMFAO. Don't use C#. DO use Python, C, C++ or Java, but not C#.

If you want the code to be safe (against hacking) without much effort, don't use C++.

If you want your code to be safe, write it carefully. Learn what makes code unsafe, and don't be an ignorant.

If you want the code to be easy to maintain, don't use C++.

If you want your code to be easy to maintain, write it following sound engineering principles:
* don't optimize until you need to.
* use established patterns when they make sense.
* don't make it more complex than it needs to be.
* write as little code as possible, and as simple as possible.

So, to sum up: Don't be an ignorant, and don't use C# for portable code.

Re:I think... (0)

Anonymous Coward | about a year ago | (#44236265)

Never heard of mono? There's nothing wrong with writing portable code in C#. Not anymore than doing the same with Java.

Re:I think... (0)

Anonymous Coward | about a year ago | (#44235867)

Well you could just use Python instead of C++.

And C# is portable to other platforms?? (0)

Viol8 (599362) | about a year ago | (#44235889)

Mono on linux is pretty much dead so C# is more or less a Windows only language now making it a locked in dead end for developers who don't want to be tied to the MS upgrade treadmill all their working lives.

As for your other points, C++ is easy to maintain if you're competant in the language and as for hacking - remind me what happens if there's a vulnerability in a VM? Oh thats right , every single fucking program running on it is potentially screwed , thats what.

Re:And C# is portable to other platforms?? (1)

gigaherz (2653757) | about a year ago | (#44235947)

No, if you want easy portability you use Java. That's the only good thing I see in Java. I just forgot to mention it.

Re:And C# is portable to other platforms?? (1)

gigaherz (2653757) | about a year ago | (#44235961)

Also, if there's a bug in the VM, you can update the VM, and every single app is back to working well, while a bug in a statically linked runtime, or in user code, requires every app with that bug to be fixed separately, or at least recompiled.

Re:And C# is portable to other platforms?? (1)

Anonymous Coward | about a year ago | (#44236183)

You mean you can update the VM if somebody in the community offers a fix or if you have the competency to fix it yourself. If neither condition is present you're screwed. Your VM problem might not be a priority to anybody else, and in my experience you are much more likely to be able to fix problems in your own code than in a 3rd party offering.

Re:And C# is portable to other platforms?? (1)

flimflammer (956759) | about a year ago | (#44236331)

Why is mono dead on Linux?

Re:And C# is portable to other platforms?? (0)

Anonymous Coward | about a year ago | (#44236683)

It is for sure not dead, I 've used it recently.

Re:I think... (0)

sproketboy (608031) | about a year ago | (#44235951)

You had me until "there's nothing that compares to C#/dotNET." Er JAVA which is 10 times better?

Re:I think... (3, Interesting)

gigaherz (2653757) | about a year ago | (#44235985)

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.

Re:I think... (1)

gigaherz (2653757) | about a year ago | (#44235989)

s/over/but/

Re:I think... (0)

Anonymous Coward | about a year ago | (#44236303)

Haha. Oh man, that was a good one. ... ...Wait, you weren't joking?

Re:I think... (1)

flimflammer (956759) | about a year ago | (#44236401)

Er, no?

A mixed bag, for sure (0)

Anonymous Coward | about a year ago | (#44235605)

JEE/C/C++/.NET is a diverse group of stuff with diverse capabilities. You've mixed in JEE and .NET, which will both give you all you could ask for with straight up C. Easiest way to turn C into a packaged web thing is probably using JNI or P/Invoke and let the non-C side handle that part. As for your question about node.js, I don't know. I'll say the obvious: the tooling is less mature. If it lets your developers share responsibility for and code between client and server portions that's great. JavaScript is very versatile; in some ways it outdoes Perl in the more-than-one-way-to-do-it sense. But Perl isn't hot now. That's probably your biggest risk with node.js: popularity, rather than app packaging. That some day not far from now you'll stick a job ad up and when the respondents hear node.js and server-side JavaScript they'll hold their noses, mutter something about it not being 2013 anymore, and walk out. If your maintaining your application in five years is a bigger concern than rapid deployment I would avoid node.js until there is a more permanent community of developers, regardless of what answer you find to the question you asked.

Just say NO (0)

Anonymous Coward | about a year ago | (#44235611)

We tried both large scale Ruby and Node.js deployments, and it was simply horrible to maintain and we got bitten by very-hard-to-find bugs due to the lack of a type system. Don't go there for serious stuff.

Re:Just say NO (1)

MrBandersnatch (544818) | about a year ago | (#44235637)

Interesting, would you care to expand?

Re:Just say NO (1)

murdocj (543661) | about a year ago | (#44236101)

I can 't comment on Node.js but I can see what large scale Ruby would be a problem. Because Ruby is so dynamic (classes and objects altered on the fly, not static typing, etc) there's simply no way to detect errors up front. Basically Ruby throws out everything that's been done over the last 50 years to make software development safer and more predictable. It's an interesting language, but for large scale development you're going to run into problems and hard to find bugs, as the GP mentioned.

Re:Just say NO (1)

Anonymous Coward | about a year ago | (#44236237)

Yes, and the exact same issues apply for Javascript I'm afraid.

Re:Just say NO (0)

Anonymous Coward | about a year ago | (#44235737)

WebODF [webodf.org] uses Closure Compiler [google.com] to do type checking and has lots of unit tests. This rigorous checking is essential if you want to write a serious project in pure JavaScript.

Apache-Quality Library & Framework Environment (1)

Anonymous Coward | about a year ago | (#44235615)

Seems illogical but the fact that there's a lot of dynamics in the node environment can hit back in Enterprise Projects. In Enterprise I need Libraries and Platforms where I can be absolutely (=100%) sure that noone breaks compatibility, noone stops maintaining the code, noone stops fixing security and stability bugs, noone stops properly documenting changes etc. in _all_ the libraries and toolkits used in the project. "The Apache Way" is a major factor in being able to maintain and run a large Enterprise System for a decade or more and Mircrosoft is also excellent at ensuring stable internal APIs for a very long and plannable way.

Don't do it (1)

Anonymous Coward | about a year ago | (#44235635)

Javascript is a horrid scripting language, we should get rid of it on browsers and not to use it on servers.

Errmmmh ... what was your question? (5, Interesting)

Qbertino (265505) | about a year ago | (#44235643)

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 [adaptivepath.com] 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 said, for the reasons stated above, I do think JS on the serverside (and thus Node.js in particular) does have a good chance of ruling the serverside future of the web. Add in nginx overtaking the conceptially dated Apache Webserver setups, and you have a safe bet.

My 2 cents.

Re:Errmmmh ... what was your question? (0)

Anonymous Coward | about a year ago | (#44235715)

yes.. in customize product everything need to fast update.. compile version or restart webserver just for updating file is a joke.
If before people might force to use remote desktop with single application to overcome update problem. Many Point Of Sales using this concept.
Ya,php is joke but i like it because fast to code..

Re:Errmmmh ... what was your question? (1)

leuk_he (194174) | about a year ago | (#44235765)

If the question is about languages?

maybe the question is about frameworks instead. A framework is a set of libraries for a certain language. E.g. The language is java, the framework is J2EE.
For C/C++ the question leave it open, but i think C/C++ should be mainly used for support/intermediate software, and not for the business logic.
Node.js is not a complete framework, you need to add things to make it complete. .Net is not a language, but mulplie languages can use the .Net framework.

In a enterprise you have your enterprice level software (SAP/Dynamics/mainframe), your set of your supporting application arround it, glue software (SOA... nowadays, ftpíng files arround 10 year ago). And nowadays you glue some sort living mobile app to it that has some glue to the backbone applications. Each has its onw langueage and support. Minimizing the number of platform/languages will make your life simpler.

Re:Errmmmh ... what was your question? (1)

The Cat (19816) | about a year ago | (#44235881)

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.

Re:Errmmmh ... what was your question? (4, Informative)

Capt.Albatross (1301561) | about a year ago | (#44235983)

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.

Re:Errmmmh ... what was your question? (0)

Anonymous Coward | about a year ago | (#44235899)

I think compiled languages are impractical for web environments, for reasons everyone can come up with, so that rules out C and C++.[...]

Can you expand on that briefly? Serious question.

Compiled languages (1)

Viol8 (599362) | about a year ago | (#44235939)

"I think compiled languages are impractical for web environments, for reasons everyone can come up with, so that rules out C and C++. "

Yes - C & C++ are complex, hard to learn and require a deeper understanding of a computer than browser documents, which pretty much rules out web "developers" being able to use them. Is that one of the reasons you were thinking of?

Re:Compiled languages (1)

Xest (935314) | about a year ago | (#44235975)

Hey not all of us are bad, I'd say I'm a "web developer" because it's mostly what I do, but I use C/C++ for some server products because when performance and flexibility matters it's not like I'm going to use a toy such as node.js.

I absolutely agree with you and think node.js is redundant for this very reason, everything it does can be done in languages like C and C++ and in fact if you want to do anything that requires performance you have to drop back to C with node.js in the first place which begs the question, why bother with it at all?

The fact is node.js is just a tool to get Javascript developers up and running on the server. If you know, or are willing to learn languages other than that it's of no value because they already offer better options.

Re:Errmmmh ... what was your question? (1)

Capt.Albatross (1301561) | about a year ago | (#44235959)

Sorry, your rambling - that is supposed to be a question I presume - is a tad incoherrent....

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...

It depends on what you have and what you need (5, Insightful)

stikves (127823) | about a year ago | (#44235689)

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 (1)

Dambiel (115695) | about a year ago | (#44235891)

GC = Garbage Collection? Six times the RAM req's?

Sounds high but possible, can I get a link or citation on that article? Sounds like a decent read.

Re:It depends on what you have and what you need (1)

antsbull (2648931) | about a year ago | (#44236715)

Theres also research out there showing that GCed Java can often significantly outperform C/C++ during memory management. I find it hard to believe that you require 6 times the space to run a GC though - it probably depends on what algorithm you are forcing it to use.

Application for mobile devices? (2)

aglider (2435074) | about a year ago | (#44235717)

First of all, the fact that the application is for mobile devices it doesn't say anything.
Is the application you are mentioning runnint into the mobile device? Or is it a web application for mobile devices?
In the former case, I think you need to stick with the device architecture constraints, like ObjectiveC for Apple mobile stuff.
In the latter case, the choices is up to the developer team and what they know better.
I would personally choose C++ with Wt [webtoolkit.eu] . But that's just me.

So, please, explain better your problem.

List (0)

Anonymous Coward | about a year ago | (#44235775)

https://github.com/joyent/node/wiki/Projects,-Applications,-and-Companies-Using-Node

Node.js is new (1)

jayklub (2633869) | about a year ago | (#44235783)

Honestly I think it's because most medium->large corporations are established entities with established codebases. It probably has more to do with switching technologies on an established product is difficult. In the next 5 years you'll probably see more medium->large companies using Node.js only because they grew to that size with it.

What is best for the Job (1)

GrimMethos (2978897) | about a year ago | (#44235787)

You need to use what is best for the job, there is a reason we have so many different programming languages. Do some research (it does not look like the OP has done all that much) and pick what fits the situation and your company can support with knowledgable people. You have to remember it is ECMAScript and has been around for about 15 years so it has had time to change and evolve. There are large enterprises using nodeJS, like LinkedIn using it for the server interface for their mobile application. When you talk of maintainability it is javascript, there are A LOT of people that know javascript, not to be confused with people that know jQuery but I wont go into that. If you are looking for prebuilt things, look at npm it is a package manager for node so there are a lot of packages out there for things from i2c and bluetooth controllers to full web frameworks and test suites. They even have stuff for cli utilities.

The Enterprise (1)

loufoque (1400831) | about a year ago | (#44235817)

I'm pretty sure the Enterprise doesn't use JavaScript. It either uses C or a Starfleet-specific language.

Use Ada (0)

Anonymous Coward | about a year ago | (#44235825)

Seriously, I'd use Ada instead. Strong static typing will catch 80% of all errors at compile time, it will work in 20 years from now and can easily be interfaced with C.

I know that some people think this is a joke, but Ada is really the best choice for sustainable business. Even if you disagree with that, it surely is better than Javascript.

Nope (0, Flamebait)

The Cat (19816) | about a year ago | (#44235837)

Javascript is not a real programming language. Put away your toys and do your job.

dart (1)

gedw99 (1597337) | about a year ago | (#44235853)

i used have used nodejs and c# and java extensively.

Now i have moved across to DART.

I get the IDE, tye aheadand OOP of c#, with the ability to deploy to Browsers as JavaScript.
For deployment scnenarios where the environment is controlled we can deploy as Dart.
The next version allows "edit and continue" in the IDE also.

Dart can interoperate with plain JavaScript and with c++ if required also.

JEE? (1)

smitty_one_each (243267) | about a year ago | (#44235871)

No: GTE.

Deliberate trolling (0)

Anonymous Coward | about a year ago | (#44235877)

Why is there a new article every week about the legitimacy of JS around here?

There's no right answer, and slashdot is geared towards a slightly 'old-school' crowd, and the answer is obviously going to be, it doesn't matter what you write it in, you're code is going to suck, be late, and you're going to quit in a year, and it's going to be someone else's problem.

Look at resumes for programmers in your area/budget. Meet a few. Decide if you think you can find a node.js or a Java programmer or whatever programmer. Decide what community you want to get into bed with, and do it.

We don't need a blog post or a question or a whatever every 20 seconds about whether or not Ruby or C or assembly or Lisp or VB or Lua or whatever else is legitimate for a project or not. You can find out pretty easily what people are using, look at other companies job listings. Someone's gotta be first for a newer technology, decide if you and your team are up for it. Otherwise, follow the status quo, and stop starting flamewars.

PS, a technology is never going to solve your real problems, which is making the right thing, communicating with the right people, and staffing people to make the right thing. This question is a waste of time.

I only see one majour problem/challange (1)

angel'o'sphere (80593) | about a year ago | (#44235885)

Node.js is a JavaScript platform. So you need languages that ultimately compile down to JavaScript (like CoffeeScript, or you can abuse the GWT compiler and use Java).

The problem with JavaScript is weird syntax for real oo programming on one side and dynamic typing on the other.

Dynamic typing means you have to have a very gout test harness and really unit test nearly everything.

I also would not wonder if you might get into new security risks. After all the server is a bunch of not compiled text files ... If you have an exploit way where input "gets evaled" you have arbitrary code running on the server. That means avoid eval() totally and make sure it is indeed avoided and/or have thought out input validation. And again: test for that!

Wheel reinvented once again (1)

Anonymous Coward | about a year ago | (#44235995)

Node.js seems to be the usual churn. Let's throw out decades of J2EE experience and start over! We'll write a new MVC framework! And a new ORM framework! Let's rewrite everything from scratch and make it similar to but different from everything else.

This churn has got to stop. It's gone far beyond innovation or new technology and is just change for the sake of change. There is no reason for every platform to have its own ORM framework (Android's unnamed one, Core Data, Hibernate, EF, etc) and MVC framework. There's no reason for so many languages that are all similar to C and Java, but different. (C#, designed by the Turbo Pascal creator, uses WriteLine, while Java, a C++ syntax clone, uses Pascal's WriteLn? Really?)

The time has come to get back to industry standards in the technology world instead of extreme Balkanization.

Re:Wheel reinvented once again (1)

Tridus (79566) | about a year ago | (#44236091)

Amen.

Seems like there's a cycle in this field where people forget everything that was already learned and have to learn it all over again by reinventing everything.

UI designers seem to be doing the same thing by throwing stuff away and giving all new everything instead. That gave us Metro. We'd have been better off if they hadn't bothered.

Re:Wheel reinvented once again (1)

Cereal Box (4286) | about a year ago | (#44236283)

I don't think it's change for the sake of change necessarily. You've got to remember that this stuff is created by a young generation that's just entering the workforce. They see existing technologies as old and crufty. Declaring types? Get with the times grandpa!

Plus, there seems to be a fascination with making code as terse as possible...

Don't compare compare apples to oranges (1)

RichSad (1167605) | about a year ago | (#44236011)

There is no "one right answer" as to which enterprise platform is best. Every project has a unique set of requirements and constraints. Each team consists of some group of people with some body of skills/experience. I have found it best to avoid getting religiously attached to any architecture or platform. I ask myself and my team "how do we best solve the problem the business has and deliver a great experience to customers?" I am currently engaged on a project where despite having C#/.net and PHP on LAMP stacks already in production at a large entertainment company, we opted to use node.js for a specific use case. The proof will be in the pudding after years in production, but so far node.js, CoffeeScript, MongoDB and Redis seem to be the right tools for this set of requirements. That said, I would not attempt to use node.js to cover all the use cases you specify in the original post. There are certainly people that would argue it is suitable for that, but I would not be one of them. Last thought is do a little research and see who IS using node.js and talk to them. I did this as part of my due diligence on this project. I also talked to those adamantly against using it. You have to decide what offers the right risk/reward ratio for your specific project. You will most likely end up with different tiers of your enterprise back-end with different tools for different needs.

Ok for Front Office, less for Back Office (1)

merty (203292) | about a year ago | (#44236043)

In our company, we are exploring the use of node.js / javascript as a substantial part of our development strategy. What most people tend to forget is that most enterprises really don't like to develop anything but buys everything out of the box, looking closely what their competition is buying and using. We don't develop CRM systems on our own, we don't develop a billing system, we don't develop any ERP like system. We buy SAP, Siebel, Microsoft Dynamics and other programs to do this. We are not an IT software development company, it is not our core business nor do we have experience enough in house to start these kind of risky projects.

However, what we will do, is "customise" and integrate the whole landscape of applications and have a single "online presence". In this area we do have a lot of development, consisting out of an enormous amount of relatively small changes. Most of these changes has to do with marketing campaigns, online web / applications and simply GUI or input validation logic, so to say the "Front Office" without much of business logic or processes. Most of these changes are temporary or very tailer made for a specific product and requirements will be altered during build... In the past, developers altered the "standard" back office applications for this, resulting in non-upgradable software and lots and lots of scattered code in ABAP, C#, Java, SQL and what else these applications uses. Just in case for these kind of changes, it is better to have this contained in one single environment. For this environment we had two choices: Java application server or Javascript Node.js. Both are sufficient for this kind of development. It is easier/cheaper to get Java programmers, however, since most of our changes are directly related to online/web stuff, most online developers do understand and know about javascript. Again, we didn't need the performance, en most of the changes are very, very simpel solved in a few lines of javascript using standard node.js functions and libraries. The only thing you have to be aware of is to choose one kind of framework and version & release system.
We have measured projects doing it the "java way" and doing it the "node.js way", en we came to the conclusion that node.js projects delivered faster results with same quality. Not that much, but more like 10 java design/coding/testing mandays is comparable with 8 node.js mandays.

The only issues we are facing is the availability of "real" javascript developers, keeping quality good enough and the terrible or often outdated documentation surrounding node.js libraries or components.

Node.JS: The Good Parts? A Skeptic's View (1)

Anonymous Coward | about a year ago | (#44236079)

I found this video to be helpful - as told by a guy who is from the Java EE world who did not like Node.JS to begin with but now sees it as being useful -

Node.JS: The Good Parts? A Skeptic's View [youtube.com]

LinkedIn uses Node (2)

Required Snark (1702878) | about a year ago | (#44236095)

Any debate on whether Node is "good enough" is already obsolete. It's being used by real companies, not just unknown overly hip startups.

LinkedIn Moved from Rails to Node: 27 Servers Cut and Up to 20x Faster http://highscalability.com/blog/2012/10/4/linkedin-moved-from-rails-to-node-27-servers-cut-and-up-to-2.html [highscalability.com]

Having said that, I've started using Node in a limited way and it is obviously immature. NPM is a mess. There are far too many almost the same packages, and no obvious way to choose between them without reviewing the code. A package may not be compatible with the latest release, but there is no way to tell without installing it to try it out. These are signs of a still evolving ecosystem.

Still, it's only a matter of time until the rough edges are smoothed out and Node becomes accepted as a legitimate server side alternative.

Re:LinkedIn uses Node (1)

RoverDaddy (869116) | about a year ago | (#44236261)

A package may not be compatible with the latest release, but there is no way to tell without installing it to try it out.

This is the first thing I ran into as a newcomer to Node. Not just packages but programming techniques. You're trying to learn how to do something trivial for the first time, so you hit Google and then drop into Stack Overflow and find plenty of questions and answers about your very problem. Then you try to use the solution and it falls apart. That's when you look back through the comments and you discover, "Oh yeah, I wrote that answer / released that package for Node 0.4.x: it really doesn't work anymore, sorry."

This isn't really an indictment of node, because I see this now wherever I look into the Web world (coming from the C/C++ world). So much immaturity (in the literal sense). Everything: HTML, CSS, Standards, Real-world browser support for said standards, VMs, best practices for JavaScript, tools like Dojo, Node, etc. all in flux. Documents that describe the "deprecated" old way, the new "approved" way, and the "better" way that doesn't work yet but will when the next revision is coming out (date TBD). A little more stability would go a long way.

Re:LinkedIn uses Node (1)

Laz10 (708792) | about a year ago | (#44236529)

LinkedIn uses it for their mobile backend.
But I more than suspect that the mobile backend is just a simple frontend to the real backend. And that is written mainly in Scala.

As far as I know the closest thing to node.js in Scala would be something like Finagle, which they use at twitter:
http://twitter.github.io/scala_school/ [github.io]

For my current hobby project the backend is written in Scala, Akka and Play! - though I am considering replacing Play with Spray, since all the backed does is serving JSON from REST services.

http://akka.io/ [akka.io]
http://spray.io/ [spray.io]

My 2 cents on Node.JS (1)

randomErr (172078) | about a year ago | (#44236203)

Node is great for small, narrowly focused web apps and quick development. But I find many of the supporting projects to be less then stellar. The lack of a solid IDE that has some sort of optimizer bother me. Also, JavaScript is an interpreted language which by it nature has speed issues.

What I'm saying for long term support you'll need to roll most of your own code. Pulling in external modules may be slow because of the lack compiled code. Don't expect much from third party libraries. I've only been able to get one to work as advertised. And most of the advanced third party libraries require Python. Which begs the question: why am I using Node.JS when I could be using Python instead?

Re:My 2 cents on Node.JS (4, Informative)

Required Snark (1702878) | about a year ago | (#44236347)

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) [wikipedia.org]

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.

Re:My 2 cents on Node.JS (0)

Anonymous Coward | about a year ago | (#44236511)

>Which begs the question: why am I using Node.JS when I could be using Python instead?
About the performance: Until PyPy is ready, NodeJS - which is based on V8, a JIT-Compiler - is still much faster. Maybe not as fast as C++ using Wt, but still about a big factor.
Also, consider the non-blocking model of NodeJS. It's ideal for applications like say irc only clients.

Also: Before someone says: "But there's Tornado", consider that it's made for long connections only.

Huh? (1)

emblemparade (774653) | about a year ago | (#44236267)

I think you're jumping on the Node.js bandwagon without understanding why.

Node.js is a good asynchronous server, like Tornado (written in Python). However, it sounds like you are writing a backend for a RESTful (mobile) web application. Web is rarely asynchronous and has no special benefits from using an asynchronous server. You will not be more scalable just because you choose Node.js as your platform.

However, if you're excited about JavaScript on the server -- wonderful, because you get to use the same language throughout your project -- then consider the following products that are based on the JVM:

Prudence [threecrickets.com] (cool because it has a framework for MongoDB, which is also JavaScript-based, and also because it uses Restlet, a truly awesome JVM library)

Helma [helma.org] (very mature and proved its worth)

JSSP [sourceforge.net]

Myna [mynajs.org]

Phobos [java.net]

strengths and weaknesses (0)

Anonymous Coward | about a year ago | (#44236485)

Most web software is heavy on the I/O, and light on the processing. For that kind of workload, node.js is emerging as a very viable solution; certainly better than a .NET or full JavaEE stack. But for processing-heavy, transactional workloads, node.js is simply not appropriate, and a JavaEE-based solution is still far preferable. It's a question of using the right tool for the job, not of what's "old" and what's "new".

As for support, well: Oracle isn't very good, and neither is Microsoft. Node's document sucks, but then again so does that of most of the tools used by Java and .NET developers (anyone ever look into JBoss' docs? And IBM produces copious documentation, but you can never find the one thing you're actually looking for).

So: if your workload is I/O bound, and you intend to run the code in the cloud, definitely take a peek at node.js, especially if you have a team of highly skilled Javascript developers (you'll need them; node is non-trivial). If you don't, then look at Java-based solutions, either JavaEE/Spring for transactional applications, or even Vert.x for I/O bound workloads (once the dust settles down on the IP issues).

Node.js Is the future (1)

Anonymous Coward | about a year ago | (#44236661)

Node.js or something like it is the future. While the tech today is not ready for prime time, it defiantly shows the trend that programming needs to go.

That trend of course is one language to rule them all, and that language is Javascript. Having your entire application written in one language front to back end. (And with Json, even data transfer) is a major boost to application development. Is it the best language for the task, no. But that simply does not matter because it is good enough. The removal of the context language switching, adding the ability to share code across any part of and application, and removing segration of developers based on language is such a big plus it easily outweighs javascript quicks.

The funny thing is that the software industry has created a portable, cross platform, cross domain language despite itself.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?