8 ms·

If you are thinking about using node.js for this reason[1] on most sites, you are optimizing poorly. LinkedIn didn't worry about this until after they were a pu

If you are thinking about using node.js for this reason[1] on most sites, you are optimizing poorly. LinkedIn didn't worry about this until after they were a public company. If Python/Djando or Ruby/Rails can get your app out the door and into customer hands faster, it is almost always the right thing to use. 1. There are certainly other, very valid, technical reasons for choosing node.js over other technologies early. But let those reasons be about the problems you are solving today, not the ones you might need to worry about when you have 50 servers to deal with.

Smudge 14y ago
I'm sure LinkedIn could have cut servers without switching to node. Take your first, crappy implementation and rewrite it in the same language and you'll probably still see at least 10x improvement, if not 20.
- asianexpress 14y ago
  My thoughts exactly -- going from 30 to 3 servers is no joke and it couldn't just be because of a move to node.js
- nicholassmith 14y ago
  This times a thousand. When you first write the software you're basing it on expectations, no matter how well you plan, but when you rewrite it you're coming at it with real world knowledge of the pain points so of course it's going to be better in terms of performance.
  - omaranto 14y ago
    "This times a thousand" would be an improvement by a factor of 10000. The improvement should definitely not be that large.
    - skeletonjelly 14y ago
      You're getting downvoted because the poster was referring to the gravity/importance of the message.
    - omaranto 14y ago
      Thanks for the explanation, skeletonjelly. I think the reason I misunderstood is that I don't hang out on the Internet enough: a friend explained to me that "This." and "this times a thousand" are Internet slang that mean "I agree" (the second, presumably means something like "On a scale from 1 to infinity my agreement level is 1000." :). As far I know these expressions aren't used verbally, which would explain why I took it literally.
      - xenophanes 14y ago
        It means repeat it a thousand times for emphasis.
    - dguaraglia 14y ago
      LOL, apparently sarcasm and witty banter is not HN forte :P
    - freditup 14y ago
      We don't all have English as our first language, and there's no problem with that. I'd have replied exactly as you did if I thought he literally meant "this times a thousand"
    - nicholassmith 14y ago
      I included an extra bit of improvement to deal with inflation rates.
- ericcholis 14y ago
  I'm with you on this one. I'm currently in the process of re-platforming and I'm noticing considerable gains just from revising the way certain process are done. You find a lot of "wtf was I thinking".
- pdelgallego 14y ago
  >> Take your first, crappy implementation and rewrite it in the same language and you'll probably still see at least 10x improvement. You will probably will get the same mess. There is plenty of literature about that. I.e: A complete rewrite is what killed Netscape
  - ahupp 14y ago
    I think this taking the wrong lesson from Netscape. If you do a greenfield re-write of a multi-million line application you probably are going to have a bad time, but people successfully re-write smaller applications or portions of an application all the time. Since this was just a portion of the total functionality of LinkedIn, they incurred much less risk than a ground up rewrite would have.
  - Devilboy 14y ago
    Is moving from Rails to Node not a complete rewrite?
    - pyre 14y ago
      They just wrote a Ruby interpreter for Node.js. Node.js is just that fast.
      - OriginalSyn 14y ago
        Where can I see this?
        jrockway 14y ago
        You'll have to wait until April 1.
    - tedunangst 14y ago
      It doesn't count as a rewrite when the rewrite is in a language that's cooler than the original version.
  - 14y ago
- dkrich 14y ago
  I disagree. When you change state management to client side, you are making a fundamental architecture shift that is significant enough to remove a lot of server-side overhead. What makes you think refactoring code is going to give you a 10x improvement in efficiency? If your code is that bad, you should get rid of the developers along with the code.
  - dmorgan 14y ago
    >I disagree. When you change state management to client side, you are making a fundamental architecture shift that is significant enough to remove a lot of server-side overhead. In most cases, you're not. You're mostly making a big logic spaghetti mess on both the client and the server AND make your pages load slower, especially for the initial load (client performance, js loading times, etc). >What makes you think refactoring code is going to give you a 10x improvement in efficiency? Because even correctly implementing just the caching layer, with nested/micro-caching, can give you up to 1000x improvement in efficiency in the first place.
    - kevincennis 14y ago
      It's true that moving more logic and state management to the client side often increase page load times - but it also allows you (potentially) to make certain interactions much faster. When you have real data on the client instead of just a bunch of markup, you can be a lot smarter about how and when you make additional AJAX requests. Optimistic updates can make a huge difference in perceived performance.
  - deleted 14y ago
    [deleted]
- fleitz 14y ago
  Yeah as the article notes the old version used HTML and the new version uses binary blobs. This is hardly surprising.
- benologist 14y ago
  Node has some pretty unique benefits, I save a good $1000/month from switching from .NET on dedicateds to NodeJS on a PaaS (Heroku), and that was after 2 - 3 years of writing and rewriting and optimizing the .NET stuff. Biggest improvements came from persistant connections to redis/mongodb and polling for updated information independently of requests so there was no cached-or-fetch shenanigans at all in some areas.
  - statictype 14y ago
    What were the benefits you saw in switching from .NET to Node? Was it in basic code structure/complexity or performance? I'd actually be very surprised if NodeJS running on Heroku (which is built on EC2) performs better than compiled .NET code running on dedicated Windows hardware.
    - benologist 14y ago
      The major benefits were persistant connections and background fetching of data - a lot of my requests serve data directly from local memory instead of hitting local or shared caches and databases. The equivalent in .NET I guess would be BackgroundWorkers that are independently prefetching the data required most of the time but I could never get them to Just Work. Specifically for my use case 99+ percent of requests receive some data, do some light manipulations and then push the data to redis about 8,000 to 12,000 times a second. With .NET I could only push to locally running software instances because anything remote couldn't keep up with the connection volume (without throwing even more hardware at the problem).
      - statictype 14y ago
        Interesting. Thanks for the answer. I'm a little surprised that .NET can't juggle network connections very well but in retrospect, I probably shouldn't be.
        benologist 14y ago
        I think it's just whatever .NET's doing to pool them that has some tiny bit of overhead that doesn't matter most of the time.
- throwa 14y ago
  This article actually gives details of their first implementation which suggest that they could cut servers without switching to node : http://ikaisays.com/2012/10/04/clearing-up-some-things-about-linkedin-mobiles-move-from-rails-to-node-js/ http://ikaisays.com/2012/10/04/clearing-up-some-things-about...
lumberjack 14y ago
To be fair, Node.js isn't exactly harder to work with than Django or Rails. I myself had to choose between these about a year ago and despite the asynchronous paradigm I still found it relatively easy to start using in comparison to Rails and Django.
- astrodust 14y ago
  Node.js is extremely hard to work with compared to Rails and moderately hard to work with compared to Django. The Node.js ecosystem has a lot of potential, but the variety of off-the-shelf add-ons is severely limited compared to either of those more mature frameworks. If you think Node.js is easy, you've never really experimented enough to understand what makes Rails so effortless. It's a lot easier to produce a production-ready application with Rails than it is with Node.js as it is today. In four years, as Rails starts to add less critical features, Node.js may well have caught up.
  - erichocean 14y ago
    Node.js is extremely hard to work with compared to Rails and moderately hard to work with compared to Django. Pro tip: Don't put this on your resume.
    - mansoor-s 14y ago
      made me chuckle
    - andybak 14y ago
      Meaning?
    - astrodust 14y ago
      Coming from Rails, Node is like opening a toolbox and finding it has a screwdriver, a wrench, and a hammer. Somehow you're expected to build things with that. For those that love to build things from the ground up or to carve out new solutions, Node is a great place to be. I think it's got enormous potential and is biggest opportunity since Python and Ruby took off around years ago. Just don't think because you can create the same sorts of apps with Node that it's as easy. Ruby on Rails even three years ago was laughable compared to today's toolset. Node is catching up quickly, covering ground faster than Ruby ever did, but still lagging.
jonpaul 14y ago
Why not write your code using Node.js because you actually enjoy using JavaScript? Or how about the convenience of writing in one language in your stack? Or how about the simplicity provided by not having to worry about threading per process? If you already know Python or Ruby, then ya, using Node.js would be silly. But if you have to pick one because you're equally familiar with all of the languages, then Node.js isn't a bad choice at all.
- SoftwareMaven 14y ago
  You'll note I explicitly said there are reasons to choose it. And if you choose it for those reasons, great. Just don't choose it because it will solve your Mazzerati problem. Choose it for your problems today.
- andersbreivik 14y ago
  " because you actually enjoy using JavaScript? " You sick bastard!
todd3834 14y ago
After reading the article, the fact that they cut servers was just one of the advantages they got from using node.js
kin 14y ago
What I saw as a plus was that they combined front/back end teams into a single unit.
- jeremyjh 14y ago
  Am I the only person who doesn't believe this story? Because really, the whole reason we have front-end/back-end specialists is because front-end javascript ninjas can't learn RUBY??!?
  - kin 14y ago
    It's believable to me. The whole reason we have front-end/back-end specialist isn't because front-end js people can't learn Ruby but rather it's the same reason why front-end/back-end is separated code-wise. Depending on how they're using node they could very well keep this segregation. But some implementations with node have server/client sharing code. I know I've seen examples of this. I imagine that's how they're doing things.
    - ikailan 14y ago
      I don't think it's about the language - it's about knowledge. A backend specialist can learn Javascript but may not know the nuances of working with the DOM, or optimizing for pagespeed, or the important front end libraries. Similarly, a front-end specialist may not have all the experience necessary to diagnose problems in a deployment. That's one reason I don't buy the "front end developers can now do backend development because of node.js" argument. Any sufficient competent backend developer can start writing Python code in a day. What that developer doesn't get in a day is understanding deployments, popular Python libraries, the ecosystem, etc.
      - jeremyjh 14y ago
        Exactly.
      - kin 14y ago
        I'm not saying they've removed specialists. I believe they still exist. But in switching to node, because client/server shares a language, they're now capable of sharing code as well. Which is what I imagine they are doing, which is why it's logical that they've merged teams. This doesn't rule out that front/back-end specialists are removed and become well-rounded rather, they're just working together more.
markmm 14y ago
I would spend a little extra time upfront and save many many expensive rewrites latter on. Use C from the start, you won't need to rewrite just scale with hardware. This argument that using Ruby (or any language that makes programming easy but runs like treacle) to get something out the door a few months earlier is bullshit, I would rather release something a few months later that I didn't have to totally rewrite down the line 10 times.
- jonny_eh 14y ago
  But the odds of the thing you release actually getting used are low. So make it fast, and if it's a hit, then deal with that.
  - markmm 14y ago
    Wow!! your comment encapsulates the thinking of every wannabe startup loser that ends up smoking crack on some beach in San Francisco" Will making it faster increase the chances of more people using it? Also this attitude of building shit products (Yes software is a product) because..well the chances are it will fail.. is precisely why so many startups fail. This is why you get one crapola startup after another........ "Show HN: Crap.ly -- we built this in 3 weeks using Ruby, it will scale up to 20 users before craping out, its a twitter scraper that connects to app.net and diaspora showing how much Money your Kick-starter project has made and includes quotes from Paul Graham about how to build a successful startup, because he has built so many" Imagine Linus had built Linux using fucking node.js
    - bgilroy26 14y ago
      You're not yourself when you're hungry.
    - drstewart 14y ago
      Imagine your shock when you build your craptastic app in C++ and wonder why it's not any faster than a scripted app. I'll give you a hint ahead of time: most bottlenecks aren't processing time, they're DB or IO limited.

Smudge 14y ago

I'm sure LinkedIn could have cut servers without switching to node. Take your first, crappy implementation and rewrite it in the same language and you'll probably still see at least 10x improvement, if not 20.

asianexpress 14y ago
My thoughts exactly -- going from 30 to 3 servers is no joke and it couldn't just be because of a move to node.js
nicholassmith 14y ago
This times a thousand. When you first write the software you're basing it on expectations, no matter how well you plan, but when you rewrite it you're coming at it with real world knowledge of the pain points so of course it's going to be better in terms of performance.
- omaranto 14y ago
  "This times a thousand" would be an improvement by a factor of 10000. The improvement should definitely not be that large.
  - skeletonjelly 14y ago
    You're getting downvoted because the poster was referring to the gravity/importance of the message.
  - omaranto 14y ago
    Thanks for the explanation, skeletonjelly. I think the reason I misunderstood is that I don't hang out on the Internet enough: a friend explained to me that "This." and "this times a thousand" are Internet slang that mean "I agree" (the second, presumably means something like "On a scale from 1 to infinity my agreement level is 1000." :). As far I know these expressions aren't used verbally, which would explain why I took it literally.
    - xenophanes 14y ago
      It means repeat it a thousand times for emphasis.
  - dguaraglia 14y ago
    LOL, apparently sarcasm and witty banter is not HN forte :P
  - freditup 14y ago
    We don't all have English as our first language, and there's no problem with that. I'd have replied exactly as you did if I thought he literally meant "this times a thousand"
  - nicholassmith 14y ago
    I included an extra bit of improvement to deal with inflation rates.
ericcholis 14y ago
I'm with you on this one. I'm currently in the process of re-platforming and I'm noticing considerable gains just from revising the way certain process are done. You find a lot of "wtf was I thinking".
pdelgallego 14y ago
>> Take your first, crappy implementation and rewrite it in the same language and you'll probably still see at least 10x improvement. You will probably will get the same mess. There is plenty of literature about that. I.e: A complete rewrite is what killed Netscape
- ahupp 14y ago
  I think this taking the wrong lesson from Netscape. If you do a greenfield re-write of a multi-million line application you probably are going to have a bad time, but people successfully re-write smaller applications or portions of an application all the time. Since this was just a portion of the total functionality of LinkedIn, they incurred much less risk than a ground up rewrite would have.
- Devilboy 14y ago
  Is moving from Rails to Node not a complete rewrite?
  - pyre 14y ago
    They just wrote a Ruby interpreter for Node.js. Node.js is just that fast.
    - OriginalSyn 14y ago
      Where can I see this?
      - jrockway 14y ago
        You'll have to wait until April 1.
  - tedunangst 14y ago
    It doesn't count as a rewrite when the rewrite is in a language that's cooler than the original version.
- 14y ago
dkrich 14y ago
I disagree. When you change state management to client side, you are making a fundamental architecture shift that is significant enough to remove a lot of server-side overhead. What makes you think refactoring code is going to give you a 10x improvement in efficiency? If your code is that bad, you should get rid of the developers along with the code.
- dmorgan 14y ago
  >I disagree. When you change state management to client side, you are making a fundamental architecture shift that is significant enough to remove a lot of server-side overhead. In most cases, you're not. You're mostly making a big logic spaghetti mess on both the client and the server AND make your pages load slower, especially for the initial load (client performance, js loading times, etc). >What makes you think refactoring code is going to give you a 10x improvement in efficiency? Because even correctly implementing just the caching layer, with nested/micro-caching, can give you up to 1000x improvement in efficiency in the first place.
  - kevincennis 14y ago
    It's true that moving more logic and state management to the client side often increase page load times - but it also allows you (potentially) to make certain interactions much faster. When you have real data on the client instead of just a bunch of markup, you can be a lot smarter about how and when you make additional AJAX requests. Optimistic updates can make a huge difference in perceived performance.
- deleted 14y ago
  [deleted]
fleitz 14y ago
Yeah as the article notes the old version used HTML and the new version uses binary blobs. This is hardly surprising.
benologist 14y ago
Node has some pretty unique benefits, I save a good $1000/month from switching from .NET on dedicateds to NodeJS on a PaaS (Heroku), and that was after 2 - 3 years of writing and rewriting and optimizing the .NET stuff. Biggest improvements came from persistant connections to redis/mongodb and polling for updated information independently of requests so there was no cached-or-fetch shenanigans at all in some areas.
- statictype 14y ago
  What were the benefits you saw in switching from .NET to Node? Was it in basic code structure/complexity or performance? I'd actually be very surprised if NodeJS running on Heroku (which is built on EC2) performs better than compiled .NET code running on dedicated Windows hardware.
  - benologist 14y ago
    The major benefits were persistant connections and background fetching of data - a lot of my requests serve data directly from local memory instead of hitting local or shared caches and databases. The equivalent in .NET I guess would be BackgroundWorkers that are independently prefetching the data required most of the time but I could never get them to Just Work. Specifically for my use case 99+ percent of requests receive some data, do some light manipulations and then push the data to redis about 8,000 to 12,000 times a second. With .NET I could only push to locally running software instances because anything remote couldn't keep up with the connection volume (without throwing even more hardware at the problem).
    - statictype 14y ago
      Interesting. Thanks for the answer. I'm a little surprised that .NET can't juggle network connections very well but in retrospect, I probably shouldn't be.
      - benologist 14y ago
        I think it's just whatever .NET's doing to pool them that has some tiny bit of overhead that doesn't matter most of the time.
throwa 14y ago
This article actually gives details of their first implementation which suggest that they could cut servers without switching to node : http://ikaisays.com/2012/10/04/clearing-up-some-things-about-linkedin-mobiles-move-from-rails-to-node-js/ http://ikaisays.com/2012/10/04/clearing-up-some-things-about...

lumberjack 14y ago

To be fair, Node.js isn't exactly harder to work with than Django or Rails. I myself had to choose between these about a year ago and despite the asynchronous paradigm I still found it relatively easy to start using in comparison to Rails and Django.

astrodust 14y ago
Node.js is extremely hard to work with compared to Rails and moderately hard to work with compared to Django. The Node.js ecosystem has a lot of potential, but the variety of off-the-shelf add-ons is severely limited compared to either of those more mature frameworks. If you think Node.js is easy, you've never really experimented enough to understand what makes Rails so effortless. It's a lot easier to produce a production-ready application with Rails than it is with Node.js as it is today. In four years, as Rails starts to add less critical features, Node.js may well have caught up.
- erichocean 14y ago
  Node.js is extremely hard to work with compared to Rails and moderately hard to work with compared to Django. Pro tip: Don't put this on your resume.
  - mansoor-s 14y ago
    made me chuckle
  - andybak 14y ago
    Meaning?
  - astrodust 14y ago
    Coming from Rails, Node is like opening a toolbox and finding it has a screwdriver, a wrench, and a hammer. Somehow you're expected to build things with that. For those that love to build things from the ground up or to carve out new solutions, Node is a great place to be. I think it's got enormous potential and is biggest opportunity since Python and Ruby took off around years ago. Just don't think because you can create the same sorts of apps with Node that it's as easy. Ruby on Rails even three years ago was laughable compared to today's toolset. Node is catching up quickly, covering ground faster than Ruby ever did, but still lagging.

jonpaul 14y ago

Why not write your code using Node.js because you actually enjoy using JavaScript? Or how about the convenience of writing in one language in your stack? Or how about the simplicity provided by not having to worry about threading per process? If you already know Python or Ruby, then ya, using Node.js would be silly. But if you have to pick one because you're equally familiar with all of the languages, then Node.js isn't a bad choice at all.

SoftwareMaven 14y ago
You'll note I explicitly said there are reasons to choose it. And if you choose it for those reasons, great. Just don't choose it because it will solve your Mazzerati problem. Choose it for your problems today.
andersbreivik 14y ago
" because you actually enjoy using JavaScript? " You sick bastard!

todd3834 14y ago

After reading the article, the fact that they cut servers was just one of the advantages they got from using node.js

kin 14y ago

What I saw as a plus was that they combined front/back end teams into a single unit.

jeremyjh 14y ago
Am I the only person who doesn't believe this story? Because really, the whole reason we have front-end/back-end specialists is because front-end javascript ninjas can't learn RUBY??!?
- kin 14y ago
  It's believable to me. The whole reason we have front-end/back-end specialist isn't because front-end js people can't learn Ruby but rather it's the same reason why front-end/back-end is separated code-wise. Depending on how they're using node they could very well keep this segregation. But some implementations with node have server/client sharing code. I know I've seen examples of this. I imagine that's how they're doing things.
  - ikailan 14y ago
    I don't think it's about the language - it's about knowledge. A backend specialist can learn Javascript but may not know the nuances of working with the DOM, or optimizing for pagespeed, or the important front end libraries. Similarly, a front-end specialist may not have all the experience necessary to diagnose problems in a deployment. That's one reason I don't buy the "front end developers can now do backend development because of node.js" argument. Any sufficient competent backend developer can start writing Python code in a day. What that developer doesn't get in a day is understanding deployments, popular Python libraries, the ecosystem, etc.
    - jeremyjh 14y ago
      Exactly.
    - kin 14y ago
      I'm not saying they've removed specialists. I believe they still exist. But in switching to node, because client/server shares a language, they're now capable of sharing code as well. Which is what I imagine they are doing, which is why it's logical that they've merged teams. This doesn't rule out that front/back-end specialists are removed and become well-rounded rather, they're just working together more.

markmm 14y ago

I would spend a little extra time upfront and save many many expensive rewrites latter on. Use C from the start, you won't need to rewrite just scale with hardware. This argument that using Ruby (or any language that makes programming easy but runs like treacle) to get something out the door a few months earlier is bullshit, I would rather release something a few months later that I didn't have to totally rewrite down the line 10 times.

jonny_eh 14y ago
But the odds of the thing you release actually getting used are low. So make it fast, and if it's a hit, then deal with that.
- markmm 14y ago
  Wow!! your comment encapsulates the thinking of every wannabe startup loser that ends up smoking crack on some beach in San Francisco" Will making it faster increase the chances of more people using it? Also this attitude of building shit products (Yes software is a product) because..well the chances are it will fail.. is precisely why so many startups fail. This is why you get one crapola startup after another........ "Show HN: Crap.ly -- we built this in 3 weeks using Ruby, it will scale up to 20 users before craping out, its a twitter scraper that connects to app.net and diaspora showing how much Money your Kick-starter project has made and includes quotes from Paul Graham about how to build a successful startup, because he has built so many" Imagine Linus had built Linux using fucking node.js
  - bgilroy26 14y ago
    You're not yourself when you're hungry.
  - drstewart 14y ago
    Imagine your shock when you build your craptastic app in C++ and wonder why it's not any faster than a scripted app. I'll give you a hint ahead of time: most bottlenecks aren't processing time, they're DB or IO limited.