We switched to Node.js: the good and the not so good
blog.superfeedr.com
We switched to Node.js: the good and the not so good
1–10 of 106 posts
Re: We switched to Node.js: the good and the not so good
#2> It terms of performance, we also have seen a significant (about 25%) bump in terms of feeds processed by second per server.
They rewrote the entire codebase and obtained for just a 25% gain? It doesn't sound like they are very happy to be coding in javascript now either.
Everyone: please don't rewrite your code, it's almost never worth it. The one exception is rewriting a core part of an algorithm in C for speed (the last 10x speedup).
Re: We switched to Node.js: the good and the not so good
#3> It terms of performance, we also have seen a significant (about 25%) bump in terms of feeds processed by second per server. They rewrote the entire codebase and obtained for just a 25% gain? It doesn't sound like they are very happy to be coding in javascript now either. Everyone: please don't rewrite your code, it's almost never worth it. The one exception is rewriting a core part of an algorithm in C for speed (t…
There are other reasons for rewriting like getting to a more easily maintainable code or when a previous solution has simply outlived it's usefulness.
Also, C is not the only language worth rewriting in.
Re: We switched to Node.js: the good and the not so good
#4> It terms of performance, we also have seen a significant (about 25%) bump in terms of feeds processed by second per server. They rewrote the entire codebase and obtained for just a 25% gain? It doesn't sound like they are very happy to be coding in javascript now either. Everyone: please don't rewrite your code, it's almost never worth it. The one exception is rewriting a core part of an algorithm in C for speed (t…
Well, the reason we rewrote was not to explode all benchmarks. The reason we rewrote was to be able to ease the maintenance of our code =)
Re: We switched to Node.js: the good and the not so good
#5> It terms of performance, we also have seen a significant (about 25%) bump in terms of feeds processed by second per server. They rewrote the entire codebase and obtained for just a 25% gain? It doesn't sound like they are very happy to be coding in javascript now either. Everyone: please don't rewrite your code, it's almost never worth it. The one exception is rewriting a core part of an algorithm in C for speed (t…
They did not say anywhere that the 25% speed gain was the reason they did it...
Re: We switched to Node.js: the good and the not so good
#6> It terms of performance, we also have seen a significant (about 25%) bump in terms of feeds processed by second per server. They rewrote the entire codebase and obtained for just a 25% gain? It doesn't sound like they are very happy to be coding in javascript now either. Everyone: please don't rewrite your code, it's almost never worth it. The one exception is rewriting a core part of an algorithm in C for speed (t…
I kind of agree that 25% gain doen't justify codebase rewrite, let along language/framework switching. Perhaps they are doing this with future traffic peak in mind. Premature optimisation, I know. Probably they've already cleared up other important items on their todo list.
What interested me most is the community part. I've always thought ruby/rails community is awesome. Maybe I should start learning some JavaScript now.
Re: We switched to Node.js: the good and the not so good
#7I tried Node, because it was the new hotness and trying new things is great. It was distinctly Not For Me, for many of the same reasons that they've found; many tutorials are out of date in subtle ways (I like to think of this as the Rails effect from way back in the good old fun days), the language is just painful to structure and read over for my syntax processing.
There's definitely a lot to like, and like they said it's still a very new world with a lot of exploration to be done.
Re: We switched to Node.js: the good and the not so good
#8> It terms of performance, we also have seen a significant (about 25%) bump in terms of feeds processed by second per server. They rewrote the entire codebase and obtained for just a 25% gain? It doesn't sound like they are very happy to be coding in javascript now either. Everyone: please don't rewrite your code, it's almost never worth it. The one exception is rewriting a core part of an algorithm in C for speed (t…
It depends on how large the code base is. Rewriting a 10k LOC project isn't a big deal, compared to a 10 mln one. And a rewrite doesn't have to target performance only, but ease of maintenance too.
Re: We switched to Node.js: the good and the not so good
#9I tried Node, because it was the new hotness and trying new things is great. It was distinctly Not For Me, for many of the same reasons that they've found; many tutorials are out of date in subtle ways (I like to think of this as the Rails effect from way back in the good old fun days), the language is just painful to structure and read over for my syntax processing. There's definitely a lot to like, and like they sa…
I have not tried Node (or in fact JS as a whole) yet. But it seems very hard to avoid JS in these days. I am going to learn it in a few months. Can anyone give me a rough idea how bad it is? (I know some Obj-C so is JS worse than that?)
Re: We switched to Node.js: the good and the not so good
#10> It terms of performance, we also have seen a significant (about 25%) bump in terms of feeds processed by second per server. They rewrote the entire codebase and obtained for just a 25% gain? It doesn't sound like they are very happy to be coding in javascript now either. Everyone: please don't rewrite your code, it's almost never worth it. The one exception is rewriting a core part of an algorithm in C for speed (t…
Well, the reason we rewrote was not to explode all benchmarks. The reason we rewrote was to be able to ease the maintenance of our code =)
That's fine. Did the code become easier to maintain? It's not clear from the article. The "The good" section is relatively weak and the "The not-so-good" has some painful points about memory management and api instability.
It sounds a bit like you guys rewrote it because node.js is hot and you then stuck with the rewrite because of sunk costs. Or am I imagining things?
Thanks for sharing your experiences with us. I'm just asking those questions because I want to learn more about them.