Slashdot Mirror
Ask Slashdot: Node.js vs. JEE/C/C++/.NET In the Enterprise?
theshowmecanuck writes "I'm working at a small- to medium-sized company that creates software for mobile devices, but came from a 'large enterprise' world before. I see node.js being used increasingly in smaller companies (including ours) or in web/mobile related software. Meanwhile we see languages like Java/JEE, C/C++, and .NET continue to be used for medium-to-large enterprise corporate software. Compared to the status quo in the enterprise (JEE/C/C++/.NET ... and yes, maybe even COBOL) maybe Slashdotters can chime in on how they see Node.js in this role. I'm thinking of things like complexity of business logic (dependencies, workflows, linear processes, etc), transaction support (for processes in general and database support), messaging services, etc. Also, what is the state of Node.js in terms of paradigms like application containers, where much of the 'plumbing' is already set up for you (one of the main benefits of JEE application containers)? But there is also the question of maintainability, deployment, and ongoing operations. What say you, Slashdot?"
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.
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.
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.
Typescript is the answer here if you love JS.
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.
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?
Javascript is a horrid scripting language, we should get rid of it on browsers and not to use it on servers.
Interesting, would you care to expand?
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: .... 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. ...
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
Had Netscape released their webserver as FOSS back in the mid-90ies, we'd all be using JS as serverside language ever since, since JS was the serverside language on the Netscape Enterprise Server.
I think compiled languages are impractical for web environments, for reasons everyone can come up with, so that rules out C and C++. For every environment that is set up from scratch I can't think of a single expert that would recommend .Net. .Net exists because it banked on the existing Windows/MS legacy. The MS CLR may be a neat feat, but it is a MS lockin trap, and today it's mostly pointless, since abundant server power, virtualisation and simular things have made optimisation concerning multiple runtimes on one setup a non-issue.
This leaves us with JIT/bytecode compiled or interpreted languages. Here I see Java vs. all the rest (Python, PHP, JS, Ruby, etc.). It's basically Java vs. FOSS languages. Java *is* a FOSS language by now, but the problem is that Oracle is a very bad herald for FOSS Java, and the FOSS alternative, OpenJDK/SDK is bad/slow.
For the future of web I do see Node.js gaining lead position. Google put serious cash into aquiring V8 technology, improving it and putting it into Chrome. Flash was killed by Steve Jobs/iOS, pushing brilliant no-Flash-allowed devices (iPhones and iPads) into millions of end-user hands, so Google had to come up with a serious alternative. Hence JS/V8.
Not being stupid - selling software is *not* Googles business - they released the impressive V8 engine as FOSS, and some smart people put in the effort to port that engine to the serverside, where it is about to kick PHPs and Rubys ass, simply because it's at least as good as either of those *and* it is the same primary non-lockin language on the serverside as is on the clientside. Mind you, clientside JS only became popular once a guy wrote a famous blog article in which he renamed "doing important smart things with JavaScript" into "Ajax", which is a cool name and thus made JS on the clientside popular with a lot of people who formerly had no interest in looking into JS seriously. We have the same effect when some smart guy decided that plain Java objects weren't used and other things like EJBs were more popular simply because regular Java objects didn't have a cool name. So he named them Pojos (Plain Old Java Objects) and solved the problem. Any serious respectable Java toolkit today uses Pojos at its heart.
Bottom line: Wether a tech or PL catches on, gains traction and becomes the next big thing is usually rooted in issues one would not think as relevant right away - things like 'Does the tech have a cool name?', among others. That sa
We suffer more in our imagination than in reality. - Seneca
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.
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. But that's just me.
So, please, explain better your problem.
Sent as ripples into the electromagnetic field. No single photon has been harmed in the process.
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.
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.
I'm pretty sure the Enterprise doesn't use JavaScript. It either uses C or a Starfleet-specific language.
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.
No: GTE.
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
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!
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
"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?
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.
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.
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.
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.
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.
-------------------------------------------------
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
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
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.
Why is Snark Required?
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.
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.
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?
You say things that offend me and I can deal with it. Can you?
Yes, and the exact same issues apply for Javascript I'm afraid.
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 (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 (very mature and proved its worth)
JSSP
Myna
Phobos
Why is mono dead on Linux?
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.
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 movement.
What I would like to be able to do is write XQuery on both the server and in the browser. The Sausalito made that promise, but it just never felt quite right to me.
Node and CouchDB together appear to do the same with JavaScript, and with impressive results from what I've seen. I've spent a long time evaluating it and a few other frameworks for a future project, but the surprise find for me has been AngularJS.
Having been raised with MVC back in the 1990s in C++ and Java, there has just been something about AngularJS that has totally clicked with me. I can take a bit of the load of rendering pages away from the XML database backend and use static HTML pages in the dynamic fashion that was promised since Netscape Navigator 2.0.
It's been nice doing everything in a single language - XQuery - for the past several years. The Model is XML, the View is XHTML and JSON output, and the Controller is XQuery. All of it running on the server side.
The division of labor in AngularJS feels right to me. It's organized well. (Part of that organization appears to be a reliance on Node for project management. So understanding Node is useful, even if you're not going to be running from a Node HTTP server.)
Hardly dead. Its very much alive on Linux, Mac & Android.
I run a big 24/7 mission critical GPS and Mobile network on Linux/Mono for a household name. It better not be dead!
JavaScript is the new LISP. Once you master its scoping rules (very simple, but nuanced), and use closures with the same ease you use for-loops, you'll see the light.
Node takes JavaScript to the next level by making everything asynchornous. You can't have some things synchronous, and some things asynchronous... Async is like a virus, and once one thing should be Async, everything touching it needs to be Async. Node helps by making a idiomatic way of handling Async things, along with making everything in their standard library Async. This is really annoying at first, if you're coming from a threads/sync world... but once you get used to it -- it's better! This is the answer to "how do we kill threads?" Threads are a mess and I'll let you Google the thousands of posts and papers on that.
Sharing code between server and client is (surprisingly) very useful. There are a lot of "utility" type functions you'll want shared. Also, code that generates HTML can be shared between server and client side, which makes it very easy to switch between AJAX and traditional requests (because the behavior can be simulated on the server, with the HTML results sent to the client -- or the client can calculate the result themselves, and inject it into the DOM... depending on the situation).
I know JavaScript has warts. I know. Show me a language that doesn't have warts. The point is that JavaScript is supported in every browser. So, what it really comes down to, is you can master one language that is good enough (JavaScript), or you can continue to dabble in all sorts of other languages (Java, Python, Ruby, PHP, whatever's next), and try to ignore the browser. JavaScript will dominate the web for the next two decades, due to entrenched browser support. Deal with it.
That doesn't mean JavaScript should be used for *everything* -- it just means that if you plan on touching the web, then JavaScript is the pill you have to swallow. And once you swallow it, it isn't SO bad. It could have been a lot worse (VBScript, anyone?).
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.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
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 its own ecosystem and idioms. I used to be a .Net guy. If I went in expecting a package manager like npm, I would think that the .Net ecosystem was horrible, because Nuget does not come close. However, I would be ignoring the fact that most .Net projects are off of Nuget and the expectation is to download the dlls from somewhere.
Although I should not get into a huge flamewar about dynamics languages, I would like to point one thing out. Although we do not get compile time checking, IME the adoption of modern best practices for testing in static enterprise shops is almost non-existent. In the modern dynamic world (Rails and node.js where my personal experience lies), it is nearly universal to one degree or another. To each his own, but I would be hesitant to put so much trust in my compiler...
The only real programming language is LISP, but carry on.
"First they came for the slanderers and i said nothing."
Typescript is a superset of javascript (legal javascript is legal typescript) with additions like static typing and some ECMAScript 6 support (classes, modules).
If you're allergic to ;{} characters, stick to coffeescript. If you like ruby or python, stick to coffeescript. If you like c-style (C/C++/C#/Java/Javascript) languages, use Javascript, TypeScript, or Dart.
Do you even lift?
These aren't the 'roids you're looking for.
guess which one has had more serious vulnerabilities to date? you guessed it, java.
you guys are idiots.
Of course, they were all security problems with the Java browser plugin, which in no way would have any effect on server-side java, or any Java use case similar to Node.js. Reality....
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 stops when no one alive can code C++.
My company went that route. Bad idea on multiple levels. The weak typing of JS means you spend a bunch of time on unit tests that the compiler should catch instead. That is time you should be investing on your biz logic, not syntax errors. Node.js' use of callbacks instead of promises makes your code a mess of boomerangs.
There are better solutions out there. JVM based ones are good, so I'm told.
http://vertx.io/ Have both (the promises of Node.JS and the enterprisey seal of approval from the Java ecosystem :)
There also exists Servlets + ASync + WebSockets exists if you want to lean towards the more traditional model (one thread per request) but need a little bit of ASync.
The Java ecosystem is set to get better native JS support (to run / integrate JavaScript directly into the JVM), via both improved Rhino (based on new Java7/8 features) and also a V8 engine (also webkit) due in future JREs. So once these things happen the polygot vert.x can push JS directly as well. As historically JS performance is not good on JVM.
I think it's more like "meh, good enough".
http://soylentnews.org/~tibman
Ok, you sold me on it.
IBM also makes their own compilers and VM there are others. No one forces you to use Oracle's implementation.
Oh and Sun open sourced Java so no one is stopping you from continuing development if Oracle gave up on it anyway.
Uh no. Plenty of people wrote CGIs in C back in the 90s. That is the easiest way for a C application to interface with the web. If you want even better performance you can use FastCGI which is supported by web servers like lighthttpd.
We do not commonly use C today for web programming for other reasons.
I'd split this into two questions. _will_ node.js be very successful in the enterprise, and _should_ it be.
the first is pretty easy - no. Fundamentally if you do a project in java, and it screws up, no one is going to come looking for your head - but if you do it in javascript - it doesn't matter how many gains you get - at the first tiny little problem you are going to be attacked. People are scared of new things, particularly in big business - and all those people who've spent 20 years becoming god's gift to C++ have a very strong interest in watching you fail.
however, should it? I also think this is easy.. "yes". The why is a very complicated answer.
Years ago we spent a long time "getting it working". The tools, libraries, frameworks, services and particularly knowledge (i.e. google) out there mean that any idiot can get something major working very quickly - in most cases you can just type in exactly what you want and find source code for it.
We also spent a lot of time optimising. But now computers are _fast_. and they have lots of memory. And optimisers and jits and vms are really fast. And libraries are so high level that all of your critical sections are usually in someone else's existing highly optimised code anyway. People like to talk a lot about speed - but usually conflate latency and throughput the amount of latency sensitive tasks is _very_ few and far between once you mention hft you starting having to think. And for throughput your grid or gpu able to do thousands or millions of things at once sorta makes you start laughing at the supposed 1.6x improvement you'll get for C++ over java. Then it becomes a _cost_ issue - and that has some interesting trade-offs.
When you really look at it 99..999% of code is not latency sensitive. For that that is, obviously, C is the best option. Then, as your code complexity increases, C becomes messy, and java starts looking like a good way of managing that complexity. Imagine a graph of complexity vs performance requirements - your requirement is a point on the graph and the suitability of the language is a line. Java is ok at performance, but great at complexity. C++ is _much_ better at performance, but worse at complexity - and C is just much better at complexity. As great a language as C++ is, there's just no point on the graph where it makes sense to use it. Especially as your choice doesn't have to be mutually exclusive - it's quite possible to write the 1% of code that gets executed 99% of the time in C, or hell even ASM - and use a pretty language for the rest (mind you I _hate_ java with a passion - it can never hope to equal the elegance of a C# or Miranda)
Of course, large enterprises still spend a lot of time writing code. That's because of many things - mostly because every single person is writing the same thing - and because they are all doing it in the context of "legacy" apps which have good historical reasons for what now appears to be rampant insanity.
and you start seeing the real cost of software - which is not "making it work" - but really "putting it together" - "reusing" - "sharing" - "discovering", not duplicating. And this is where C++ has really hurt the industry. It's _much_ easier to rewrite a library than to get it compiling with another one. Sorry What version of RogueWave was that?
This is something java is really good at - if you can live with the fact that every word has been used a thousand times - java libraries tends to just compose fairly well. Besos showed another way - which is to have services everywhere. That's great in theory.
But it's really hard to write a large new thing that way. It's hard to trace - to debug. and especially release. And nowadays - it's all about releasing - people talk about CI, CD - gatekeepers and the like - but websites now have to be up 24x7. Trading systems give you an hour window a day maybe - but that's going away. Software quality _expectations_ have gone up. It's no longer ac