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.
Why we moved from NodeJS to Ruby on Rails
81–90 of 166 posts
Re: Why we moved from NodeJS to Ruby on Rails
#82Earlier 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.
Re: Why we moved from NodeJS to Ruby on Rails
#83Earlier 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.
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
#84We 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
#85Earlier 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…
Re: Why we moved from NodeJS to Ruby on Rails
#86Earlier 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…
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
#87Re: Why we moved from NodeJS to Ruby on Rails
#88Since 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 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
#89Mentioning "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
#90Earlier 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.