Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We switched to Node.js: the good and the not so good

blog.superfeedr.com

Post reply on HN
Print view View original

11–20 of 106 posts

Re: We switched to Node.js: the good and the not so good

#11

Post by superbobry »

blacktulip wrote: post #9
nicholassmith wrote: post #7

I 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?)

[1] can give you some insight on the dark side of JS. Also, avoiding JS in some way or another is not that hard, esp. since there're a lot of languages which compile to JS, most notably CoffeeScript and ClojureScript.

  * [1] http://wtfjs.com 
  * [2] https://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS

Re: We switched to Node.js: the good and the not so good

#12

Post by julien »

DoubleCluster wrote: post #10
julien wrote: post #4

Earlier quoted context omitted.

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…

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

Re: We switched to Node.js: the good and the not so good

#14

Post by octo_t »

julien wrote: post #12
DoubleCluster wrote: post #10

Earlier quoted context omitted.

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…

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?

Re: We switched to Node.js: the good and the not so good

#15

Post by julien »

octo_t wrote: post #14
julien wrote: post #12

Earlier quoted context omitted.

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.

Re: We switched to Node.js: the good and the not so good

#16

Post by dagw »

blacktulip wrote: post #9
nicholassmith wrote: post #7

I 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?)

Instead of worrying about how bad JS is, read JavaScript the Good Parts and Effective JavaScript and focus on how good much of it is. Yes, JavaScript has oddities and there is a quite short list of pitfalls you have to learn to avoid ('==' vs '===' for example), but it also has some very powerful features. Take the time to actually learn actual JavaScript, as opposed to assuming that it's basically a bad Java (or whatever) with slightly different syntax and you'll find a pretty neat and powerful language.

Re: We switched to Node.js: the good and the not so good

#17

Post by davidw »

> What we liked the most of Javascript was the fact that it’s an asynchronous language ‘by default’.

That's not strictly true - a "while (true)" will lock up a Node process as far as I can tell. I think a more accurate way of stating it would be that "Javascript API's and libraries tend to be written with asynchronous use in mind", with lots of callbacks.

If you want something that's async at a deeper level, Erlang is worth a look.

Re: We switched to Node.js: the good and the not so good

#18

Post by dagw »

superbobry wrote: post #11
blacktulip wrote: post #9

Earlier quoted context omitted.

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

[1] can give you some insight on the dark side of JS. Also, avoiding JS in some way or another is not that hard, esp. since there're a lot of languages which compile to JS, most notably CoffeeScript and ClojureScript. * [1] http://wtfjs.com * [2] https://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS

As much as I love CoffeeScript, it's not a substitution for learning JavaScript. CoffeeScript is basically just JavaScript with a prettier syntax and if you don't understand JavaScript you won't understand CoffeeScript.

Re: We switched to Node.js: the good and the not so good

#19

Post by PommeDeTerre »

dnu wrote: post #8
DoubleCluster wrote: post #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 (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.

If ease of long-term maintenance is a goal, then JavaScript is the wrong approach.

Re: We switched to Node.js: the good and the not so good

#20

Post by viraptor »

DoubleCluster wrote: post #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 (t…

I'd look at it from another side. They took a working project which they knew well and transferred it completely to a different platform. The first "complete" version of the rewrite had 25% more throughput.

In that case it's a pretty good achievement, since the rewrite will have a lot more low-hanging fruit regarding performance improvements, than a polished, existing product. I'm used to see rewrites which are at least a little bit worse than previous versions due to all the work done to squeeze everything out of version N-1.

Post reply on HN