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

81–90 of 106 posts

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

#81

Post by sandGorgon »

jondot wrote: post #55

I am using a mix of Ruby, Node and Java in production but after some hard-learned lessons chose to minimize the Node usage to things I absolutely need. My experience with the Node community: - Great people (Substack!) - Great attitude #node.js/freenode - However, many hours spent on solving bugs in existing libraries. My experience with maintaining production Node code: - It may be more maintainable than EventMachine…

could you detail how you are using jruby to offset evented systems on node.js ?

If you are using scala, which async framework are you using - I have heard it is basically scalatra vs spray.io

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

#82

Post by CoffeeDregs »

I like JS and I like NodeJS, but I'm more of an integrator-coder and prefer frameworks, so I miss things like Django, South, mature ORMs, etc. Though I did somewhat overcome this hurdle, I particularly hurt for a migration library when building a NodeJS project (we did find a decent one, but it was young, immature and not well documented, so it took 10x the time to get comfortable working with it and then it lacked lots of features). I also missed the availability of batteries-included API libraries such as Tasty-Pie and Django-Rest-Framework. Again, it's not hard to code up a few URLs for a model, but then ... HATEOS ... default REST stuff ... JSONP support ... etc.

I do look forward to switching to NodeJS and I am fairly early adopter... but it's still been too early for me.

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

#83

Post by jondot »

continuations wrote: post #69
jondot wrote: post #67

Earlier quoted context omitted.

I used the examples from the original article. I think the OP ported an EventMachine code to Node. When I said 'Java' I really meant JVM. Specifically I'm using Scala. Regardless, I have a different Clojure based project, with it as well, I prefer doing what clojure has to offer in terms of concurrency (pmap, etc). I have dipped a toe in Go. Loved the fact that you get a compiled binary, ecosystem still feels skinny.…

If you're already using Scala, why do you need Node? What does Node give you that a Scala async framework like Play or Scalatra doesn't? Also what does Ruby give you that Scala doesn't? Just wondering why do you choose to use 3 stacks (Ruby, Scala, Node) when one could be enough.

I'll also try to address sandGordon's question.

Like superfeeder, I have "backend" services, but I also have client-facing services.

I value how Node.js handles slow clients. It also services some more 'utility' use cases for me, such as reverse proxies, etc.

JRuby and Scala cover IO bound processing for me over the Web.

JRuby covers the majority of the backend services.

I use Scala coupled with Storm, and I could have used JRuby here too, but you can also use JRuby with Hadoop and you typically don't. Since this use case actually required the optimization (I wasn't prematurely optimizing), I went as bare metal as possible (ruled Java out, yes). Previously, this service was a Node.js service and got rewritten into Scala+Storm.

I don't use Akka because I didn't feel it was needed yet. Old school threaded workers with JRuby works fine so far.

I know that Scala is supposed to be a multi-layered solution and it can handle all of this.

However, Ruby and Node brings the ecosystem Scala doesn't have (I'm not moved by the "but Java has a million Jars out there" argument, already integrating with them with JRuby).

And in general Ruby makes me happy (SBT makes me very very angry and sad, for comparison - yet Scala is OK), that simple.

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

#84

Post by jondot »

sandGorgon wrote: post #81
jondot wrote: post #55

I am using a mix of Ruby, Node and Java in production but after some hard-learned lessons chose to minimize the Node usage to things I absolutely need. My experience with the Node community: - Great people (Substack!) - Great attitude #node.js/freenode - However, many hours spent on solving bugs in existing libraries. My experience with maintaining production Node code: - It may be more maintainable than EventMachine…

could you detail how you are using jruby to offset evented systems on node.js ? If you are using scala, which async framework are you using - I have heard it is basically scalatra vs spray.io

>could you detail how you are using jruby to offset evented systems on node.js ?

Simply because JRuby has real threads over MRI's GIL, and the JVM has a time-proven Server VM that has a very good JIT. I also leave open the option to drop to 'bare' Java. As the OP mentioned, it's a craft of balancing CPU and memory. In my case I don't mind the extra threads memory and context switching overhead.

> If you are using scala, which async framework are you using - I have heard it is basically scalatra vs spray.io

My Scala use case is with Storm, as mentioned in other reply. You can call that "backend" processing, instead of using it with a Web framework.

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

#85

Post by mason55 »

brown9-2 wrote: post #74
davidw wrote: post #17

> 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 i…

Beyond this, is there any part of the JavaScript language itself that is inherently asynchronous or enables the writing of asynchronous code? I believe the answer is no - the async nature is provided by V8 and the core Node libraries.

I disagree. Try writing fully async Java - it's much, much harder without functions as first-class objects and true closures.

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

#86

Post by pindi »

archangel_one wrote: post #80
brown9-2 wrote: post #74

Earlier quoted context omitted.

Beyond this, is there any part of the JavaScript language itself that is inherently asynchronous or enables the writing of asynchronous code? I believe the answer is no - the async nature is provided by V8 and the core Node libraries.

I would say yes, it's very easy to write inline anonymous functions which are very very nice for a primarily callback-driven model. I much prefer Python as a language overall, but I think writing code for "Node.py" would be an awful lot harder.

"Node.py" is Twisted [1] and/or Tornado [2]. And you're definitely correct.

[1] http://twistedmatrix.com/trac/

[2] http://www.tornadoweb.org/

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

#87

Post by chrismsnz »

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

Pick up "Javascript: The good parts" by Douglas Crockford and don't look back.

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

#88

Post by xyzzy123 »

pindi wrote: post #86
archangel_one wrote: post #80

Earlier quoted context omitted.

I would say yes, it's very easy to write inline anonymous functions which are very very nice for a primarily callback-driven model. I much prefer Python as a language overall, but I think writing code for "Node.py" would be an awful lot harder.

"Node.py" is Twisted [1] and/or Tornado [2]. And you're definitely correct. [1] http://twistedmatrix.com/trac/ [2] http://www.tornadoweb.org/

Agree, Python doesn't feel as natural for callback-style. I do like the gevent (http://www.gevent.org/) or greenlet style code though.

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

#89

Post by cmccabe »

antihero wrote: post #52

Say I'm a Python developer and I'm looking to write services that are fast. Would I likely be better off going down the route of node.js, Go, Haskell, Erlang? I mean they are all fantastic languages and I've dabbled in most of them but from what I've read, Go seems to be the best one to use if you don't want to shake your world up, but if you do, Haskell or Erlang are nice new paradigms to dive into. Is this true?

Go for go.

Go is actually fast, not just fast in theory or fast when speed isn't important, or whatever other weasel words you care to choose. Goroutines and channels give you the scalability advantages of async programming, without leaving behind readable code. Deployment is super simple because it produces a compiled binary.

Go has a solid foundation, including things like real support for integers, real support for threads, a runtime that was really developed for servers, and a well-thought-out type system. Some people have compared it to static duck typiing.

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

#90

Post by codygman »

nkohari wrote: post #60
gbog wrote: post #32

Earlier quoted context omitted.

You have better ways to ask for explanations. Not the OP but I can give some reasons for Javascript and Node.js to not be the best option for a rewrite if the goal is longterm maintainability: - js / node.js is very young, it might fade out of fashion, and in 10 years it is not impossible that good coders in js will be hard to find. - Readability and simplicity are prominent in this context, and js has a syntax that…

Technology and business requirements move too fast to worry about writing software that will be around 10 years from now. Choosing the best technology for your particular use case, that will also allow your software to evolve over time, is much more important than trying to predict the future. Also, I've gotta say, you completely undermined all 3 points of your argument by saying you'd choose Go.

I don't think he undermined the second, but would like to know your opinion. Here is mine:

"- Readability and simplicity are prominent in this context, and js has a syntax that is less than optimal in this regard."

Go code is almost always very simple and readable. What makes you think him choosing Go undermines the simplicity and readability arguments?

Post reply on HN