Live data from Hacker News

Why we moved from NodeJS to Ruby on Rails

blog.targeterapp.com

81–90 of 166 posts

Re: Why we moved from NodeJS to Ruby on Rails

#81

Earlier quoted context omitted.

Mongodb is a json document store. I use it myself. It works very well with "node" because node of course uses javascript as its language.

But wouldn't it work as equally well with any other language that has a JSON library? With Node you still need to call a function to serialize an object to a JSON string or vice versa.

Not any other language. In JavaScript there is 1 function call to serialize and 1 function call to deserialize. In Java it's much more complicated, for example.

Re: Why we moved from NodeJS to Ruby on Rails

#82
post #59

Earlier quoted context omitted.

I disagree with this. By the ecosystem being huge do you mean the modules and different gems? That in itself is modularized for having the choice not to use them. The availability is what makes it powerful on top of the simplicity to get it all running. Node is by far not simple for a new developer or new teams running node. Projects tend to drift toward unreadable due to poor design, just try following people's call…

Im sorry but you make it sound like everybody that does rails is a perfect programmer. Rails itself has changed over the years and if you look at an app from years ago im quite sure it will be very different then a current rails app. So again this is just not an appropriate comparison.

I don't think they are perfect programmers. Heck, I use several languages and frameworks, whatever is right for the project. Knowing a language isn't a perfect programmer (we all know that). And to your point, that was the comparison I would make. Node is young so there is a lack of experience with it.

Re: Why we moved from NodeJS to Ruby on Rails

#83

Earlier quoted context omitted.

But wouldn't it work as equally well with any other language that has a JSON library? With Node you still need to call a function to serialize an object to a JSON string or vice versa.

Not any other language. In JavaScript there is 1 function call to serialize and 1 function call to deserialize. In Java it's much more complicated, for example.

Well in Java, if your JSON library doesn't have a single function to call for deserialize or serialize, it's either a poor library or you should be able to wrap the complicated part in a function that makes it a one-liner. The Jackson library for instance has ObjectMapper.readValue() and ObjectMapper.writeValue() which are both one-liners.

My main point though is that writing in JavaScript doesn't naturally make it easier to work with JSON than any other language with similar functions to serialize/deserialize JSON.

Re: Why we moved from NodeJS to Ruby on Rails

#84
Anyone else find it ironic that this post is about moving from Node to Ruby in order to produce the admin interface to a Java hosting service? (This was a blog post written by "Jelastic" devs, who make a Java PaaS product).

We seem to be seeing more of this "don't eat your own dogfood" approach to software development lately. The other example that comes to mind is the Play Framework, written in Python and also targeted to Java devs.

Re: Why we moved from NodeJS to Ruby on Rails

#85

Earlier quoted context omitted.

Not any other language. In JavaScript there is 1 function call to serialize and 1 function call to deserialize. In Java it's much more complicated, for example.

Well in Java, if your JSON library doesn't have a single function to call for deserialize or serialize, it's either a poor library or you should be able to wrap the complicated part in a function that makes it a one-liner. The Jackson library for instance has ObjectMapper.readValue() and ObjectMapper.writeValue() which are both one-liners. My main point though is that writing in JavaScript doesn't naturally make it e…

I'm not a Java coder so I'll take your word on it about library support, I've only used the JSONObject, JSONArray, etc. classes. Surely you will concede that JSON being modeled after JavaScript gives the language a little bit of a leg up?

Re: Why we moved from NodeJS to Ruby on Rails

#86
post #16
post #8

Earlier quoted context omitted.

That sounds like a complicated approach at it. Here's an example of some NodeUnit tests that involve communications with a Redis-based message queue: https://github.com/bergie/noflo/blob/master/test/MQ_SendMess... More BDD-ish version of something similar: https://github.com/nemein/kckupmq/blob/master/test/001_kckup...

Does that test you link actually talk to a live Redis-based message queue that must exist for the test to run? If so, while that's a nice test there's also a need to be able to fully control the event loop so you can test arbitrary event orders, some of which you may not be able to synthesize (or not easily, or not reliably) but may be able to occur in the real world. Testing event loop code sucks hard enough when yo…

>there's also a need to be able to fully control the event loop so you can test arbitrary event orders

Hmm, something doesn't sound right there. I'm not really sure why you'd want to "fully control the event loop" for testing, but if you did you can install a callback on every tick: http://nodejs.org/api/process.html#process_process_nexttick_...

If you want to test arbitrary inbound event sequences, you'll need to run at least two processes. You could run two node processes, one generating events for the other. This would probably give you a better test environment then hacking the event loop, too.

Re: Why we moved from NodeJS to Ruby on Rails

#88

Since our stack involved MongoDB, it only made sense to live in a JS only environment. I've never used MongoDB; can someone explain to me why this would seem like an advantage, and/or what it has to do with MongoDB? Is the MongoDB API simply JavaScript?

MongoDB has good drivers for Node (as for most other languages) but also a fully-featured ORM that can save time in these kind of projects: mongoosejs.com

MongoDB also ships with a JS runtime so you can run map/reduce calls written in JavaScript entirely DB-side, as well as other goodies.

So it's fair to say that the language that makes the most sense when using MongoDB is JavaScript, even if that wouldn't be enough IMHO to justify using Node for a project.

Re: Why we moved from NodeJS to Ruby on Rails

#89
I'd be curious which things were missing in Node. I realise gratuitous detail doesn't make for a great blog post but if Node.js is missing things that stopped development of an app it would be useful for the Node community to know what they are.

Mentioning "immature packages" and "testing" is fine, but I'd really like to know what makes testing on RoR better than, say, testing with Mocha.

I'd also be really interested in the experiences of trying to cache with Node. I think while it's possible to do it's definitely a place that could be improved.

Re: Why we moved from NodeJS to Ruby on Rails

#90
post #20

Earlier quoted context omitted.

Justin.tv frontend is rails, though they may / may not be moving to Django according to Kyle. http://news.ycombinator.com/item?id=3461476

Of course Rails took YEARS getting to the point of scalability. People are acting like it was scalable on the very first alpha release.

But will JavaScript be able to scale? It has come a long way from the days of onMouseOver but it seems like it's going to be hard unless it gets turned into a different language (i.e. Dart).
Post reply on HN