Live data from Hacker News

Why we moved from NodeJS to Ruby on Rails

blog.targeterapp.com

111–120 of 166 posts

Re: Why we moved from NodeJS to Ruby on Rails

#111

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

Learning new technologies is something I do, not because I'm interested in getting hired or in becoming the DHH of node. I would do it even if I were by profession a truck driver.

This may sound "romantic", but when your love of technology interferes with you actually being productive and getting things done, ... it's frustrating.

If you are a student, then jumping on a new platform and making a name for yourself is a great thing to do. But I'm an old fart, I was there when Java applets were "the thing that will change the world".

>There will be new kinds of software that directly result from the new possibilities of Node, CoffeeScript, Meteor, Firebase, Parse, etc.

Like what? (not rude, just curious)

As far as I can see there's nothing new under the Sun, so to speak.

Re: Why we moved from NodeJS to Ruby on Rails

#112

Earlier quoted context omitted.

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

What do you even mean by scale in this context? https://en.wikipedia.org/wiki/V8_%28JavaScript_engine%29 V8 increases performance by compiling JavaScript to native machine code (x86,[2] ARM,[2] or MIPS[3] CPUs), before executing it, versus executing bytecode or interpreting it. Further performance increases are achieved by employing optimization methods such as inline caching.

I mean the language itself, not the performance of the individual implementations. For example, I can't imagine prototype based OO being used for large scale projects.

Re: Why we moved from NodeJS to Ruby on Rails

#113

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…

What java service?

Re: Why we moved from NodeJS to Ruby on Rails

#114
I suspect -- and I may be wrong -- that the advantages of using Node differ between large teams and small teams. For my first startup, I had the budget to hire a single full-time developer. The was a substantial amount of work to do on both the frontend and backend -- with the backend development needing to get underway first, but the frontend work being much more experimental and needing to go through many more iterations as part of the development process (we understood this upfront).

My developer did his homework, and came to exactly the same conclusions about Node that this article highlights. So he began developing the backend in Python/flask. I'm sure that was a good choice for the backend, on general principle.

However, we began hitting problems when it came time to start developing and iterating the frontend in parallel with the backend: it proved to be almost impossible for a single person to handle the task-switching between two completely different languages, testing frameworks, etc. So backend development lagged a little, and frontend development lagged a lot. I'm fairly sure this set the project back by 3-4 months. It wasn't until we brought on a dedicated front-end programmer that development was able to pick up pace a bit.

So I can see how for larger companies, it is probably best to optimise the backend with something other than Node -- you will have enough people working for you that backend and frontend programmers can specialise. But for companies with two (or fewer) developers -- which know that they also have to be doing a quite substantial amount of javascript on the front-end -- then I suspect that Node's comparative small task-switching penalty is probably hugely valuable.

That's just my hunch, but it's lasted a long while. So as I get ready to hire a couple of developers for my second startup, I'm leaning towards using Node. It's a frontend-intensive application which is unlikely to ever have to deal with "web-scale" issues that more mature backends are needed to handle. And if it does ever approach "web-scale", then it'll certainly have the budget to hire additional programmers to re-implement the backend in something else -- or maybe, by then, Node will have evolved into something sufficiently robust. Either way, it seems better than causing ourselves a bunch of task-switching pain upfront.

I'd be really curious to see a critique/comparison of Node which addresses the relative merit (or lack thereof) of its low task-switching barrier -- particularly for small teams.

Re: Why we moved from NodeJS to Ruby on Rails

#115

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.

Python is great for that sort of thing - but there do exist CLI helper libraries for Java in Apache Commons that make it almost as nice. It's just wierd to me to make development tooling for a langage in a different language - and indeed, if you find yourself doing this you might want to ask yourself why. (Of course there's a clear market reason - the hosted Ruby on Rails market is locked up by Heroku, but the hosted Java market, apart from a subset of JEE supported by GAE, doesn't even exist.)

Re: Why we moved from NodeJS to Ruby on Rails

#116
post #114

I suspect -- and I may be wrong -- that the advantages of using Node differ between large teams and small teams. For my first startup, I had the budget to hire a single full-time developer. The was a substantial amount of work to do on both the frontend and backend -- with the backend development needing to get underway first, but the frontend work being much more experimental and needing to go through many more iter…

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 !

Re: Why we moved from NodeJS to Ruby on Rails

#117
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…

Personally id say Node and Rails simply shouldnt be compared in any way. They are just too different technologies. So node shouldnt even be concerned about trying to be rails at all. People are going to use whatever they want to regardless. So node should just do what its own users need. And thats it.

Re: Why we moved from NodeJS to Ruby on Rails

#118

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…

I see what you mean by ironic, but it might be a bit less ironic when you consider the history of the name "JavaScript." Its original market positioning was as a lightweight complement to the heavier Java. Now we have other languages serving in that capacity as well: Python, Ruby, Scala, etc.

I don't know if there will someday be a language that is as easy to work in as a Python or Ruby for simpler programs but which lets you get (almost) as fast and fine-grained as C as your features stabilize and you start to optimize, but while we're waiting for Godot, it's not too ironic to use different tools for different projects, even if the project relates to one language in particular.

(And I don't know why you were downvoted for this. Sheesh, downvoters.... I'm contradicting you a little with my post, but I see no reason why you shouldn't say what you think. So, after contradicting you, I'll now go and cancel your downvote with my upvote. How's that for irony?)

Re: Why we moved from NodeJS to Ruby on Rails

#120
post #46

I could write a similar post, having used Node on a couple of projects before nodding to reality and switching back to Rails for a larger project. For a "typical" web project, Rails simply has a ton of mature libraries that don't exist in Node, or are very early days. Sure, there might be a basic data mapper, but does it have support for testing? Automatic counter caching? Workaround on StackOverflow for a hundred th…

There is a project coming up - railwayjs. I hope it changes the way people use nodejs!

That's part of the problem in a way. Rails-style large applications are kinda poor by-design. Even Express suffers from this more than I'd like (express-specific plugins etc). Ideally Express "plugins" or extensions would just be thin wrappers around things that the rest of the Node community can utilize. I'm guilty of this too of course but that's largely due to time constraints.

Anyway, writing Rails for Node won't be anything revolutionary, it would just be... Rails on a different platform. Frankly lots of developers including myself prefer these smaller frameworks, sure some things might be a bit slower to get started with but ultimately you're not fighting a framework, it's just another block of lego.

I used Drupal for about 3 or 4 years, and you can get things going much faster than Rails even, but you'll spend a lot of time fighting the thing.

Post reply on HN