Re:LinkedIn Mobile Moved from Rails to Node: 27 Servers Cut ...
by dkrich on Thursday October 04, 2012 @05:29PM
(#4614497)
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.
[ Parent
| on HN ]
Re:LinkedIn Mobile Moved from Rails to Node: 27 Servers Cut ...
by dmorgan on Thursday October 04, 2012 @05:36PM
(#4614529)
>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 ...
by kevincennis on Thursday October 04, 2012 @09:42PM
(#4615313)
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.