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