Hacker News Reader

Comment by julien | Hacker News Reader

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 =)

View on HN

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.

Well, we assumed everyone knew about the good... so yes, we're happy with the rewrite and will probably never go back. Also, a 25% saving in servers for us translate in several thousands of dollars saved monthly. Not negligible :)

How much development time did this cost though, when you could have been adding new features and improving the user experience?

Hard to assess exactly, but we were not adding feature and improving the user experience mostly because maintaining the previous code base and evolving it was so costly.

Yeah but in your article you said you're not even sure if this is because of node. You made some architectural changes in your code base and hinted that might have been a reason for the speed boost too.

The article might as well be written as "we refactored our code and got a nice speed boost".

from a long term maintainability perspective, javascript can be notorious. you could always follow a disciplined approach for development to help with maintainability, but that applies to all programming languages. i don't see anything about javascript that makes it more maintainable especially for large projects.

It's not the language, it's the people, the community.

what's different about node community from ruby community? are you sure that's not confirmation bias?

Well, again, most of the dependencies we used in Ruby did not see any update in the 3 years we've been using them. We also reported several bugs in those libraries/dependencies which were never fixed. This led us overtime to use our own branch of all the significant dependencies we had (including the MySQL gem for EM, the redis gem... and several other key ones).

Most of node modules are still in active development. As I've stated in the blog post, that's a pro and con, but we estimated that the pro was greater than the con :)

What leads you to believe all of these node modules that you now have dependencies on will still be in active development in 3 years?

They might not be, but that doesn't matter as much as being able to report bugs and have them fixed now, while people are still actually developing/fixing things.

TypeScript makes it way more maintainable.

What was the reason you choose to rewrite for ease the maintenance in node?

Couldn't you rewrite for ease the maintenance in ruby?

Reply on news.ycombinator.com