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

91–100 of 166 posts

Re: Why we moved from NodeJS to Ruby on Rails

#91

Post by benatkin »

karterk wrote: post #28
Fluxx wrote: post #25

> NodeJS is suitable for apps that do plenty of short lived requests. I'm confused. Isn't Node's event-loop style programming ideal for long-lived requests? I.e. ones that, under a synchronous i/o, block other requests?

The OP probably meant short-lived with reference to CPU bound requests.

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.

Re: Why we moved from NodeJS to Ruby on Rails

#92

Post by stcredzero »

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…

With respect to the author of this post, the testing environment and the ease of developing a CRUD web application are things that should have been looked into before a single line of code intended for production had been written.

The former: Golden. The latter: Eh, not so much.

Re: Why we moved from NodeJS to Ruby on Rails

#93

Post by gordianknot »

sasha-dv wrote: post #72

This reads like my life story. Falling in love with a new technology, trying to use it in production, only to find out that it just isn't there yet :) Node.js will become a great option for web development, but I don't think that node, at this moment, is ready for "mainstream" use.

To me that's the value proposition actually. Invest in learning and collaborating now, then be ahead of the curve in a few years (if interested in getting hired) or be ready to capitalize and know how to hire and make software that only could've been made with it when it eventually reaches some level of maturity. I mean, those that grow it reap the best rewards.

Software is a product of the platform(s) it was built with, in the same way a novel is a reflection of the writer's language more-so than the writer. Microsoft's software is what happens when you use C and .NET; Google with C++, Java, and Python; Facebook with PHP; 37signals with Rails; etc. There are apps that will be built because they could only be built with a unified JS platform. There will be new kinds of software that directly result from the new possibilities of Node, CoffeeScript, Meteor, Firebase, Parse, etc.

Different tools yield fundamentally different results. Once a platform is "mainstream", it's to late, the big opportunities have already passed and the innovation is elsewhere. There's still a chance to be the "DHH of Node"; that spot's obviously already been taken in the Ruby world.

Re: Why we moved from NodeJS to Ruby on Rails

#94

Post by clarkdave »

javajosh wrote: post #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 targe…

Only the CLI utility in Play used Python, and the newest version has replaced this dependency with Scala/SBT instead. I imagine the original reason for using Python for the CLI was because it's pretty damn easy to do that in Python.

Re: Why we moved from NodeJS to Ruby on Rails

#95

Post by swedenborg »

brown9-2 wrote: post #73

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?

A Document Based Store have several advantages over traditional for ex. relational stores ...

Mongo core is c++ and can be utilized from any lingo ...

It is schema less but can be desribed with a schema . it is named collections and on the fly add a tables or rows, no migrations downtime etc.

scary for some ...

Closing into what the oodb concept was setting goals prior ...

Re: Why we moved from NodeJS to Ruby on Rails

#96

Post by claudiusd »

When it comes to prototyping, anything goes - you should be optimizing for the speed with which you can deliver and market-test a product, and you should choose the tools that allow you to do so. The trick is having the discipline to pay back the technical debt that accumulates as a result of the fast, informal prototyping work.

I think the OP did exactly that, realizing that Rails is the better long-term solution for their engineering activity. I wouldn't say they "moved" from NodeJS to RoR, because that implies that that they chose a new technology to solve the same problem - they didn't... they chose NodeJS for prototyping and RoR for production.

I had the same experience transitioning from a prototype RoR app to a production app also written in RoR - I still did significant rewriting to improve testability/test coverage and make it more RESTful, but I didn't need to switch frameworks to do that.

Re: Why we moved from NodeJS to Ruby on Rails

#97

Post by heroic »

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 presence of a similar authentication system for nodeJS but I am not very sure if that works with mongoose js and is as extensible as devise is. And then there is the rails console, which makes trying out things real easy and fun.

Re: Why we moved from NodeJS to Ruby on Rails

#98

Post by bad_user »

I only played with Node.js and I didn't like it. The event loop is cool for long-lived requests. It scales and so on.

However for the project I worked on, I decided to go with Ruby on Rails + Java Servlets.

You see, only some parts of an API needs to scale. But what about simple web pages like the viewing/editing of a user profile? What about viewing some stats that are auto-generated? What about the freakishly boring admin interface that every web app must have? What about deployment automation? What about just searching for a library that already does what you want and actually finding a good one?

Therefore I've built a Ruby on Rails app. Everything except the API that needed to scale was built on top of Rails. Then the API with scalability concerns was built as a couple of Java servlets. And I deployed the whole thing on top of Jetty.

The wonderful thing about Jetty is that it has support for continuations, so requests don't have to block on processing in case you're doing something expensive. You can just push that processing in an Akka actor and release the request until a response is ready. And Jetty may not scale as well as something custom built on top of JBoss Netty or Apache Mina, however a single Jetty server does scale to ten thousand requests per sec easily. And in case that doesn't satisfy me at some point, Netty and Mina are there, waiting for me to tap their potential.

And then with the wonderful JRuby-Rack integration, I could configure Jetty to select between the pure Java implementation and Ruby on Rails for serving, based on the URL. So everything, like the Rails server, the Java servlets for the API and the queue processing (Akka) is running in a single process. Which really, is freaking awesome.

So why use Node.js, when I can get the Rails maturity and ease of use, while escaping to Java in case I have special needs, such as extreme scalability or flexibility?

Re: Why we moved from NodeJS to Ruby on Rails

#99

Post by base698 »

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…

Indeed, planning for 3 months to make sure you've done no wrong is much better than coding for a weekend, and determining then if you've made the right decision. Funding engineers for 3 months isn't all that expensive and everyone always makes the correct decision after 3 months of planning...

Re: Why we moved from NodeJS to Ruby on Rails

#100

Post by mbostock »

This post would benefit from concrete examples rather than vague complaints. For example, if something is "very immature", why not include specific examples of bugs or issues that required upgrading to "the latest version"? Likewise, if Node's testing frameworks are "good" but "no match for … Django", explain what's missing or how other testing frameworks are better. Being precise with your criticism helps the reader put them in context, and also helps maintainers improve their projects. Unsubstantiated criticism merely generates fear, uncertainty and doubt.
Post reply on HN