12 ms·

Why Node.js is becoming the go-to technology

108 points by pmcpinto 13y ago

pgsandstrom 13y ago
While I really like node.js, I always feel skeptical about "re-implemented gave X% improvement". Often a re-implementation is done because the domain-knowledge has improved significantly since the project was started. There should be an improvement even if the re-implementation was done in the same language.
- adrianoconnor 13y ago
  When I see people talk about X% improvement because of some new tech, I always think about Fred Brooks and the No Silver Bullet essay. Nothing changes under the sun.
- baudehlo 13y ago
  See my post here about Haraka. Basic summary is: compared to Postfix (written in C) people are seeing significant performance gains.
davidw 13y ago
* Because Erlang is difficult to grok and hire people for, even though it probably does a better job at a lot of the same things.
jeswin 13y ago
The author makes a point about getting high-quality node developers. That is primarily for two reasons. 1) Early adopters generally tend to do well, whatever the language may be. 2) And more importantly, the asynchrony in nodejs is not easy. Writing maintainable JS is harder than writing Python or Java. So if someone has been through that grind, chances are they could be good developers. Being able to do everything with a single language is kind of a big deal for many companies; the only thing holding back JS of the messy nature of callbacks (and promises, yuck). I would expect real adoption of JS to begin when ES6 features (generators, classes, etc) become available.
- lazyloop 13y ago
  By that logic Erlang should be winning, but it's really just "worse is better" at work.
  - antirez 13y ago
    It is probably more of different tensions competing: if node.js will provide 80% of what Erlang can do, but is a lot more obvious, is the same language of the web development, is hyped, and so forth, there is no chance for Erlang to compete. A stranger / corner language to win must provide a lot more than another more accessible technology. EDIT: it does not help that other popular backend technologies suck so hard performance-wise, since I can't see how javascript is better than, for example, Ruby, as a language (but the contrary).
    - jlouis 13y ago
      I would contend Go does around 50% of what Erlang does. Node.js does around 10% of what Erlang does. You are right that both Go and Node.js has a lot of mass and a lot of acceleration right now. But Erlang has inertia in the projects where it does well and it will probably not affect typical Erlang systems much if Node.js or Go grows large. To this extent, Erlang is a too different beast.
      - antirez 13y ago
        If we are talking from the point of view of "features" of the language, probably yes, but in the get-things-done area things tend to be a lot more malleable, and once you have a single process that performs concurrency with mutable global state you can hack a lot on top of it.
      - davidw 13y ago
        > I would contend Go does around 50% of what Erlang does. Node.js does around 10% of what Erlang does. You're probably more or less correct, but turn things around: from the point of view of the Node.js user, Node does pretty much everything they need, and Erlang does "extra, cool stuff" that, however, they can live without; or think they can. They can do fast, dynamic web sites with web sockets with relatively low overhead, and that's really what they are after. This is related to disruptive innovation being discussed elsewhere: https://news.ycombinator.com/item?id=7397653 https://news.ycombinator.com/item?id=7397653 So for them, node.js is "good enough". You are I'm sure correct that people who need Erlang won't see Node encroach on their turf, but it's something of a missed opportunity for Erlang just the same.
catmanjan 13y ago
I was listening to a podcast by the PM in charge of the WalMart node.js deployment, he had nothing but good things to say about node, but using the CPU graph as a measure is stupid and misleading. The project was using node as a middle-man for some old Java based API which spat out products, prices and stock levels. So node was basically set up to serve static pages, in the hope that later they can migrate the API to node as well. Anyway, I'm sure it's all great, but unfortunately since I know the WalMart statement is a load of BS I distrust the rest of the metrics provided.
daraosn 13y ago
I really like node.js, but Ruby gives you way more 'happiness' and productivity, imo. Until I don't see ALL (or at least 80%) of the stack that frameworks like Ruby on Rails have in node.js's frameworks, I will still prefer Ruby over node.js for most of my web projects (of course node.js is sometimes more suitable for certain things, especially asynchronous services, but you can still use Ruby).
prottmann 13y ago
Oh my god, on some parts i agree and on some parts you exaggerate massive. Node is a step into the right direction, but the Node.js way is only the base for building up new or other technoligies. Yes programmers want to experiment with new things, but when programmers grow up, they want to use things that work without inventing the wheel again. Node grow up now and it is exciting to see what node will be. It seems that iam too old with my 35 years ;-) because i see things like node as a tool, a tool to solve a problem. I use node, but i did not say "yesssss it is the best thing in the world, wohoooooo" ;-)
- mantrax 13y ago
  I'm 32. Let's just point at the overexcited crowds and have a chuckle as another fad is about to peak. I like Node.JS a lot, as you say it's a tool in my toolbox. But due to the it's nature the code is quite fragile. It's best to keep Node.JS apps small and simple and play to Node's strengths, which are a high volume of computationally simple (and potentially long-running) requests. That article is definitely hype-inspired.
gaius 13y ago
Erlang is hard, let's go shopping!
buster 13y ago
Wow, a node.js company writes a blog post how node.js is the next technology and you should switch over (and hire them, they do node.js consulting!) Uhm.. yes.. node.js is great but this article is not. I can write the exact same article with success stories about PHP, Ruby, Python, Erlang, Perl and with a little bit of creativity about brainfuck..
- filipedeschamps 13y ago
  Doesn't need to be a blog post, list some cases of people switching back to PHP, Ruby, Python, Erlang or Perl with the sizes of Wallmart, Paypal, Voxer, etc...
  - mgkimsal 13y ago
    http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_switched_back_to_p_1.html http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_swit... Not the same size, but this was a company that spent a lot of time chasing the Rails fad in 2005/2006/2007, and switched back to PHP. I wouldn't doubt the same type of stories may be told about node in a year or two, although few will ever be terribly public. Few companies like to promote out their bad decisions (not saying node is definitely a bad decision).
    - dham 13y ago
      At my company(we are small just 2 devs), I decided to go down the Node route, because why not, the project I just got off of was a lot of client javascript(with Play framework) and it made sense. This was the end of 2011. I was looking for something to replace Play framework because the impending doom of Play 2.0(which ended up being terrible..for us). We started writing stuff in Node using the node mysql, and ran into a few issues(https://github.com/felixge/node-mysql/issues/200 https://github.com/felixge/node-mysql/issues/200), that were resolved really fast. As I got into it more and writing more business logic it started to fall apart. The async nature really started to show it's face. The async library was awesome in helping with taming the callbacks . When you want to execute queries in series, iterate over data, manipulate the data coming in and then write some data to a csv, it's just not pretty. The code looked good, and it was all in really small functions, but making sense of order of execution with callbacks flying all over the place proved difficult. It was possible definitely but if you looked at the logic in Java, it was just like a big sigh of relief. Not sure how to explain it but looking at code that executes like you think it would makes me happier. Luckily we didn't have too many projects done in Node and switched to Rails 6 months after and have been happy ever sense. I've revisited Node a few times, but even with generators it makes certain things blah. Specifically looping through arrays that need to execute callback code. I really, really want to like Node.JS, but it's just not there for me. For me both languages on the client and server is overrated anyway and with Angular I'm writing less Javascript then I ever have.
hiisi 13y ago
Feels like the "Easy to modify and maintain" part is confusing the benefits of using Node.js with benefits of good application design.
staticelf 13y ago
I write php at work, mostly. But all my free time projects are in node because I love it.
CSDude 13y ago
When I saw go-to in the title, I thought it was about callback hell. I use NodeJS heavily in my projects since it was version 0.4 still have difficulties in writing good code. Other than that, it seems fast, but of course there is no point believing node is 15x faster than our old implementation. Any complete re-building of a system would be faster when you have more experience with the domain.
hartator 13y ago
I think Node.js is overrated. The Node.js/NPM community is going through a lot of issues and seems, unfortunately, immature. People also tends to choose Node.js for the wrong reasons. Mainly they want to have only one language for everything: Database/Frontend/Backend/Deployment... JS itself as a bare language is a far from perfect. A good point to start will be to just compare a sample selenium test in ruby or python and node.js. The Ruby/Python one is clear and expressive whereas the node.js one is just a callback nightmare. Finally, node.js single thread blocking nature means you have to deal with threads/forks anyway for any serious application.
- lunarcave 13y ago
  I think calling a technology overrated by pointing out a sample selenium test is pointless. Like any technology, there are some things that node.js is good at, and somethings not good at. The callback-hell is something that will eventually be ironed out in ES6 and as a language, that'd be something that any dev will find non-appealing about javascript.
  - krsunny 13y ago
    Callback hell has been my biggest stumbling block with node but there are libraries such as asynch and Q which have provided me with adequate solutions. Also since were talking about things to be ironed out, I hope they make it easier to run node behind Apache or some other webserver thats tried and true.. why abandon all that progress?
    - dham 13y ago
      Phusion Passenger(https://www.phusionpassenger.com/ https://www.phusionpassenger.com/) supports Node.
- baudehlo 13y ago
  I wondered this too, so I went out and implemented a large project in Node (Haraka - an SMTP Server). It turned out to be such a success that Craigslist dumped Postfix for it (an SMTP server written in C), and managed to get rid of more than half of their servers due to Haraka being faster. We just added another example company doing the same - bounce.io - they are seeing similar gains. Yes Node has problems like any language does, but the gains are real.
insertnickname 13y ago
>“Why go to Facebook and do PHP when you can go to PayPal and do Node.js” >- Bill Scott – Dir UX PayPal Why don't I just kill myself?
- Sirenos 13y ago
  Or... you could just avoid Paypal? But good god you gave me quite the chuckle. Thanks for making my shitty day a little better.
matthewmacleod 13y ago
I know this is advertising, but there are a couple of particularly objectionable points… Increasing competition between rival internet companies, the speed of delivery and the ability to iterate are the key traits of market leaders. In a competitive scenario, reacting to end user needs, incorporating their feedback into the offering and delivering updates and changes regularly is essential. This is literally nothing to do with Node. It's to do with good architecture and project management. The style of architecture generally used and encouraged in the Node community does tend to push SOA etc., but that's nothing to do with the language. It’s extremely difficult to hire top talent these days; good developers like to learn new things and to use new technologies. Node will not continue to be 'new technology' for long. This is a shoddy basis on which to select a tool. double the number of requests per-second and reduced response time by 35% or 200 milliseconds. Measuring reimplementations of code in alternative languages is frequently absolutely pointless, because that reimplementation will always go hand-in-hand with massive re-architecting, and absent second-system effect this will result in better performance. For example: The old story of linkedin where moving to Node.js from Rails for their mobile traffic, reducing the number of servers from 30 to 3 (90% reduction) and the new system was up to 20x faster. Because all of the rendering was pushed to the client, no doubt. Node is great, but it's one of many valid choices for developing huge, modern web apps. It's not that Node is becoming the "go-to technology in the Enterprise" (it's not), but that SOA, loose coupling and the reduction in use of monolithic frameworks are everywhere, and that's something that Node is good at.
- RyanZAG 13y ago
  > Node will not continue to be 'new technology' for long. This is a shoddy basis on which to select a tool. Not to worry - there will be a new hot technology within a year or two, and a good percentage of the node.js people will scramble to rewrite in it to avoid looking old fashioned.
  - krsunny 13y ago
    I know what you mean but I really think it'll be hard to topple node. I started with express and tried a few other frameworks and finally decided on sailsjs. I haven't had this much fun or been this excited about web development since I started 10+ years ago. I really don't know what it is about node thats so appealing as Im no js guru but I think its going to be around for a very long time.
puppetmaster3 13y ago
4 reasons its good and 2 way to make it better: 1. it's async! most developers can't do threading. it does not do locking at all! let me say it again: no locks. java devs: what is faster, hashmap or hashtable? 2. it's dynamic. compare to old static langs. 3. it uses same syntax as browser. 4. npm. compare it to the maven. A way to make it better? 1. thick client, not server side rendering of ui. use a CDN and phonegap build 2. npm -g install typescript (to make it a bit less dynamic) cheers.(I myself now like D libs, such as http://vibed.org http://vibed.org )
- larsmak 13y ago
  >Java devs: what is faster, hashmap or hashtable? Ok, as a Java-dev I'll bite: They are not really comparable - because their use depends on the situation. One is meant for concurrent access by multiple threads - and thus synchronizes the access, while the other one is not thread safe and should not be used where this is a requirement. If you want the best of both, use ConcurrentHashMap. There is a concept of a shared resource, e.g. a cache of computed values. A shared resource will necessarily be subject to concurrent modification, and thus requires synchronization. The point is, depending of the situation shared resources may far outweigh the cost of synchronization. These are tools, understand them and use them where they makes sense.
- andy_boot 13y ago
  >>it's async! most developers can't do threading Most developers can't do async either. - It's really hard to debug if you dont get your callbacks right. Personally I find threads easier than async.
  - puppetmaster3 13y ago
    It's just you. It's easy to do clean deterministic event driven programming. Maybe you are just not used to it. It works just like the browser events, and there are kids in elementary doing it. Last, no locks is FAST!
- darkarmani 13y ago
  > 4. npm. compare it to the maven. NPM is probably the worst part. It solves the easy problem using brute force and 20 copies of the same library, but punts on actual packaging. Joyent's advice is "don't use NPM to deploy -- use tarballs." What kind of package manager requires you not to use it for deployment?? I really think NPM is a solution for immaturity on the node libraries. Think about the attack surface when you have 20 different versions of the same library scattered throughout your application. Not having to understand your library dependencies means you don't understand all of the security bugs from old versions of libraries. You should understand your library dependencies. Forgetting about them doesn't make those relationships go away.
sdfjkl 13y ago
> Black Friday the WalMart servers didn’t go over 1% CPU utilisation So they massively overprovisioned? Hopefully they didn't buy all that hardware.
- nocoment 13y ago
  Maybe they just didn't pay for priority over netflix so comcast broke their legs.
- dspillett 13y ago
  Using CPU utilisation as a measure like that is pretty pointless anyway. Without knowing over what period (instantaneous measure across the farm, a ten minute average from a typical node, a ten minute average over the lot, ...) that reading was taken it could mean many things. If they have pushed a chunk of the rendering duties client-side then the CPU is not going to be their bottle-neck anyway: the back-end data-store and network bandwidth will be.
- gaius 13y ago
  They could have been stuck in iowait...
deleted 13y ago
[deleted]
lucian1900 13y ago
This is all bullshit. There is one reason Node is popular: it's JavaScript (extremely popular) on a server and mostly works with little effort (unlike most similar runtimes).
- mackwic 13y ago
  Javascript is extremely popular ? Since when ? Oh, wait, since node.js. (Even if node is not the only cause of the JS popularity)
  - lucian1900 13y ago
    No, since browsers.
  - BasDirks 13y ago
    Are you an actual person with a brain?
- lnanek2 13y ago
  Performance is a big deal too. If you try to start a VC backed startup with Rails nowadays everyone will tell you to stop, you are just going to have to rewrite it in something performant anyway if anything happens, so to just start in NodeJS and save time. Big headline cases like LinkedIn having to move over is in everyone's heads.
  - lucian1900 13y ago
    You could write it in Ruby without Rails and it'd be about the same.
dschiptsov 13y ago
"Write server side apps the way you wrote stupid web pages" meme? And all the difficulties with resource management and efficient I/O is someone else's problem. Ok, good luck for those who never learn Java's lessons.) Btw, pamphlet forgot to mention compared to what they got many X increases and reductions. Ruby, I suppose.) Well, V8 complies into native code, but server side is mostly about I/O and RPC and data persistence, which requires a bit more skills than getElementById, so assumption about 1/2 number of developers is overoptimistic. Also would love to see, same as for java based "solutions", the ratio between memory used and the size of served data set , especially compared to Golang which I think is little more appropriate for server side.) "Let's add it all together" section is especially convincing.)
adamors 13y ago
Do people actually use Node in production for serious things? I actually don't know anybody who shipped anything done in Node. Sure, they do side projects or hobby projects, but nothing more than that.
- pas 13y ago
  I think GitHub is using it ( https://github.com/blog/678-meet-nodeload-the-new-download-server https://github.com/blog/678-meet-nodeload-the-new-download-s... https://github.com/blog/900-nodeload2-downloads-reloaded https://github.com/blog/900-nodeload2-downloads-reloaded )
- mkohlmyr 13y ago
  You're not being serious.. https://github.com/joyent/node/wiki/Projects,-Applications,-and-Companies-Using-Node https://github.com/joyent/node/wiki/Projects,-Applications,-... In fact I work at a company which is on target to process more than 2bn events / 1bn page views this year on a node / python based service oriented architecture. I'd say that's a handful more than your average hobby project.
  - zorked 13y ago
    We're doing 3.5 billion requests a month on Node and I'm sure it's still a small number compared to what other people are doing.
neverminder 13y ago
From what I read around I understand that node.js is good for simple projects, but not for heavyweights where concurrency and scalability is the key. This is where I'm pretty sure something like Typesafe stack (Scala/Play/Akka) blows it out of the water. Personally if I work on something I'd like to at least hope that it will be big someday, which is why I'm willing to spend some extra time, but choose the most solid platform that I can afford. Typesafe stack is the most impressive one at least for now, in my opinion.
mgkimsal 13y ago
The issue about happy developers because they are using 'new technologies' (use node! it's a new technology) is a wrong conclusion. This is like Rails 7-8 years ago. People using node now are essentially doing greenfield projects - they're writing 'from scratch' code without any major requirements to keep existing code going. Come back in 5 years when someone has to maintain the Paypal nodejs stuff which has become a moderate mess due to weird edge cases, changed business and legal requirements, and try to hire node developers to come in and maintain code written by people who are no longer working there, having moved on to scala/f# projects in 2015. All the new attention will be in 'node 2017', but you'll be stuck trying to make 2017 modules work in 2013 code, and you'll be left trying to patch/maintain something that wasn't as forward-compatible. For true irony, some of those same developers will be brought back as consultants to develop the next-gen 'paypal 2018!' based on some new Scala framework, and the maintainers will have to watch the experts write the next generation of what they'll be maintaining 4 years on. EDIT: "The old story of linkedin where moving to Node.js from Rails for their mobile traffic, reducing the number of servers from 30 to 3 (90% reduction) and the new system was up to 20x faster." I strongly suspect that if the team had been given X months of "rewrite the Rails system using all the current knowledge and techniques, as a new system vs patching the live one", they'd have seen similar results in less time. To the extent that some companies are more SOA flavored than they were 5-10 years ago, this will be easier for everyone involved, of course, but let's not pretend that developers are happy because they're using 'new technology'. They're generally happy in any language when they don't have to work within bone-headed constraints leveled on them by predecessors who were chasing the latest fad before really understanding it.
vjeux 13y ago
I'm a developer at Facebook I thought I'd share my experience. Before I joined, I wasn't really convinced by PHP. My experience using it was good for quick and dirty work but quickly resulted in a mess. However, the Facebook codebase was nothing alike. The PHP stack uses generators to deal with async requests and doesn't suffer from callback hell. To write the UI, you write new custom components using XHP (XML in PHP). It heavily uses classes, traits, and most badly designed native php functions have a better counterpart available. On the javaScript side, all the code is written using CommonJS modules. It runs a custom version of JSLint and Jasmine for unit tests. React as the main framework. We also have source transform for ES6 classes, arrow functions, spread operator ... It definitively feels at home for any node.js person :)
- jerf 13y ago
  "The PHP stack uses generators to deal with async requests and doesn't suffer from callback hell." This is one of the problems with the Node hype; it claims to be this unique and special snowflake, when in fact pretty much any similar language (Perl, Python, PHP, Lua, etc.) has just as much stuff working for it. Even the "but our libraries are 'designed' for async!" isn't as big of an advantage as is claimed, since in many cases the other languages have good libraries too. (Or in the case of something like gevent, a reasonable ability to convert libraries to async.) It's really a throwback, not the awesome step forward it claims to be.
CmonDev 13y ago
The new Silver Bullet is born! Will get you best developers, cut bad things 50% and improve good things 2x! JS is the only language you will _ever_ need!
Kiro 13y ago
> NPM effectively kills the possibility of experiencing dependency hell Am I the only one feeling that package management is the cause of dependency hell? Doing it the old school way where you just always have all the dependencies in the repo will never lead to these problems.
KaiserPro 13y ago
"sidestep threading issues" I think displacing them is more apt. complex Callbacks just as nasty as complex threads.
pjmlp 13y ago
Err, no.
AgLiAn 13y ago
Propaganda.
exabrial 13y ago
Because the hipsters thought it was a good idea? Once they realize it's impossible to maintain your codebase they'll all moved on to create their next disaster.
jbeja 13y ago
When Lua will become the go-to technology?
camus2 13y ago
nodejs will live on because it uses js which is mandatory in the browser,for better or worse. Hopefully ES6 and futures versions will make this awfull language much better.
- VeejayRampay 13y ago
  I really wish ES6 does that because as it is, Javascript only has two things going for it: the speed provided by the big boys (V8, xMonkey, etc) and the fact that it's only language available on the web. And none of those are merits of the language itself. Kind of sad.
rbanffy 13y ago
JavaScript seems to be enormously popular among non-programmers. ;-)
edem 13y ago
I wonder how can you build a reliable e-commerce platform on a database which is not ACID...and node users typically use MongoDB and other NoSQL databases which does not support transactions.
- warcode 13y ago
  Amazon seems to be doing alright. http://aws.amazon.com/dynamodb/faqs/ http://aws.amazon.com/dynamodb/faqs/
- camus2 13y ago
  It's true that the most mature DB framework on nodejs plateform is Mongoose,so usually nodejs devs use mongoose to deal with data. No need to say that MongoDB is not the right choice for apps that need transactions or when datas are heavily relational. And Mongoose doesnt support cascade operations. Sequelize or Bookshelf are not mature enough for now IMHO,compared to what one can find on other plateforms like Java,Ruby or PHP. So you either need to write raw sql queries or delegate all transactions to another app layer.
tyler-codenvy 13y ago
I have read the article and this thread with keen interest. I am curious to solicit community feedback on our choices as we faced the Node vs. Java choice in 2012. In particular, does our business ultimately suffer long term consequences by our stack choice? We think we ultimately have strong advantages vs. any competitor built using Node.JS, but the beauty of HN is that we can open up the thoughts for everyone to contribute. I am the CEO and founder of Codenvy. We make SAAS developer environments, and have been working as a team since 2009. Starting in 2012, we recognized the limitations of our initial system and needed to rebuild the entire system from the ground up. We had three criteria: performance, security, and modularity (of our core base and an ability for ISVs / enterprise to plug-in their own customizations). We raised $9M in Jan 2013, so we now have big investors and aspirations equally large. Our target market is primarily enterprises and ISVs that build Eclipse plug-ins. Individual developers and consultants are a secondary audience. We chose to go with a pure Java stack, after a careful evaluation of Node.JS vs. Java. We wanted to provide some of our thoughts, as we continually ask ourselves whether there are downsides to the approach we chose. For the record, we have competitors like Eclipse Orion and Cloud9 that are pure JavaScript / Node implementations, but we are - as far as I have seen - the only Java implementation in our market. Our team is currently 40 people, with 35 or so in R&D. Our engineers have experience with Java, Scala, JavaScript, AngularJS. Prior to this project, most engineers were working on server systems for content and document management firms. The hard stuff: sync, versioning, correlation, and so on. As for myself, my career started as a Java engineer in the 90s, but for the most part have been hands off as a technologist for a decade. My skills may have faded, but as a CEO, I am conversant. We did 2 prototypes on Node.JS where the client and server were combined systems. We ran a battery of performance tests and did conclude that we could probably run a large scale system on fewer physical nodes with Node.JS than with Java, but the gains were not enough to justify the choice. Our long term architecture was different from our competitors. Most SAAS dev environments provision each user / group their own VM, give you root access, and let you control that system. We chose an approach that would optimize overall system density by by offloading builds, debugs, and editing onto separate clusters. User environments will be virtualized and routed to the appropriate cluster on-demand. The user will feel like they have a personal VM, but our elvish helpers route traffic between the nodes across performance queues. After offloading LDAP (for identity), event / log management (for analytics), and cloud administration, the only core systems left was our API services (account / builder / runner / auth) and editing. These core systems would be subject to heavy iterative development, and Node's architecture could offer higher density of requests / users than Java, but by our tests the comparison was 10-20% difference, not 300%. By way of scaling, for every 10,000 concurrent developers, we average 20 editing nodes (I/O constrained), 75 debugging nodes (memory constraining), 5 builder nodes (CPU constrained). A similar TS / VDI implementation would require nearly 5,000 nodes of the same shape / size to service the same population. So, we saw a disadvantage to Java as we could have reduced our editing node even further. But we chose Java because: a) The library selection. Broad and mature. In particular, it's data structures, file management, REST services. b) GWT. This library gave us cross-browser portability of code written in Java. c) Eclipse Plug-Ins. We knew we wanted to target Eclipse plug-in developers and saw the Orion project as optimized for Web dev, leaving a gap in Eclipse. We saw it as a business gamble that Eclipse devs who needed to move their plug-ins would find a pure Java plug-in architecture that was similar to RCP more attractive than a newer (but have to learn new tech & rewrite) approach. d) Our history. We did a straw poll of our engineers before we started. We asked them if they felt that they would rather do Node or Java, and 75% said that they would enjoy Java more. When asked why? They had tool familiarity, were confident in the maturity of maven, and better job prospects. This last one completely surprised me. e) JVM. The number of optimizations of the JVM would give us advantages for enterprise deployment. We built our system to be automatically installable on-premises. We do so with Puppet, but recognized that we would be encountering many IAAS and PAAS standards internally. Enterprises had security and performance tested the JVM, so we saw an opportunity to win hearts and minds of system admins, datacenter architects, and security specialists by our choice of architecture. So, we carried forward. Since we started working on our next generation architecture, we have focused hard on the best practices associated with agile, devops, and continuous delivery. We have 7 teams of 4-6 people, each focused on a different aspect of our stack. We are able to release any Jira issue at any point in the day. Each team can push into acceptance, staging or production without coordinating with the other teams. At the same time, we have achieved modularity and a rapid development tempo. While we haven't released our new system to the market yet, we find that the performance of the environment is similar to a desktop environment, and it scales cleanly with simulated load tests. We have also been able to give out our SDK (github.com/codenvy/sdk) to 6 different partners, some of which are Eclipse plug-in developers, who are able to code, build, test, integrate, and publish their plug-ins without complicated dependencies to our core team. Their feedback was that the port of their plug-in took about 1/2 the time of the original development. And there is no real way to estimate what the effort would be to do the same in a Node-based offering like Orion. What we can't measure is whether our competitors are able to release faster & more functionality than we are. It seems like a crap shoot. One other variable we can't account for is the cost to maintain legacy. The system we have Codenvy.com is legacy for us, and will be retired in Q3. We have to continually allocate 3-5 people to work on bugs, special partner projects, or other related items to keep that system live while we also work to roll out the new system. We know this is a drag, and some of our engineers think we may more than double our productivity once we consolidate to a single architecture. I am a bit skeptical at that - but I find that it's unwise to disagree with my engineers. I tend to lose. So at this point, we feel like we made the right choice. But time will tell - we begin selling our enterprise offering earnestly once we ship our new system in Q2. Looking forward to the discussion.

108 points by pmcpinto 13y ago

While I really like node.js, I always feel skeptical about "re-implemented gave X% improvement". Often a re-implementation is done because the domain-knowledge has improved significantly since the project was started. There should be an improvement even if the re-implementation was done in the same language.

adrianoconnor 13y ago
When I see people talk about X% improvement because of some new tech, I always think about Fred Brooks and the No Silver Bullet essay. Nothing changes under the sun.
baudehlo 13y ago
See my post here about Haraka. Basic summary is: compared to Postfix (written in C) people are seeing significant performance gains.

davidw 13y ago

* Because Erlang is difficult to grok and hire people for, even though it probably does a better job at a lot of the same things.

jeswin 13y ago

The author makes a point about getting high-quality node developers. That is primarily for two reasons. 1) Early adopters generally tend to do well, whatever the language may be. 2) And more importantly, the asynchrony in nodejs is not easy. Writing maintainable JS is harder than writing Python or Java. So if someone has been through that grind, chances are they could be good developers. Being able to do everything with a single language is kind of a big deal for many companies; the only thing holding back JS of the messy nature of callbacks (and promises, yuck). I would expect real adoption of JS to begin when ES6 features (generators, classes, etc) become available.

lazyloop 13y ago
By that logic Erlang should be winning, but it's really just "worse is better" at work.
- antirez 13y ago
  It is probably more of different tensions competing: if node.js will provide 80% of what Erlang can do, but is a lot more obvious, is the same language of the web development, is hyped, and so forth, there is no chance for Erlang to compete. A stranger / corner language to win must provide a lot more than another more accessible technology. EDIT: it does not help that other popular backend technologies suck so hard performance-wise, since I can't see how javascript is better than, for example, Ruby, as a language (but the contrary).
  - jlouis 13y ago
    I would contend Go does around 50% of what Erlang does. Node.js does around 10% of what Erlang does. You are right that both Go and Node.js has a lot of mass and a lot of acceleration right now. But Erlang has inertia in the projects where it does well and it will probably not affect typical Erlang systems much if Node.js or Go grows large. To this extent, Erlang is a too different beast.
    - antirez 13y ago
      If we are talking from the point of view of "features" of the language, probably yes, but in the get-things-done area things tend to be a lot more malleable, and once you have a single process that performs concurrency with mutable global state you can hack a lot on top of it.
    - davidw 13y ago
      > I would contend Go does around 50% of what Erlang does. Node.js does around 10% of what Erlang does. You're probably more or less correct, but turn things around: from the point of view of the Node.js user, Node does pretty much everything they need, and Erlang does "extra, cool stuff" that, however, they can live without; or think they can. They can do fast, dynamic web sites with web sockets with relatively low overhead, and that's really what they are after. This is related to disruptive innovation being discussed elsewhere: https://news.ycombinator.com/item?id=7397653 https://news.ycombinator.com/item?id=7397653 So for them, node.js is "good enough". You are I'm sure correct that people who need Erlang won't see Node encroach on their turf, but it's something of a missed opportunity for Erlang just the same.

catmanjan 13y ago

I was listening to a podcast by the PM in charge of the WalMart node.js deployment, he had nothing but good things to say about node, but using the CPU graph as a measure is stupid and misleading. The project was using node as a middle-man for some old Java based API which spat out products, prices and stock levels. So node was basically set up to serve static pages, in the hope that later they can migrate the API to node as well. Anyway, I'm sure it's all great, but unfortunately since I know the WalMart statement is a load of BS I distrust the rest of the metrics provided.

daraosn 13y ago

I really like node.js, but Ruby gives you way more 'happiness' and productivity, imo. Until I don't see ALL (or at least 80%) of the stack that frameworks like Ruby on Rails have in node.js's frameworks, I will still prefer Ruby over node.js for most of my web projects (of course node.js is sometimes more suitable for certain things, especially asynchronous services, but you can still use Ruby).

prottmann 13y ago

Oh my god, on some parts i agree and on some parts you exaggerate massive. Node is a step into the right direction, but the Node.js way is only the base for building up new or other technoligies. Yes programmers want to experiment with new things, but when programmers grow up, they want to use things that work without inventing the wheel again. Node grow up now and it is exciting to see what node will be. It seems that iam too old with my 35 years ;-) because i see things like node as a tool, a tool to solve a problem. I use node, but i did not say "yesssss it is the best thing in the world, wohoooooo" ;-)

mantrax 13y ago
I'm 32. Let's just point at the overexcited crowds and have a chuckle as another fad is about to peak. I like Node.JS a lot, as you say it's a tool in my toolbox. But due to the it's nature the code is quite fragile. It's best to keep Node.JS apps small and simple and play to Node's strengths, which are a high volume of computationally simple (and potentially long-running) requests. That article is definitely hype-inspired.

gaius 13y ago

Erlang is hard, let's go shopping!

buster 13y ago

Wow, a node.js company writes a blog post how node.js is the next technology and you should switch over (and hire them, they do node.js consulting!) Uhm.. yes.. node.js is great but this article is not. I can write the exact same article with success stories about PHP, Ruby, Python, Erlang, Perl and with a little bit of creativity about brainfuck..

filipedeschamps 13y ago
Doesn't need to be a blog post, list some cases of people switching back to PHP, Ruby, Python, Erlang or Perl with the sizes of Wallmart, Paypal, Voxer, etc...
- mgkimsal 13y ago
  http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_switched_back_to_p_1.html http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_swit... Not the same size, but this was a company that spent a lot of time chasing the Rails fad in 2005/2006/2007, and switched back to PHP. I wouldn't doubt the same type of stories may be told about node in a year or two, although few will ever be terribly public. Few companies like to promote out their bad decisions (not saying node is definitely a bad decision).
  - dham 13y ago
    At my company(we are small just 2 devs), I decided to go down the Node route, because why not, the project I just got off of was a lot of client javascript(with Play framework) and it made sense. This was the end of 2011. I was looking for something to replace Play framework because the impending doom of Play 2.0(which ended up being terrible..for us). We started writing stuff in Node using the node mysql, and ran into a few issues(https://github.com/felixge/node-mysql/issues/200 https://github.com/felixge/node-mysql/issues/200), that were resolved really fast. As I got into it more and writing more business logic it started to fall apart. The async nature really started to show it's face. The async library was awesome in helping with taming the callbacks . When you want to execute queries in series, iterate over data, manipulate the data coming in and then write some data to a csv, it's just not pretty. The code looked good, and it was all in really small functions, but making sense of order of execution with callbacks flying all over the place proved difficult. It was possible definitely but if you looked at the logic in Java, it was just like a big sigh of relief. Not sure how to explain it but looking at code that executes like you think it would makes me happier. Luckily we didn't have too many projects done in Node and switched to Rails 6 months after and have been happy ever sense. I've revisited Node a few times, but even with generators it makes certain things blah. Specifically looping through arrays that need to execute callback code. I really, really want to like Node.JS, but it's just not there for me. For me both languages on the client and server is overrated anyway and with Angular I'm writing less Javascript then I ever have.

hiisi 13y ago

Feels like the "Easy to modify and maintain" part is confusing the benefits of using Node.js with benefits of good application design.

staticelf 13y ago

I write php at work, mostly. But all my free time projects are in node because I love it.

CSDude 13y ago

When I saw go-to in the title, I thought it was about callback hell. I use NodeJS heavily in my projects since it was version 0.4 still have difficulties in writing good code. Other than that, it seems fast, but of course there is no point believing node is 15x faster than our old implementation. Any complete re-building of a system would be faster when you have more experience with the domain.

hartator 13y ago

I think Node.js is overrated. The Node.js/NPM community is going through a lot of issues and seems, unfortunately, immature. People also tends to choose Node.js for the wrong reasons. Mainly they want to have only one language for everything: Database/Frontend/Backend/Deployment... JS itself as a bare language is a far from perfect. A good point to start will be to just compare a sample selenium test in ruby or python and node.js. The Ruby/Python one is clear and expressive whereas the node.js one is just a callback nightmare. Finally, node.js single thread blocking nature means you have to deal with threads/forks anyway for any serious application.

lunarcave 13y ago
I think calling a technology overrated by pointing out a sample selenium test is pointless. Like any technology, there are some things that node.js is good at, and somethings not good at. The callback-hell is something that will eventually be ironed out in ES6 and as a language, that'd be something that any dev will find non-appealing about javascript.
- krsunny 13y ago
  Callback hell has been my biggest stumbling block with node but there are libraries such as asynch and Q which have provided me with adequate solutions. Also since were talking about things to be ironed out, I hope they make it easier to run node behind Apache or some other webserver thats tried and true.. why abandon all that progress?
  - dham 13y ago
    Phusion Passenger(https://www.phusionpassenger.com/ https://www.phusionpassenger.com/) supports Node.
baudehlo 13y ago
I wondered this too, so I went out and implemented a large project in Node (Haraka - an SMTP Server). It turned out to be such a success that Craigslist dumped Postfix for it (an SMTP server written in C), and managed to get rid of more than half of their servers due to Haraka being faster. We just added another example company doing the same - bounce.io - they are seeing similar gains. Yes Node has problems like any language does, but the gains are real.

insertnickname 13y ago

>“Why go to Facebook and do PHP when you can go to PayPal and do Node.js” >- Bill Scott – Dir UX PayPal Why don't I just kill myself?

Sirenos 13y ago
Or... you could just avoid Paypal? But good god you gave me quite the chuckle. Thanks for making my shitty day a little better.

matthewmacleod 13y ago

I know this is advertising, but there are a couple of particularly objectionable points… Increasing competition between rival internet companies, the speed of delivery and the ability to iterate are the key traits of market leaders. In a competitive scenario, reacting to end user needs, incorporating their feedback into the offering and delivering updates and changes regularly is essential. This is literally nothing to do with Node. It's to do with good architecture and project management. The style of architecture generally used and encouraged in the Node community does tend to push SOA etc., but that's nothing to do with the language. It’s extremely difficult to hire top talent these days; good developers like to learn new things and to use new technologies. Node will not continue to be 'new technology' for long. This is a shoddy basis on which to select a tool. double the number of requests per-second and reduced response time by 35% or 200 milliseconds. Measuring reimplementations of code in alternative languages is frequently absolutely pointless, because that reimplementation will always go hand-in-hand with massive re-architecting, and absent second-system effect this will result in better performance. For example: The old story of linkedin where moving to Node.js from Rails for their mobile traffic, reducing the number of servers from 30 to 3 (90% reduction) and the new system was up to 20x faster. Because all of the rendering was pushed to the client, no doubt. Node is great, but it's one of many valid choices for developing huge, modern web apps. It's not that Node is becoming the "go-to technology in the Enterprise" (it's not), but that SOA, loose coupling and the reduction in use of monolithic frameworks are everywhere, and that's something that Node is good at.

RyanZAG 13y ago
> Node will not continue to be 'new technology' for long. This is a shoddy basis on which to select a tool. Not to worry - there will be a new hot technology within a year or two, and a good percentage of the node.js people will scramble to rewrite in it to avoid looking old fashioned.
- krsunny 13y ago
  I know what you mean but I really think it'll be hard to topple node. I started with express and tried a few other frameworks and finally decided on sailsjs. I haven't had this much fun or been this excited about web development since I started 10+ years ago. I really don't know what it is about node thats so appealing as Im no js guru but I think its going to be around for a very long time.

puppetmaster3 13y ago

4 reasons its good and 2 way to make it better: 1. it's async! most developers can't do threading. it does not do locking at all! let me say it again: no locks. java devs: what is faster, hashmap or hashtable? 2. it's dynamic. compare to old static langs. 3. it uses same syntax as browser. 4. npm. compare it to the maven. A way to make it better? 1. thick client, not server side rendering of ui. use a CDN and phonegap build 2. npm -g install typescript (to make it a bit less dynamic) cheers.(I myself now like D libs, such as http://vibed.org http://vibed.org )

larsmak 13y ago
>Java devs: what is faster, hashmap or hashtable? Ok, as a Java-dev I'll bite: They are not really comparable - because their use depends on the situation. One is meant for concurrent access by multiple threads - and thus synchronizes the access, while the other one is not thread safe and should not be used where this is a requirement. If you want the best of both, use ConcurrentHashMap. There is a concept of a shared resource, e.g. a cache of computed values. A shared resource will necessarily be subject to concurrent modification, and thus requires synchronization. The point is, depending of the situation shared resources may far outweigh the cost of synchronization. These are tools, understand them and use them where they makes sense.
andy_boot 13y ago
>>it's async! most developers can't do threading Most developers can't do async either. - It's really hard to debug if you dont get your callbacks right. Personally I find threads easier than async.
- puppetmaster3 13y ago
  It's just you. It's easy to do clean deterministic event driven programming. Maybe you are just not used to it. It works just like the browser events, and there are kids in elementary doing it. Last, no locks is FAST!
darkarmani 13y ago
> 4. npm. compare it to the maven. NPM is probably the worst part. It solves the easy problem using brute force and 20 copies of the same library, but punts on actual packaging. Joyent's advice is "don't use NPM to deploy -- use tarballs." What kind of package manager requires you not to use it for deployment?? I really think NPM is a solution for immaturity on the node libraries. Think about the attack surface when you have 20 different versions of the same library scattered throughout your application. Not having to understand your library dependencies means you don't understand all of the security bugs from old versions of libraries. You should understand your library dependencies. Forgetting about them doesn't make those relationships go away.

sdfjkl 13y ago

> Black Friday the WalMart servers didn’t go over 1% CPU utilisation So they massively overprovisioned? Hopefully they didn't buy all that hardware.

nocoment 13y ago
Maybe they just didn't pay for priority over netflix so comcast broke their legs.
dspillett 13y ago
Using CPU utilisation as a measure like that is pretty pointless anyway. Without knowing over what period (instantaneous measure across the farm, a ten minute average from a typical node, a ten minute average over the lot, ...) that reading was taken it could mean many things. If they have pushed a chunk of the rendering duties client-side then the CPU is not going to be their bottle-neck anyway: the back-end data-store and network bandwidth will be.
gaius 13y ago
They could have been stuck in iowait...

deleted 13y ago

[deleted]

lucian1900 13y ago

This is all bullshit. There is one reason Node is popular: it's JavaScript (extremely popular) on a server and mostly works with little effort (unlike most similar runtimes).

mackwic 13y ago
Javascript is extremely popular ? Since when ? Oh, wait, since node.js. (Even if node is not the only cause of the JS popularity)
- lucian1900 13y ago
  No, since browsers.
- BasDirks 13y ago
  Are you an actual person with a brain?
lnanek2 13y ago
Performance is a big deal too. If you try to start a VC backed startup with Rails nowadays everyone will tell you to stop, you are just going to have to rewrite it in something performant anyway if anything happens, so to just start in NodeJS and save time. Big headline cases like LinkedIn having to move over is in everyone's heads.
- lucian1900 13y ago
  You could write it in Ruby without Rails and it'd be about the same.

dschiptsov 13y ago

"Write server side apps the way you wrote stupid web pages" meme? And all the difficulties with resource management and efficient I/O is someone else's problem. Ok, good luck for those who never learn Java's lessons.) Btw, pamphlet forgot to mention compared to what they got many X increases and reductions. Ruby, I suppose.) Well, V8 complies into native code, but server side is mostly about I/O and RPC and data persistence, which requires a bit more skills than getElementById, so assumption about 1/2 number of developers is overoptimistic. Also would love to see, same as for java based "solutions", the ratio between memory used and the size of served data set , especially compared to Golang which I think is little more appropriate for server side.) "Let's add it all together" section is especially convincing.)

adamors 13y ago

Do people actually use Node in production for serious things? I actually don't know anybody who shipped anything done in Node. Sure, they do side projects or hobby projects, but nothing more than that.

pas 13y ago
I think GitHub is using it ( https://github.com/blog/678-meet-nodeload-the-new-download-server https://github.com/blog/678-meet-nodeload-the-new-download-s... https://github.com/blog/900-nodeload2-downloads-reloaded https://github.com/blog/900-nodeload2-downloads-reloaded )
mkohlmyr 13y ago
You're not being serious.. https://github.com/joyent/node/wiki/Projects,-Applications,-and-Companies-Using-Node https://github.com/joyent/node/wiki/Projects,-Applications,-... In fact I work at a company which is on target to process more than 2bn events / 1bn page views this year on a node / python based service oriented architecture. I'd say that's a handful more than your average hobby project.
- zorked 13y ago
  We're doing 3.5 billion requests a month on Node and I'm sure it's still a small number compared to what other people are doing.

neverminder 13y ago

From what I read around I understand that node.js is good for simple projects, but not for heavyweights where concurrency and scalability is the key. This is where I'm pretty sure something like Typesafe stack (Scala/Play/Akka) blows it out of the water. Personally if I work on something I'd like to at least hope that it will be big someday, which is why I'm willing to spend some extra time, but choose the most solid platform that I can afford. Typesafe stack is the most impressive one at least for now, in my opinion.

mgkimsal 13y ago

The issue about happy developers because they are using 'new technologies' (use node! it's a new technology) is a wrong conclusion. This is like Rails 7-8 years ago. People using node now are essentially doing greenfield projects - they're writing 'from scratch' code without any major requirements to keep existing code going. Come back in 5 years when someone has to maintain the Paypal nodejs stuff which has become a moderate mess due to weird edge cases, changed business and legal requirements, and try to hire node developers to come in and maintain code written by people who are no longer working there, having moved on to scala/f# projects in 2015. All the new attention will be in 'node 2017', but you'll be stuck trying to make 2017 modules work in 2013 code, and you'll be left trying to patch/maintain something that wasn't as forward-compatible. For true irony, some of those same developers will be brought back as consultants to develop the next-gen 'paypal 2018!' based on some new Scala framework, and the maintainers will have to watch the experts write the next generation of what they'll be maintaining 4 years on. EDIT: "The old story of linkedin where moving to Node.js from Rails for their mobile traffic, reducing the number of servers from 30 to 3 (90% reduction) and the new system was up to 20x faster." I strongly suspect that if the team had been given X months of "rewrite the Rails system using all the current knowledge and techniques, as a new system vs patching the live one", they'd have seen similar results in less time. To the extent that some companies are more SOA flavored than they were 5-10 years ago, this will be easier for everyone involved, of course, but let's not pretend that developers are happy because they're using 'new technology'. They're generally happy in any language when they don't have to work within bone-headed constraints leveled on them by predecessors who were chasing the latest fad before really understanding it.

vjeux 13y ago

I'm a developer at Facebook I thought I'd share my experience. Before I joined, I wasn't really convinced by PHP. My experience using it was good for quick and dirty work but quickly resulted in a mess. However, the Facebook codebase was nothing alike. The PHP stack uses generators to deal with async requests and doesn't suffer from callback hell. To write the UI, you write new custom components using XHP (XML in PHP). It heavily uses classes, traits, and most badly designed native php functions have a better counterpart available. On the javaScript side, all the code is written using CommonJS modules. It runs a custom version of JSLint and Jasmine for unit tests. React as the main framework. We also have source transform for ES6 classes, arrow functions, spread operator ... It definitively feels at home for any node.js person :)

jerf 13y ago
"The PHP stack uses generators to deal with async requests and doesn't suffer from callback hell." This is one of the problems with the Node hype; it claims to be this unique and special snowflake, when in fact pretty much any similar language (Perl, Python, PHP, Lua, etc.) has just as much stuff working for it. Even the "but our libraries are 'designed' for async!" isn't as big of an advantage as is claimed, since in many cases the other languages have good libraries too. (Or in the case of something like gevent, a reasonable ability to convert libraries to async.) It's really a throwback, not the awesome step forward it claims to be.

CmonDev 13y ago

The new Silver Bullet is born! Will get you best developers, cut bad things 50% and improve good things 2x! JS is the only language you will _ever_ need!

Kiro 13y ago

> NPM effectively kills the possibility of experiencing dependency hell Am I the only one feeling that package management is the cause of dependency hell? Doing it the old school way where you just always have all the dependencies in the repo will never lead to these problems.

KaiserPro 13y ago

"sidestep threading issues" I think displacing them is more apt. complex Callbacks just as nasty as complex threads.

pjmlp 13y ago

Err, no.

AgLiAn 13y ago

Propaganda.

exabrial 13y ago

Because the hipsters thought it was a good idea? Once they realize it's impossible to maintain your codebase they'll all moved on to create their next disaster.

jbeja 13y ago

When Lua will become the go-to technology?

camus2 13y ago

nodejs will live on because it uses js which is mandatory in the browser,for better or worse. Hopefully ES6 and futures versions will make this awfull language much better.

VeejayRampay 13y ago
I really wish ES6 does that because as it is, Javascript only has two things going for it: the speed provided by the big boys (V8, xMonkey, etc) and the fact that it's only language available on the web. And none of those are merits of the language itself. Kind of sad.

rbanffy 13y ago

JavaScript seems to be enormously popular among non-programmers. ;-)

edem 13y ago

I wonder how can you build a reliable e-commerce platform on a database which is not ACID...and node users typically use MongoDB and other NoSQL databases which does not support transactions.

warcode 13y ago
Amazon seems to be doing alright. http://aws.amazon.com/dynamodb/faqs/ http://aws.amazon.com/dynamodb/faqs/
camus2 13y ago
It's true that the most mature DB framework on nodejs plateform is Mongoose,so usually nodejs devs use mongoose to deal with data. No need to say that MongoDB is not the right choice for apps that need transactions or when datas are heavily relational. And Mongoose doesnt support cascade operations. Sequelize or Bookshelf are not mature enough for now IMHO,compared to what one can find on other plateforms like Java,Ruby or PHP. So you either need to write raw sql queries or delegate all transactions to another app layer.

tyler-codenvy 13y ago

I have read the article and this thread with keen interest. I am curious to solicit community feedback on our choices as we faced the Node vs. Java choice in 2012. In particular, does our business ultimately suffer long term consequences by our stack choice? We think we ultimately have strong advantages vs. any competitor built using Node.JS, but the beauty of HN is that we can open up the thoughts for everyone to contribute. I am the CEO and founder of Codenvy. We make SAAS developer environments, and have been working as a team since 2009. Starting in 2012, we recognized the limitations of our initial system and needed to rebuild the entire system from the ground up. We had three criteria: performance, security, and modularity (of our core base and an ability for ISVs / enterprise to plug-in their own customizations). We raised $9M in Jan 2013, so we now have big investors and aspirations equally large. Our target market is primarily enterprises and ISVs that build Eclipse plug-ins. Individual developers and consultants are a secondary audience. We chose to go with a pure Java stack, after a careful evaluation of Node.JS vs. Java. We wanted to provide some of our thoughts, as we continually ask ourselves whether there are downsides to the approach we chose. For the record, we have competitors like Eclipse Orion and Cloud9 that are pure JavaScript / Node implementations, but we are - as far as I have seen - the only Java implementation in our market. Our team is currently 40 people, with 35 or so in R&D. Our engineers have experience with Java, Scala, JavaScript, AngularJS. Prior to this project, most engineers were working on server systems for content and document management firms. The hard stuff: sync, versioning, correlation, and so on. As for myself, my career started as a Java engineer in the 90s, but for the most part have been hands off as a technologist for a decade. My skills may have faded, but as a CEO, I am conversant. We did 2 prototypes on Node.JS where the client and server were combined systems. We ran a battery of performance tests and did conclude that we could probably run a large scale system on fewer physical nodes with Node.JS than with Java, but the gains were not enough to justify the choice. Our long term architecture was different from our competitors. Most SAAS dev environments provision each user / group their own VM, give you root access, and let you control that system. We chose an approach that would optimize overall system density by by offloading builds, debugs, and editing onto separate clusters. User environments will be virtualized and routed to the appropriate cluster on-demand. The user will feel like they have a personal VM, but our elvish helpers route traffic between the nodes across performance queues. After offloading LDAP (for identity), event / log management (for analytics), and cloud administration, the only core systems left was our API services (account / builder / runner / auth) and editing. These core systems would be subject to heavy iterative development, and Node's architecture could offer higher density of requests / users than Java, but by our tests the comparison was 10-20% difference, not 300%. By way of scaling, for every 10,000 concurrent developers, we average 20 editing nodes (I/O constrained), 75 debugging nodes (memory constraining), 5 builder nodes (CPU constrained). A similar TS / VDI implementation would require nearly 5,000 nodes of the same shape / size to service the same population. So, we saw a disadvantage to Java as we could have reduced our editing node even further. But we chose Java because: a) The library selection. Broad and mature. In particular, it's data structures, file management, REST services. b) GWT. This library gave us cross-browser portability of code written in Java. c) Eclipse Plug-Ins. We knew we wanted to target Eclipse plug-in developers and saw the Orion project as optimized for Web dev, leaving a gap in Eclipse. We saw it as a business gamble that Eclipse devs who needed to move their plug-ins would find a pure Java plug-in architecture that was similar to RCP more attractive than a newer (but have to learn new tech & rewrite) approach. d) Our history. We did a straw poll of our engineers before we started. We asked them if they felt that they would rather do Node or Java, and 75% said that they would enjoy Java more. When asked why? They had tool familiarity, were confident in the maturity of maven, and better job prospects. This last one completely surprised me. e) JVM. The number of optimizations of the JVM would give us advantages for enterprise deployment. We built our system to be automatically installable on-premises. We do so with Puppet, but recognized that we would be encountering many IAAS and PAAS standards internally. Enterprises had security and performance tested the JVM, so we saw an opportunity to win hearts and minds of system admins, datacenter architects, and security specialists by our choice of architecture. So, we carried forward. Since we started working on our next generation architecture, we have focused hard on the best practices associated with agile, devops, and continuous delivery. We have 7 teams of 4-6 people, each focused on a different aspect of our stack. We are able to release any Jira issue at any point in the day. Each team can push into acceptance, staging or production without coordinating with the other teams. At the same time, we have achieved modularity and a rapid development tempo. While we haven't released our new system to the market yet, we find that the performance of the environment is similar to a desktop environment, and it scales cleanly with simulated load tests. We have also been able to give out our SDK (github.com/codenvy/sdk) to 6 different partners, some of which are Eclipse plug-in developers, who are able to code, build, test, integrate, and publish their plug-ins without complicated dependencies to our core team. Their feedback was that the port of their plug-in took about 1/2 the time of the original development. And there is no real way to estimate what the effort would be to do the same in a Node-based offering like Orion. What we can't measure is whether our competitors are able to release faster & more functionality than we are. It seems like a crap shoot. One other variable we can't account for is the cost to maintain legacy. The system we have Codenvy.com is legacy for us, and will be retired in Q3. We have to continually allocate 3-5 people to work on bugs, special partner projects, or other related items to keep that system live while we also work to roll out the new system. We know this is a drag, and some of our engineers think we may more than double our productivity once we consolidate to a single architecture. I am a bit skeptical at that - but I find that it's unwise to disagree with my engineers. I tend to lose. So at this point, we feel like we made the right choice. But time will tell - we begin selling our enterprise offering earnestly once we ship our new system in Q2. Looking forward to the discussion.