Forgot your password?
typodupeerror
Programming

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

Posted by Soulskill
from the go-with-the-trendy-option dept.
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?"
This discussion has been archived. No new comments can be posted.

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

Comments Filter:
  • by skovnymfe (1671822) on Wednesday July 10, 2013 @05:19AM (#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: (Score:3, Insightful)

      by Kjella (173770)

      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.

      • by sproketboy (608031) on Wednesday July 10, 2013 @06:53AM (#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.

        • While node.js may not be supported by a big company, the JS engine the runs node.js (V8) is run by Google.
      • And when your Java application goes to shit you're going to call Oracle?

        Being a mature language, it's not that hard to find a Java developer. With enterprise software you have to think about language features and support staff turnaround.

        Sure sounds a lot better than many of the other fads out there.

        You lost me on that one. Java was first released in 1995. Node.js is about two years old and is still at a 0.10 version release. PHP, Ruby, Perl, and Python all have longevity and developer base supporting them

      • by ttucker (2884057)
        Are you saying Java is a... fad?
    • 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?

    • by gl4ss (559668)

      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.

      nod

    • by Tridus (79566) on Wednesday July 10, 2013 @06:01AM (#44235659) Homepage

      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.

      • by sproketboy (608031) on Wednesday July 10, 2013 @06:55AM (#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: (Score:2, Interesting)

          by Xest (935314)

          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

          • by Tridus (79566) on Wednesday July 10, 2013 @07:28AM (#44236053) Homepage

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

            • by Xest (935314)

              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 becaus

        • 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.
          • by dwpro (520418)

            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 t

        • 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.
          • Nope. They haven't. the .NET data layer is still coded around concrete classes mostly and the APIs have many less features than JDBC.

    • by angel'o'sphere (80593) on Wednesday July 10, 2013 @06:44AM (#44235857) Homepage Journal

      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.

    • by mjwalshe (1680392)
      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.
    • Years ago I was dealing with a particularly nasty problem with some new Oracle software. We called for support and went up layer after layer until we were talking with a guy involved in development. He basically said that the software in question was crap and that we would never get our thing to work.

      About the only company that vaguely impressed me with their support was Sun in that if one of their machines died they bent over backward to get it working again. In one case they sent a guy in to swap out a
    • <quote>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.</quote>

      If Java has an issue, ONLY Oracle could address it. If they don't care to fix it, you're fucked.
      Node.js, being open source, could be fixed by the current project team, or any C++ progra

      Java maintenance stops when Oracle's suits decide they have something better to do.
      Node.js maintenance
  • by etash (1907284) on Wednesday July 10, 2013 @05:28AM (#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.
    • by gl4ss (559668) on Wednesday July 10, 2013 @05:37AM (#44235573) Homepage Journal

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

      by effigiem (2558315)
      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: (Score:2, Insightful)

        by Anonymous Coward

        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.

        • by Zeromous (668365)

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

    • by Xest (935314) on Wednesday July 10, 2013 @07:01AM (#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.

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

    • the thing with node is that it can handle things that your server can't necessarily handle. Things like websockets and server sent events. If you were to build a site that needed websockets for real-time feeds using traditional technologies (like php + apache), you'd wind up with apache having n open connections with n instances of your application loaded into memory. The power of node.js is the fact that a single instance of the app will stream content to an arbitrary number of clients with a single instan

      • by etash (1907284)
        i like node, and yes the biggest + for node is its easy asynchronous networking capabilities. It's just that i think it should work strictly as a backend and not try to also be yet another http server for which you would need to re-implement session management etc. etc.
      • An Enterprise should be using an ESB from someone like Tibco. Then they should have a heterogenous set of apps that publish endpoints to that ESB. Some could be Java backed, some .Net, some Node/Python/Erlang or straight C/++ (throw some COBOL or Haskell in). These apps should subscribe to each other as needed for data interchange.

        The client apps used for managing and reporting can be anything at this point. Node would be just fine for a web based GUI. It loves to consume endpoints. Sockets, REST, streams -

  • I think... (Score:5, Interesting)

    by gigaherz (2653757) on Wednesday July 10, 2013 @05:32AM (#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... (Score:5, Informative)

      by serviscope_minor (664417) on Wednesday July 10, 2013 @06:00AM (#44235653) Journal

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

    • by hey! (33014)

      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.

      A couple of points. First, the argument you're making is for static -- i.e. compile-time -- semantic checking. I was hearing the very same argument thirty years ago among people who advocated Pascal over C; on paper it's sound, but decades of practice have convinced me that static checking, while probably helpful, is not as efficacious as it seems like it should be. After all, you *still* run into mishandled exceptions in Java, and many Java programmers do an end-run around around much of the compile-time

    • by T.E.D. (34228)

      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 actually agree with this statement whole-heartedly. However, I can't help but find it amusing that you immedately go on to propose using one or more of the modern updates to C, Ken Thompson's slightly higher-level replacement for PDP-7&11 Assembly language [wikipedia.org].

  • by Qbertino (265505) on Wednesday July 10, 2013 @05:58AM (#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 sa

    • by leuk_he (194174)

      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 hav

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

      • by Xest (935314)

        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 qu

        • "Web developer" has a stigma due to the early days of people learning HTML and using FrontPage and comparing themselves to people who actually used a programming language. I think the fact that web applications attract the most new people is why this stigma still exists. Who knows? I generally tune it out and judge people by their ability not by their chosen specialization.

          • by Xest (935314)

            Yeah to be fair there's some truth to it, if anything the reason I do know languages like C, C++ and so forth is because I come from a desktop and server background as opposed to web. I do find a lot of developers who have done nothing but web development all of their lives do seem to be extremely low calibre.

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

  • by stikves (127823) on Wednesday July 10, 2013 @06:08AM (#44235689) Homepage

    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.

    • by Dambiel (115695)

      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.

    • by mystikkman (1487801) on Wednesday July 10, 2013 @09:14AM (#44237011)

      > 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/ [amazon.com]

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

      It's been a long time since the execution speed of the program was the bottleneck in web programming. Generally the thing that causes performance issues will either be network latency/bandwidth or database issues. The speed of the compiled code can be solved by adding a few more servers, and you will have a lot of servers before their cost is more expensive than the cost of a single developer you would have to hire to take care of C++ issues.

    • by godefroi (52421)

      6 times the RAM required for a GC to function properly? Over what? Just how, exactly, is malloc()/free() not a garbage collector? It serves the same purpose, it simply requires more handholding to do so.

  • by aglider (2435074) on Wednesday July 10, 2013 @06:14AM (#44235717) Homepage
    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.
  • I'm pretty sure the Enterprise doesn't use JavaScript. It either uses C or a Starfleet-specific language.

  • 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

  • by Required Snark (1702878) on Wednesday July 10, 2013 @07:38AM (#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.

    • 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 anym

    • by Laz10 (708792)

      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 servi

  • 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 bee
    • by Required Snark (1702878) on Wednesday July 10, 2013 @08:24AM (#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.

  • 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 sam

  • I've been primarily working with XML databases (eXist) on the back end the past several years. But the need for doing more client-side work (via JavaScript) has been increasing. Having dealt with Microsoft's weekly build breaks in IE 4 (I seriously had a list of build numbers from each week that different customers installed IE and a different aspect of my web application broke), and their inability to follow the ECMAScript standard, I've gone very grudgingly back into the whole build apps with JavaScript

  • by hey! (33014) on Wednesday July 10, 2013 @10:31AM (#44238123) Homepage Journal

    You're asking for the classic apples to oranges comparison here.

    Node.js is all about scaling the number of requests/second -- about minimizing the number of boxen you need to serve thousands of requests per second. By using polling instead of threads (under the covers) and asynchronous event handling (above the covers), it becomes simple to respond to high volumes of requests without allocating huge volumes of resources.

    But requests/second is only one dimension of scalability. There is management of the infrastructure. There is security (the number of Node tutorials which completely omit this is shocking). There is complexity (much of which in Node.js is pushed to the client side). There are features (e.g. the messaging and timer services in Java EE).

    The buzz over Node.js reminds me of the buzz over Ruby on Rails a few years back. RoR also introduced an elegant new programming paradigm -- configuration by convention. People were amazed that the could field a simple example app without having to write XML configuration files for the ORM layer. Look! It creates all CRUD interfaces for me! But in the end those tasks really aren't that challenging for an expert programmer; they're more like sand in the gears when you're starting up a project. So while RoR remains a good tool for certain kinds of web apps, it's nowhere near as revolutionary as it seemed at the time, and it has little penetration in the enterprise market. It sees to me that most of the joy in Node.js is likely to be on the front end of the project, but in the long tail of the project you're still going to have a lot of drudge work, especially where you have to roll your own enterprise features.

    Which is not to say Node.js isn't brilliant. It appeals to the old Unix man in me, because it does one thing really well. It's a superb piece of middle-ware glue. It makes exposing back end services like databases to RESTful web clients a snap, and if you've got to do that on a massive scale, where by "massive scale" I mean by retail web standards where you have to handle tens of thousands of simultaneous connections. For web applications where you don't have to integrate with a lot of back end enterprise systems and where there's a heavy emphasis on a rich HTML/CSS UI, Node.js is an elegant solution that reduces the information overload on the development team by taking advantage of the Javascript expertise they're bound to have.

  • 99% of the criticism of node here is boiling down to "its a dynamic language and dynamic languages suck". Everyone gets an opinion, but clearly dynamically typed languages can be used to build large things, because they actually have been used in many many cases. As someone who has a production node product used by enterprises everyday, most of the people on this thread sound like they have never actually used node before, and the criticisms reflect a knowledge of js from 1998. Also, every language has it

"The vast majority of successful major crimes against property are perpetrated by individuals abusing positions of trust." -- Lawrence Dalzell

Working...