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

Why we moved from NodeJS to Ruby on Rails

blog.targeterapp.com

Post reply on HN
Print view View original

141–150 of 166 posts

Re: Why we moved from NodeJS to Ruby on Rails

#141

Post by nakkiel »

justanotherbody wrote: post #78
Spyro7 wrote: post #49

I really do think that, as time wears on, we will see more of these incidents of people switching from Node to another, more familiar development environment. It seems to me that a lot of people started using Node simply because of the amount of hype that surrounded it, and many of these decisions were not as well researched as they should've been. Reading through this gentleman's blog post, it seems that, originally…

It seems to me a lot of this starts with "I have a general idea, and I want to get it off the ground ASAP" and transitions to "I have a focused idea, and can now revise the project accordingly" I see nothing wrong with that, as long as everyone involved recognizes the cost of rewriting/replacing large chunks later. If you're on a super tight schedule and don't want to write anything but JS, and you can afford to make…

I think you nailed it. Different solution are valid at different times.

Also in many cases, a website rewrite is really nothing complicated.

Re: Why we moved from NodeJS to Ruby on Rails

#142

Post by bad_user »

kylebrown wrote: post #129
bad_user wrote: post #104

Earlier quoted context omitted.

Only rookies do that inside the web server process. The job of fetching a Twitter feed can be offloaded to a background jobs queue. With a little help from Nginx, you can free the Ruby process to take care of other requests until the response of that Twitter feed is ready. Or you could simply deploy your Rails app on top of a Java server, by means of JRuby and forward that request to a servlet that uses the continuat…

Or you could just use node.

If all your app ever does is to fetch Twitter feeds, sure.

Re: Why we moved from NodeJS to Ruby on Rails

#143

Post by reissbaker »

bad_user wrote: post #104
benatkin wrote: post #91

Earlier quoted context omitted.

OP explained things improperly, then. It's an important detail, because Rails currently defaults to single-threaded. This makes an operation such as fetching and returning a twitter feed in a single request (assuming it takes hundreds of milliseconds to get a response from twitter's servers) expensive.

Only rookies do that inside the web server process. The job of fetching a Twitter feed can be offloaded to a background jobs queue. With a little help from Nginx, you can free the Ruby process to take care of other requests until the response of that Twitter feed is ready. Or you could simply deploy your Rails app on top of a Java server, by means of JRuby and forward that request to a servlet that uses the continuat…

   Rails does work with multi-threading.
Ruby has no support for concurrency, no matter how many threads your interpreter is using. 1.8 had no OS threads at all, and 1.9 has a global interpreter lock. This is not solvable in the application layer (for example, by a framework like Rails): this is a problem inherent to the runtime.

Re: Why we moved from NodeJS to Ruby on Rails

#144

Post by edwardtrunk »

i think what i'm enjoying most about node.js and the new frameworks, is that they require me to think differently. i'm also optimistic about coding end-to-end in the same language (client, server, database). this is a big learning curve for many folks. i remember when folks transitioned from C to C++ and from C++ to Java -- it takes awhile. i think this is going to be a lot of fun to see where it takes us. also i think work like coffeescript and future IDEs might make this really interesting. Also meteor -- lots of creativity and cool things.

Re: Why we moved from NodeJS to Ruby on Rails

#145

Post by jerf »

javajosh wrote: post #86
jerf wrote: post #16

Earlier quoted context omitted.

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

"I'm not really sure why you'd want to "fully control the event loop" for testing,"

Because while I'm actually one of the first to tell you that not everything needs to be a unit test and I tend to prefer integration tests over unit tests if given a choice, I will also say that unit tests still have their place, and the way you unit test an event-driven program is to feed the events you specify to an event loop and ensure that the proper actions taken, using whatever is necessary to ensure proper independence.

It's nice to be able to do integration tests, it is not nice to have to do integration tests.

You know, this may explain a great deal of the gap between my opinion of event-based programming and the conventional Node opinion. Testing event-based code isn't necessarily that hard (testing is never really easy in a language where you're always in the local IO monad equivalent, though cracking it up into events does make things challenging, especially if you try to take advantage of closures in your handlers, which unfortunately is advantageous in other ways but hurts testability hard) but it doesn't help that the frameworks never seem to ship with the testing support I just specified and I'm always having to bash it together myself, which tends to show a certain... disconnect in expectations between me and the authors.

Re: Why we moved from NodeJS to Ruby on Rails

#146

Post by jroseattle »

prospero wrote: post #137
jroseattle wrote: post #133

I read this post as "your mileage may vary", gravitating toward "it doesn't work like we expected". One particular line caught my eye: "NodeJS’ async everything wont have any affect on a CRUD app. Popular frameworks, provide very good caching and everything that is needed for your app to work fine even synchronously." There is a lot to this statement that implies how an application is architected. Node.js is async at…

I think the point wasn't that "asynchronous is hard", it's that "asynchronous is just incidental complexity". CRUD apps don't need to be asynchronous, and node.js has a relatively impoverished ecosystem for such apps. There are undoubtedly tradeoffs no matter what you use, but this seems like an eminently practical decision.

I'm not so sure about that (the async-is-hard part.) If one is making a decision of architecture change due in part to CRUD capacities within a framework, I'd guess the asynchronous programming model in Node.js is a little more than just incidental complexity.

CRUD operations within R/R might be just a few lines of code, but it's not that much more to accomplish the same with Node, Express/Railway, and any one of a bunch of template schemes.

The change certainly sounds appropriate for the team, but the basis of CRUD as a reason to change an entire architecture leads me to question how the team approached their solution with Node.

Re: Why we moved from NodeJS to Ruby on Rails

#147

Post by prospero »

jroseattle wrote: post #146
prospero wrote: post #137

Earlier quoted context omitted.

I think the point wasn't that "asynchronous is hard", it's that "asynchronous is just incidental complexity". CRUD apps don't need to be asynchronous, and node.js has a relatively impoverished ecosystem for such apps. There are undoubtedly tradeoffs no matter what you use, but this seems like an eminently practical decision.

I'm not so sure about that (the async-is-hard part.) If one is making a decision of architecture change due in part to CRUD capacities within a framework, I'd guess the asynchronous programming model in Node.js is a little more than just incidental complexity. CRUD operations within R/R might be just a few lines of code, but it's not that much more to accomplish the same with Node, Express/Railway, and any one of a b…

Unless you're taking the sunk cost of the node.js development into account, I don't understand your point.

If the core programming model for node.js doesn't help them in any way, and the ecosystem is less mature, then it kind of misses the point to say that everything is doable in node.js. Whether something can be accomplished is not a good metric for whether a platform is productive.

Re: Why we moved from NodeJS to Ruby on Rails

#148

Post by yannski »

danbmil99 wrote: post #135
yannski wrote: post #116

Earlier quoted context omitted.

What it this "low task-switching barrier" ? I mean, even though, the language is the same, back end coding and front end coding are really different. For example, your front end development may have lagged because of lack of front end development knowledge, not because of this mythical task switching barrier that everyone is talking about !

Maybe not true for everyone, but I find when working on quick prototypes of web ideas, where I have to write both front and back-end code, the fact that they're both in the same language with node.js is actually a huge advantage -- much greater than I expected.

IMHO the main problem is that usually front end development implies XHTML/CSS integration and/or UI and/or UX, and that's a very different job from back end development.

Re: Why we moved from NodeJS to Ruby on Rails

#149

Post by scraplab »

reissbaker wrote: post #143
bad_user wrote: post #104

Earlier quoted context omitted.

Only rookies do that inside the web server process. The job of fetching a Twitter feed can be offloaded to a background jobs queue. With a little help from Nginx, you can free the Ruby process to take care of other requests until the response of that Twitter feed is ready. Or you could simply deploy your Rails app on top of a Java server, by means of JRuby and forward that request to a servlet that uses the continuat…

Rails does work with multi-threading. Ruby has no support for concurrency, no matter how many threads your interpreter is using. 1.8 had no OS threads at all, and 1.9 has a global interpreter lock. This is not solvable in the application layer (for example, by a framework like Rails): this is a problem inherent to the runtime.

MRI doesn't, but JRuby supports full parallel, concurrent threading. Which is brilliant.

Re: Why we moved from NodeJS to Ruby on Rails

#150

Post by philbo »

heroic wrote: post #97
sh1mmer wrote: post #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 intereste…

IMO, things like a good ORM(or ODM) are still way too far off in NodeJS. I am aware of mogooseJS, but it is very far from the power provided by ActiveRecord and Mongoid. Also mocha is powerful, but if you have a look at capybara and rspec, they are much more powerful and friendly. The final thing in my opinion is the speed of development. With rails you go to devise, and you have authentication. I am aware of the pre…

I started looking into libraries for a Node-based model layer this weekend. The two most interesting after my initial reading about are Tubbs [1] and Resourceful [2].

I won't have a chance to actually play with them properly until this weekend unfortunately. Anyone else have any experience with these two (or other options)?

[1] https://github.com/dandean/tubbs

[2] https://github.com/flatiron/resourceful

Post reply on HN