I hate Rails. Node is the way to go. Node > Python > Rails
Having an opinion is fine, but you need to support it with an explanation and/or data.
LinkedIn Mobile Moved from Rails to Node: 27 Servers Cut and Up to 20x Faster
41–50 of 140 posts
Re: LinkedIn Mobile Moved from Rails to Node: 27 Servers Cut and Up to 20x Faster
#42Ah, odd math point, but was I the only one who noticed this sentence:
"focus on simplicity, ease of use, and reliability; using a room metaphor; 30% native, 80% HTML; embedded lightweight HTTP server; "
Re: LinkedIn Mobile Moved from Rails to Node: 27 Servers Cut and Up to 20x Faster
#43If 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 earl…
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.
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.
Re: LinkedIn Mobile Moved from Rails to Node: 27 Servers Cut and Up to 20x Faster
#44If 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 earl…
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 dow…
This would only make sense if you're working for an established company that can burn a few extra months early on. For a startup the runway might be too short. In this case you have no idea if your product is even going to exist a year later so it seems a bit premature to be worrying about the possibility of rewrites.
Re: LinkedIn Mobile Moved from Rails to Node: 27 Servers Cut and Up to 20x Faster
#45I hate Rails. Node is the way to go. Node > Python > Rails
[deleted]
Re: LinkedIn Mobile Moved from Rails to Node: 27 Servers Cut and Up to 20x Faster
#46Earlier quoted context omitted.
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 dow…
This would only make sense if you're working for an established company that can burn a few extra months early on. For a startup the runway might be too short. In this case you have no idea if your product is even going to exist a year later so it seems a bit premature to be worrying about the possibility of rewrites.
My experience is a software always takes much longer than expected, if your startup will fail if you run a few months over then you may as well go and place all your money on black at the casino. You need to get into a position were you can run 1 year over and still survive i.e. have other income while working on your startup.
Re: LinkedIn Mobile Moved from Rails to Node: 27 Servers Cut and Up to 20x Faster
#47Earlier quoted context omitted.
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.
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.
>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.
Re: LinkedIn Mobile Moved from Rails to Node: 27 Servers Cut and Up to 20x Faster
#48Earlier quoted context omitted.
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.
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 prod…
I used to think this until I built an app with node... every time I got to a point where I wanted a library or framework, a mature, well-supported one existed. Yes I had a bit of a learning curve since it was my first node app, but I was shocked at how smoothly it went and this was over a year ago.
Re: LinkedIn Mobile Moved from Rails to Node: 27 Servers Cut and Up to 20x Faster
#49Earlier quoted context omitted.
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 prod…
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.
made me chuckle
Re: LinkedIn Mobile Moved from Rails to Node: 27 Servers Cut and Up to 20x Faster
#50If 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 earl…
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 dow…
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.