8 ms·

What an odd trend. First Netflix moves part of their infrastructure to Node (https://news.ycombinator.com/item?id=8631022 https://news.ycombinator.com/item?id=8

by remon 12y ago

What an odd trend. First Netflix moves part of their infrastructure to Node (https://news.ycombinator.com/item?id=8631022 https://news.ycombinator.com/item?id=8631022) and now Yahoo is doing something similar. Node.js is great but I don't think huge enterprise systems for some of the largest brands in the world are necessarily the best fit. I wish they'd provide some insights on why they're making that particular move.

loxs 12y ago
Yep, node.js is the new PHP. Not by how it works, but by "shit everyone uses". Now, I won't try to convince anyone that it's crap (while I do believe it is), but it's the modern crap technology. Welcome to 1998, we are all "modern".
- twerquie 12y ago
  Care to back up any of your assertions? If your main complaint is popularity, your argument comes off as elitist.
  - loxs 12y ago
    Here: https://news.ycombinator.com/item?id=8662605 https://news.ycombinator.com/item?id=8662605
    - twerquie 12y ago
      I've responded there, sorry for the noise.
- general_failure 12y ago
  What framework would you suggest server side?
  - remon 12y ago
    I would argue the discussion is less about which framework and more about the suitability of the language. It's a debate worth having but I struggle to think of good arguments to move infrastructure of this sort of scope to JavaScript over the more "typical" options (Java/Scala, .NET, Python, go, erlang, etc.). JavaScript obviously has a place in web application development, I'm just not convinced that place is on servers in the vast majority of cases.
  - loxs 12y ago
    Disclaimer: I am a full-time Erlang programmer I use several frameworks/libs for different tasks: Webmachine, N2O, Cowboy I don't believe in RoR type of frameworks. I believe in clear separation between server and client. We are steadily moving towards a web of websockets and "one page JS applications". Won't comment on whether that is nice thing or not. I am not sure for myself. For client we are stuck with JS. Sucks but it's a fact of life. Erlang (or other things using this model, though, nothing as mature exists) is the only sane way of writing "multi-user" or "mega-user" servers. For me, server side is a solved problem (because of Erlang). And I'm talking about huge, clustered backends. Node.js feels like a child's toy compared to Erlang. I would suggest that everyone who claims to be a web programmer should at least know how to use Erlang. Otherwise, you aren't really aware of how big the world really is. And what is possible actually. This may sound elitist, and it probably is, and I am probably not a good person for talking like that. But you can't really argue with things like this: http://blog.whatsapp.com/196/1-million-is-so-2011 http://blog.whatsapp.com/196/1-million-is-so-2011 Once you have experienced things like this, and once you really understand why it works and how to steadily reproduce it on every project you work on... well, that's why I claim that server side is a solved problem.
    - davidw 12y ago
      As someone who knows their way around Erlang, it needs some work for more 'average joe' programmers to get much done with it. I'm not talking about the syntax, but some set of libraries or a framework or something that gets people up and running quickly. Chicago Boss is interesting, but it's not very Erlangy (it uses compiler magic). Edit: that said, a big company would certainly have the resources to make Erlang work well for web development, and, yes, it's way more solid than Node.js from an architectural point of view.
- Igglyboo 12y ago
  node.js is the new PHP for hip web developers who read HN. It's still a relatively unheard of platform to most people and mocked by a lot as well. I love it though.
  - k__ 12y ago
    Well, if you are like me, who worked with PHP for years, node.js feels nicer to use. Npm alone makes it better than PHP ever was.
    - Igglyboo 12y ago
      NPM is great, haven't used PHP but it blows Python's pip out of the water IMO.
      - tootie 12y ago
        NPM chokes for me about 1 time out of 10. The main repo has reliability issues. A lot of the libs install executables that require sudo. Java solved dependency management years ago. I don't know why every language doesn't just rely on a classpath.
        woah 12y ago
        I've never had any issues with npm and I started coding about 2 years ago. In fact I didn't have any issues with npm when I first started. Maybe you need to have a friend show you how to do it correctly. I can't imagine what your issue is.
        LunaSea 12y ago
        Same here. No issues in more than two years.
      - notastartup 12y ago
        used npm, and started using pip. it was way better because you could use python and not javascript.
- aikah 12y ago
  > Yep, node.js is the new PHP. No,it's way too low level to be "the new PHP",and frankly async programming is hard,way harder than writing sync code by default.
bhouston 12y ago
Remember that Paypal did this as well about a year ago. (This is the best link I can find quickly: https://www.paypal-engineering.com/2013/11/22/node-js-at-paypal/ https://www.paypal-engineering.com/2013/11/22/node-js-at-pay... I am sure there are more.)
- wildpeaks 12y ago
  Paypal recently had an interesting follow-up talk "9 anti-patterns for node.js teams" about what they learnt in the past year. Slides: http://www.slideshare.net/jeharrell/9-antipatterns-for-nodejs-teams http://www.slideshare.net/jeharrell/9-antipatterns-for-nodej... Video: https://www.youtube.com/watch?v=6phif2t-wj0 https://www.youtube.com/watch?v=6phif2t-wj0
  - barosl 12y ago
    It is surprising to me that they recommend callbacks over promises! I had no idea that promises require higher CPU resources.
    - spion 12y ago
      Hmm, those are strange results indeed. I would not be surprised if those measurements were made a year ago. Back then, promises were really slow. But then bluebird came out and changed everything, and many of the other promise libraries followed suit. Most promise libs are now really lightweight (with the only remaining exception being Q). See https://gist.github.com/spion/6990910 https://gist.github.com/spion/6990910 ; http://spion.github.io/posts/why-i-am-switching-to-promises.html http://spion.github.io/posts/why-i-am-switching-to-promises.... ; https://github.com/spion/async-compare/blob/master/latest-results.md https://github.com/spion/async-compare/blob/master/latest-re... - For example, bluebird (and most other promise libraries today) have 2 to 3 times lower overhead than caolan's async and are comparable to the most hand-optimized raw callbacks.
nkozyra 12y ago
I'd say, more than anything, the benefit it provides is more personnel-related than anything. While there are definitely dedicated server-side and client side JS people, speaking the "same language" helps within teams and allows for some shared responsibilities. That's appealing to large organizations with decent turnover.
- remon 12y ago
  I think you've touched upon the strongest argument for using JavaScript within a server stack. That said, that argument seems less strong for companies the size of Netflix, Yahoo, and so on. They don't exactly have problems recruiting top engineers. Curious stuff.
  - nkozyra 12y ago
    Recruiting? No, absolutely not. But maintaining? I mean if you can move in and out of server and front side, that might build some lasting engagement with developers. It also encourages an ecosystem wherein almost any developer out there can work on either side for you.
- mtbcoder 12y ago
  Is that not essentially bending the entire server side stack to the will of the LCD developers because they are only familiar with JavaScript?
hoggle 12y ago
I've got first hand experience with this at a major airline - node is a surprisingly good fit for Bigco because it is encouraging modularization and has very predictable dependency management but most of all it allows you to fit it into your current systems easily and organically. There is not much convention (also an argument against it in some cases) other than being in many ways a very "unix" kind of environment (streams etc) with the added benefit of having Javascript's functional/event-driven roots. Most of all to me node is fun which is especially important when you have to conquer problems in un-fun environments (most Bigco systems).
guard-of-terra 12y ago
I don't think they have mail storage, spooling and sending implemented in node.js. I think they use both PHP before and node.js now as a front tier. And this is okay, it's where node.js shines.
- virmundi 12y ago
  See, this confuses me. From working with Node and understanding its core architectural concept, the single event loop, I find Node's worst use case to be front end development. Server side rendering takes time, even 10 ms. On an single event loop, that is terrible. You can only server 100 request/second due to the 10 ms limit. While it is nice that you can move a request into the backing queue while waiting for the data, you're capped at 100 requests/second. Where I think Node shines is low level network management. Netflix could use it to pipe video data from one of its boxes out to a user. It's got that kind of work built right into it. As a result, I think that storage, spooling and possibly even sending would be best in Node. Those are largely I/O bound, schlep data from port to port operations. My understanding of PHP is that it's really hard to have really global variables. Compare this to Node.js where Javascript naturally does this. I can't find it now, but I remember back when Node was young a guy had an issue with his shopping cart system. People's orders were screwed up. Turns out that he missed a `var` in a function. PHP, I don't think, could do this easily since the widest screw up scope is file. So you're still limited to request scoping.
  - jdhawk 12y ago
    Well...there is the global operator, and it takes into account the entire running "stack of files" - so include your config.php, lib.php wrappers, which in turn include other files for your application/framework, and then use the global $var tag in every function, and you get a reference to a truly global variable. http://php.net/manual/en/language.variables.scope.php http://php.net/manual/en/language.variables.scope.php PHP also has "superglobals" http://php.net/manual/en/language.variables.superglobals.php http://php.net/manual/en/language.variables.superglobals.php
  - euroclydon 12y ago
    Well, Node has clustering, and there is probably some nifty load-balancer that works with Nginx and Node. http://nodejs.org/api/cluster.html http://nodejs.org/api/cluster.html
Todd 12y ago
Speaking from personal experience, I'm reluctantly moving from my favorite stack (C# MVC) to Node.js in order to be able to build an isomorphic SPA in the most straightforward way. Node is the stack of choice for JS and the obvious choice if you want to render on the client and the server using as much shared code as possible. That said, you're still free to develop your API using your favorite technologies. To be honest, this is where the heavy lifting is, anyway, so it makes sense to have stronger typing, richer data types, etc. at this level.
- remon 12y ago
  Fair point. I suppose the debate should be about API and "lower" tiers mostly.
- xtrumanx 12y ago
  As a C# developer, I too am building isomorphic apps currently in NodeJS (with ReactJS). Then I found out about ReactJS.NET [0] which allows for server-side rendering of ReactJS components from ASP.NET. I haven't had a chance to try it out properly yet but my preliminary test of it made it seem plausible for creating isomorphic apps in ASP.NET. Have you given it a shot? If so, what are your thoughts? [0] http://reactjs.net/ http://reactjs.net/
  - Todd 12y ago
    I've experimented with it. I think it's a great solution if you really want to stay with a uniform stack (as much as is possible, anyway). What I came to realize, though, is that the Razor views were just scaffolding. You would need to re-implement any such scaffolding in your client-side views. The next problem is the router. Any client-side routes will need to be mirrored on the server if you want isomorphism. This means you're using two routers. Many Node solutions will use different routers on the client and server, but there are a growing number that can be shared. The router is my biggest stumbling block right now in my road to React. There are a variety. There seems to be a consensus around react-router, but now we have the Yahoo contribution. There are two problems that I'm having. The first is that, if you want to use HTML5 History (instead of the dreaded hash bang), you're kind of on your own. There is usually little documentation on how best to handle this. If you do this, you have to intercept and prevent navigation, but only for the relevant local routes, of course. This is intimately tied to eventing. If you're using React, you'll probably use React events (vs, say jQuery). The next issue is that most of the examples out there are simplistic. They will show a simple page with one component embedded that swaps out a part of the view. Any real app will require layouts, views, and components. Some of these levels will vary based on routes. ASP.NET has an elegant solution for this. I haven't seen an analogy with React + router. I think part of my problem is that I'm still ramping up. I'm guessing that this is largely teething pains.
toong 12y ago
Wallmart is another notable node.js user. Related: https://news.ycombinator.com/item?id=6784967 https://news.ycombinator.com/item?id=6784967 http://venturebeat.com/2012/01/24/why-walmart-is-using-node-js/ http://venturebeat.com/2012/01/24/why-walmart-is-using-node-...
- at-fates-hands 12y ago
  Also notable is their run down of a famous memory leak in NodeJS. http://www.joyent.com/blog/walmart-node-js-memory-leak http://www.joyent.com/blog/walmart-node-js-memory-leak Eran's recounting of the issue: https://www.joyent.com/developers/videos/walmart-node-js-memory-leak-part-1 https://www.joyent.com/developers/videos/walmart-node-js-mem... It's interesting to note despite the memory link, the incredible amount of traffic WalMart was handling with its Mobile apps running on NodeJS. That's what was more impressive to me.
hueyp 12y ago
I've watched a presentation where (I think) Linkedin talked about their use of node.js. They used it as an API Gateway (http://microservices.io/patterns/apigateway.html http://microservices.io/patterns/apigateway.html). The main requirements for this are making a lot of service calls quickly and transforming several JSON documents into a single JSON response. Node.js is actually pretty reasonable for this.
brador 12y ago
> I don't think huge enterprise systems for some of the largest brands in the world are necessarily the best fit Why??
- tootie 12y ago
  Not OP, but I'll chime in. Enterprise software has some unique challenges. Enterprises deal with a galaxy of small systems, a mixture of proprietary and purchased software, a mix of IT staff and consultants, leadership who may or not have techology as a core competency, frequently a lot of bureaucracy and compliance rules, lots of long-running maintenance and as a corollary, you may retain a lot of lower-tier talent if you're recruting developers to maintain an 8 year old expense reporting system. All of these scream for safety and risk mitigation more than pushing the envelope. Static typing, schemas, battle tested development tools, lots of vendor support, big pool of talent to recruit from. There's no appetite for risk taking especially when the benefits are so hard for management to understand. As a developer at a consulting company, my peers understand technology very well but clients are 50/50. They mostly standardize on Java or .NET and and I don't think I could even put together a cogent argument of why node would help them at all. Maybe personal bias because I think node is kinda shitty and my limited exposure has been nothing but painful.
  - LunaSea 12y ago
    Paypal switched to Node.js from Java (I think) and they divided their amount of servers by two.
- emergentcypher 12y ago
  Because javascript.
- serve_yay 12y ago
  Some people still think of JS as a toy language.
mbesto 12y ago
Two reasons - mobile and support. Mobile, because everything on the web is moving towards API-based backends decoupled from the presentation layer. Support, because "everyone" knows how to write JavaScript.
- edwinnathaniel 12y ago
  > Support, because "everyone" knows how to write JavaScript. ... badly written JS, sad, unfortunately that's the fact.

by remon 12y ago

loxs 12y ago

Yep, node.js is the new PHP. Not by how it works, but by "shit everyone uses". Now, I won't try to convince anyone that it's crap (while I do believe it is), but it's the modern crap technology. Welcome to 1998, we are all "modern".

twerquie 12y ago
Care to back up any of your assertions? If your main complaint is popularity, your argument comes off as elitist.
- loxs 12y ago
  Here: https://news.ycombinator.com/item?id=8662605 https://news.ycombinator.com/item?id=8662605
  - twerquie 12y ago
    I've responded there, sorry for the noise.
general_failure 12y ago
What framework would you suggest server side?
- remon 12y ago
  I would argue the discussion is less about which framework and more about the suitability of the language. It's a debate worth having but I struggle to think of good arguments to move infrastructure of this sort of scope to JavaScript over the more "typical" options (Java/Scala, .NET, Python, go, erlang, etc.). JavaScript obviously has a place in web application development, I'm just not convinced that place is on servers in the vast majority of cases.
- loxs 12y ago
  Disclaimer: I am a full-time Erlang programmer I use several frameworks/libs for different tasks: Webmachine, N2O, Cowboy I don't believe in RoR type of frameworks. I believe in clear separation between server and client. We are steadily moving towards a web of websockets and "one page JS applications". Won't comment on whether that is nice thing or not. I am not sure for myself. For client we are stuck with JS. Sucks but it's a fact of life. Erlang (or other things using this model, though, nothing as mature exists) is the only sane way of writing "multi-user" or "mega-user" servers. For me, server side is a solved problem (because of Erlang). And I'm talking about huge, clustered backends. Node.js feels like a child's toy compared to Erlang. I would suggest that everyone who claims to be a web programmer should at least know how to use Erlang. Otherwise, you aren't really aware of how big the world really is. And what is possible actually. This may sound elitist, and it probably is, and I am probably not a good person for talking like that. But you can't really argue with things like this: http://blog.whatsapp.com/196/1-million-is-so-2011 http://blog.whatsapp.com/196/1-million-is-so-2011 Once you have experienced things like this, and once you really understand why it works and how to steadily reproduce it on every project you work on... well, that's why I claim that server side is a solved problem.
  - davidw 12y ago
    As someone who knows their way around Erlang, it needs some work for more 'average joe' programmers to get much done with it. I'm not talking about the syntax, but some set of libraries or a framework or something that gets people up and running quickly. Chicago Boss is interesting, but it's not very Erlangy (it uses compiler magic). Edit: that said, a big company would certainly have the resources to make Erlang work well for web development, and, yes, it's way more solid than Node.js from an architectural point of view.
Igglyboo 12y ago
node.js is the new PHP for hip web developers who read HN. It's still a relatively unheard of platform to most people and mocked by a lot as well. I love it though.
- k__ 12y ago
  Well, if you are like me, who worked with PHP for years, node.js feels nicer to use. Npm alone makes it better than PHP ever was.
  - Igglyboo 12y ago
    NPM is great, haven't used PHP but it blows Python's pip out of the water IMO.
    - tootie 12y ago
      NPM chokes for me about 1 time out of 10. The main repo has reliability issues. A lot of the libs install executables that require sudo. Java solved dependency management years ago. I don't know why every language doesn't just rely on a classpath.
      - woah 12y ago
        I've never had any issues with npm and I started coding about 2 years ago. In fact I didn't have any issues with npm when I first started. Maybe you need to have a friend show you how to do it correctly. I can't imagine what your issue is.
        LunaSea 12y ago
        Same here. No issues in more than two years.
    - notastartup 12y ago
      used npm, and started using pip. it was way better because you could use python and not javascript.
aikah 12y ago
> Yep, node.js is the new PHP. No,it's way too low level to be "the new PHP",and frankly async programming is hard,way harder than writing sync code by default.

bhouston 12y ago

Remember that Paypal did this as well about a year ago. (This is the best link I can find quickly: https://www.paypal-engineering.com/2013/11/22/node-js-at-paypal/ https://www.paypal-engineering.com/2013/11/22/node-js-at-pay... I am sure there are more.)

wildpeaks 12y ago
Paypal recently had an interesting follow-up talk "9 anti-patterns for node.js teams" about what they learnt in the past year. Slides: http://www.slideshare.net/jeharrell/9-antipatterns-for-nodejs-teams http://www.slideshare.net/jeharrell/9-antipatterns-for-nodej... Video: https://www.youtube.com/watch?v=6phif2t-wj0 https://www.youtube.com/watch?v=6phif2t-wj0
- barosl 12y ago
  It is surprising to me that they recommend callbacks over promises! I had no idea that promises require higher CPU resources.
  - spion 12y ago
    Hmm, those are strange results indeed. I would not be surprised if those measurements were made a year ago. Back then, promises were really slow. But then bluebird came out and changed everything, and many of the other promise libraries followed suit. Most promise libs are now really lightweight (with the only remaining exception being Q). See https://gist.github.com/spion/6990910 https://gist.github.com/spion/6990910 ; http://spion.github.io/posts/why-i-am-switching-to-promises.html http://spion.github.io/posts/why-i-am-switching-to-promises.... ; https://github.com/spion/async-compare/blob/master/latest-results.md https://github.com/spion/async-compare/blob/master/latest-re... - For example, bluebird (and most other promise libraries today) have 2 to 3 times lower overhead than caolan's async and are comparable to the most hand-optimized raw callbacks.

nkozyra 12y ago

I'd say, more than anything, the benefit it provides is more personnel-related than anything. While there are definitely dedicated server-side and client side JS people, speaking the "same language" helps within teams and allows for some shared responsibilities. That's appealing to large organizations with decent turnover.

remon 12y ago
I think you've touched upon the strongest argument for using JavaScript within a server stack. That said, that argument seems less strong for companies the size of Netflix, Yahoo, and so on. They don't exactly have problems recruiting top engineers. Curious stuff.
- nkozyra 12y ago
  Recruiting? No, absolutely not. But maintaining? I mean if you can move in and out of server and front side, that might build some lasting engagement with developers. It also encourages an ecosystem wherein almost any developer out there can work on either side for you.
mtbcoder 12y ago
Is that not essentially bending the entire server side stack to the will of the LCD developers because they are only familiar with JavaScript?

hoggle 12y ago

I've got first hand experience with this at a major airline - node is a surprisingly good fit for Bigco because it is encouraging modularization and has very predictable dependency management but most of all it allows you to fit it into your current systems easily and organically. There is not much convention (also an argument against it in some cases) other than being in many ways a very "unix" kind of environment (streams etc) with the added benefit of having Javascript's functional/event-driven roots. Most of all to me node is fun which is especially important when you have to conquer problems in un-fun environments (most Bigco systems).

guard-of-terra 12y ago

I don't think they have mail storage, spooling and sending implemented in node.js. I think they use both PHP before and node.js now as a front tier. And this is okay, it's where node.js shines.

virmundi 12y ago
See, this confuses me. From working with Node and understanding its core architectural concept, the single event loop, I find Node's worst use case to be front end development. Server side rendering takes time, even 10 ms. On an single event loop, that is terrible. You can only server 100 request/second due to the 10 ms limit. While it is nice that you can move a request into the backing queue while waiting for the data, you're capped at 100 requests/second. Where I think Node shines is low level network management. Netflix could use it to pipe video data from one of its boxes out to a user. It's got that kind of work built right into it. As a result, I think that storage, spooling and possibly even sending would be best in Node. Those are largely I/O bound, schlep data from port to port operations. My understanding of PHP is that it's really hard to have really global variables. Compare this to Node.js where Javascript naturally does this. I can't find it now, but I remember back when Node was young a guy had an issue with his shopping cart system. People's orders were screwed up. Turns out that he missed a `var` in a function. PHP, I don't think, could do this easily since the widest screw up scope is file. So you're still limited to request scoping.
- jdhawk 12y ago
  Well...there is the global operator, and it takes into account the entire running "stack of files" - so include your config.php, lib.php wrappers, which in turn include other files for your application/framework, and then use the global $var tag in every function, and you get a reference to a truly global variable. http://php.net/manual/en/language.variables.scope.php http://php.net/manual/en/language.variables.scope.php PHP also has "superglobals" http://php.net/manual/en/language.variables.superglobals.php http://php.net/manual/en/language.variables.superglobals.php
- euroclydon 12y ago
  Well, Node has clustering, and there is probably some nifty load-balancer that works with Nginx and Node. http://nodejs.org/api/cluster.html http://nodejs.org/api/cluster.html

Todd 12y ago

Speaking from personal experience, I'm reluctantly moving from my favorite stack (C# MVC) to Node.js in order to be able to build an isomorphic SPA in the most straightforward way. Node is the stack of choice for JS and the obvious choice if you want to render on the client and the server using as much shared code as possible. That said, you're still free to develop your API using your favorite technologies. To be honest, this is where the heavy lifting is, anyway, so it makes sense to have stronger typing, richer data types, etc. at this level.

remon 12y ago
Fair point. I suppose the debate should be about API and "lower" tiers mostly.
xtrumanx 12y ago
As a C# developer, I too am building isomorphic apps currently in NodeJS (with ReactJS). Then I found out about ReactJS.NET [0] which allows for server-side rendering of ReactJS components from ASP.NET. I haven't had a chance to try it out properly yet but my preliminary test of it made it seem plausible for creating isomorphic apps in ASP.NET. Have you given it a shot? If so, what are your thoughts? [0] http://reactjs.net/ http://reactjs.net/
- Todd 12y ago
  I've experimented with it. I think it's a great solution if you really want to stay with a uniform stack (as much as is possible, anyway). What I came to realize, though, is that the Razor views were just scaffolding. You would need to re-implement any such scaffolding in your client-side views. The next problem is the router. Any client-side routes will need to be mirrored on the server if you want isomorphism. This means you're using two routers. Many Node solutions will use different routers on the client and server, but there are a growing number that can be shared. The router is my biggest stumbling block right now in my road to React. There are a variety. There seems to be a consensus around react-router, but now we have the Yahoo contribution. There are two problems that I'm having. The first is that, if you want to use HTML5 History (instead of the dreaded hash bang), you're kind of on your own. There is usually little documentation on how best to handle this. If you do this, you have to intercept and prevent navigation, but only for the relevant local routes, of course. This is intimately tied to eventing. If you're using React, you'll probably use React events (vs, say jQuery). The next issue is that most of the examples out there are simplistic. They will show a simple page with one component embedded that swaps out a part of the view. Any real app will require layouts, views, and components. Some of these levels will vary based on routes. ASP.NET has an elegant solution for this. I haven't seen an analogy with React + router. I think part of my problem is that I'm still ramping up. I'm guessing that this is largely teething pains.

toong 12y ago

Wallmart is another notable node.js user. Related: https://news.ycombinator.com/item?id=6784967 https://news.ycombinator.com/item?id=6784967 http://venturebeat.com/2012/01/24/why-walmart-is-using-node-js/ http://venturebeat.com/2012/01/24/why-walmart-is-using-node-...

at-fates-hands 12y ago
Also notable is their run down of a famous memory leak in NodeJS. http://www.joyent.com/blog/walmart-node-js-memory-leak http://www.joyent.com/blog/walmart-node-js-memory-leak Eran's recounting of the issue: https://www.joyent.com/developers/videos/walmart-node-js-memory-leak-part-1 https://www.joyent.com/developers/videos/walmart-node-js-mem... It's interesting to note despite the memory link, the incredible amount of traffic WalMart was handling with its Mobile apps running on NodeJS. That's what was more impressive to me.

hueyp 12y ago

I've watched a presentation where (I think) Linkedin talked about their use of node.js. They used it as an API Gateway (http://microservices.io/patterns/apigateway.html http://microservices.io/patterns/apigateway.html). The main requirements for this are making a lot of service calls quickly and transforming several JSON documents into a single JSON response. Node.js is actually pretty reasonable for this.

brador 12y ago

> I don't think huge enterprise systems for some of the largest brands in the world are necessarily the best fit Why??

tootie 12y ago
Not OP, but I'll chime in. Enterprise software has some unique challenges. Enterprises deal with a galaxy of small systems, a mixture of proprietary and purchased software, a mix of IT staff and consultants, leadership who may or not have techology as a core competency, frequently a lot of bureaucracy and compliance rules, lots of long-running maintenance and as a corollary, you may retain a lot of lower-tier talent if you're recruting developers to maintain an 8 year old expense reporting system. All of these scream for safety and risk mitigation more than pushing the envelope. Static typing, schemas, battle tested development tools, lots of vendor support, big pool of talent to recruit from. There's no appetite for risk taking especially when the benefits are so hard for management to understand. As a developer at a consulting company, my peers understand technology very well but clients are 50/50. They mostly standardize on Java or .NET and and I don't think I could even put together a cogent argument of why node would help them at all. Maybe personal bias because I think node is kinda shitty and my limited exposure has been nothing but painful.
- LunaSea 12y ago
  Paypal switched to Node.js from Java (I think) and they divided their amount of servers by two.
emergentcypher 12y ago
Because javascript.
serve_yay 12y ago
Some people still think of JS as a toy language.

mbesto 12y ago

Two reasons - mobile and support. Mobile, because everything on the web is moving towards API-based backends decoupled from the presentation layer. Support, because "everyone" knows how to write JavaScript.

edwinnathaniel 12y ago
> Support, because "everyone" knows how to write JavaScript. ... badly written JS, sad, unfortunately that's the fact.