11 ms·

Why we moved from NodeJS to Ruby on Rails

• mcantelon 14y ago
  I wonder what testing functionality, specifically, they see missing in the Node ecosystem...
  • heroic 14y ago
    I presume it would be something related to capybara, rspec and factory girl.
    • mcantelon 14y ago
      Looking at the example of integrating those on RSpec's docs page... pretty nice. https://github.com/rspec/rspec-rails https://github.com/rspec/rspec-rails My guess is a similar Node cocktail would be using Mocha, Tobi, and Should.js together.
  • FooBarWidget 14y ago
    I'm writing a server in Node and to date I'm still trying to figure out how to control the main loop from Node. I want to write tests like this: 1. register some timers and create some sockets 2. send some stuff over the sockets 3. wait until the socket handlers received some data which cause the handlers to unregister the sockets and timers 4. at this point, the main event loop has ended. go to next test and setup a new event loop How do you do (3) and (4) in Node? I have no idea, and I couldn't find any clear answers on the Internet. I ended up writing my tests in RSpec which launch Node processes, and I just check whether the stuff printed to stdout matches what I expect. RSpec also happens to have a much much nicer syntax than any Javascript testing framework I've encountered.
    • bergie 14y ago
      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_SendMessage.coffee#L46 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-mq.coffee#L111 https://github.com/nemein/kckupmq/blob/master/test/001_kckup...
      • jerf 14y ago
        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 you can fake events perfectly correctly, take that away and it sucks even worse.
        • javajosh 14y ago
          >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_callback 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.
          • jerf 14y ago
            "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.
    • no-espam 14y ago
      #3 I'm not undestanding. Are you doing async? I don't know the socket API but it should be something like this: it("should wait for socket", function(done) { socket.write("asdfadf", function(err, response) { assert.ok(response.indexOf('token') >= ); done() ); }); #4 If you need a new event loop then write the tests in another module, then simply run your test utility. `mocha` will run all tests in test/*test.js. RSpec is DOG SLOW! I can run 100s of test in a couple of seconds. Can RSpec even startup in that time?
      • JonnieCache 14y ago
        >RSpec is DOG SLOW! I can run 100s of test in a couple of seconds. Can RSpec even startup in that time? Yes, of course it can. RSpec is not especially slow. Obviously the ruby interpreter can be slow, for any given rspec test you could write something faster in C or Java or Go or whatever. That's irrelevant. I'm guessing you're referring to rails tests, where the whole rails stack has to be loaded with each run of the test suite, something that is notoriously slow. There are strategies to avoid this. Also it is very easy for the naive rails developer to write tests with extremely inefficient usage of the database, which creates horrible bottlenecks.
        • fckin 14y ago
          Exactly. If you know how to use stubs/mocks properly, you can write blazingly fast tests. I have a test that does ~100 assertions in <1 second.
    • substack 14y ago
      Check out tap, it has a very simple api that works well for testing asynchronous code: https://github.com/isaacs/node-tap https://github.com/isaacs/node-tap Here's a tap example that sets up a server and client for dnode: https://github.com/substack/dnode/blob/master/test/single.js https://github.com/substack/dnode/blob/master/test/single.js Timers usually aren't necessary with test harnesses like tap or nodeunit since you need to call `t.end()` explicitly or else `t.plan()` the number of tests that are supposed to be run. If a different number of tests actually run or assertions fire after `t.end()` is called, those are reported as errors. For (4), to run a bunch of test files in a directory you can use the `tap` command. You can even add something like `tap test/*.js` to the scripts.test field of a package.json file and then to run all your tests you can just do `npm test`.
    • doomslice 14y ago
      There's also mocha: http://visionmedia.github.com/mocha/ http://visionmedia.github.com/mocha/ Which has very similar syntax to RSpec.
      • ryan_f 14y ago
        Try writing tests for controllers with Mocha. It isn't as simple as one might think.
        • rodw 14y ago
          Can you elaborate? I feel that I've written tests for controllers with Mocha several times without much hassle. Maybe you and I are using the word "controller" slightly differently, or are controlling different things?
          • ryan_f 14y ago
            My apologies I wasn't too specific. I was meaning a controller through express. It's not as straightforward as you would expect with code buried throughout on how to set it up. This is a typical barrier for developers to not test as much.
            • doomslice 14y ago
              Express doesn't even have controllers though -- just a routing mechanism. If you set up your controllers so that they are independent from the routes, then they are just as easy to test. It could be as simple as: app.get('/users/:id', userController.userPage). You can then test userController.userPage(req, res, next) instead of the route.
              • ryan_f 14y ago
                True, but in the case of the app I need to start a test server and such. Its those steps that aren't well documented and can cause confusion.
• semarjt 14y ago
  >I am huge fan of NodeJs and I believe it’s a very technology and we will see it getting I think you accidentally word.
  • sushi 14y ago
    Thanks. Fixed now.
• jarin 14y ago
  This is why it's good to have a lot of tools in your toolbox. Everything has its strengths and weaknesses.
• Timmy_C 14y ago
  The argument he makes is that it boils down to maturity. One framework is still evolving and the other is more mature.
  • heroic 14y ago
    Exactly the point being raised i'd say!
• EternalFury 14y ago
  Does anyone know 1 major consumer-facing site that was able to scale with Rails? I know Twitter kind of had to move away from Rails due to scalability issues. GameBattles.com also had to back away from Rails after their uptime dropped to 80%. I am not trying to tarnish Rails, I am just curious to learn about some success stories involving Rails at very large scale.
  • codesuela 14y ago
    How about Github?
  • heroic 14y ago
    Shopify is using rails. The thing is rails is bad when there are a whole lot of short life requests. This is what twitter had. The entire rack middleware being loaded for every tweet.
  • OriginalSyn 14y ago
    I'd like to know this as well. Some of my Coworkers went to RailsCon a few weeks ago and were remarking how a speaker talked about how they scaled from tens of thousands of hits a month to a couple hundred thousand hits a month. Not very encouraging when that's the sort of traffic we get in an hour and the solution was to use nearly double the amount of web and memcached servers than we do now on our PHP stack.
    • andrewvc 14y ago
      You can't compare servers to servers. Each app has its own computational needs and caching rules. Your hit is not my hit. One site might simply render a template, another might perform 20 queries and generate giant complex docs.
      • OriginalSyn 14y ago
        While it's true you can't do 1 to 1 the fact that my site does ~700 times as much traffic, and it is absolutely the latter of your two types time ten is a cause for caution. This is why I want to hear from some actual enterprise level people that have solved real scaling problems, unfortunately at the conf it seemed like startup size scaling problems were being addressed, and perhaps not very well.
• julian37 14y ago
  The data is being written to the db, or being crunched, while the request is ending, and the browser can continue with the important stuff. It sounds like a good fit for NodeJS for sure, but for what it's worth, even in a synchronous web framework nothing forces you to keep the connection open until the request has been processed. I don't know off-hand how to do it in Rails, but say in Java Servlet-based frameworks you'd just call HttpServletResponse.close().
  • heroic 14y ago
    The point is that the rack middleware would be called for everything, which is very heavy for something so trivial
    • cmelbye 14y ago
      Of course, it's trivial to write request methods that bypass the rack middleware in Rails.
    • julian37 14y ago
      I didn't mean to imply that NodeJS isn't the best fit for the problem at hand. I was just trying to clarify that it doesn't take an asynchronous framework like Node to keep processing a request after the connection is closed.
      • mike-cardwell 14y ago
        Yeah, even with a simple Perl CGI, all you have to do is close STDOUT if you want the HTTP response to end, but continue processing the request.
• Fluxx 14y ago
  > 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?
  • karterk 14y ago
    The OP probably meant short-lived with reference to CPU bound requests.
    • benatkin 14y ago
      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.
      • bad_user 14y ago
        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 continuations support in EE 6, offloading the request to an Akka actor and freeing the pipeline until it is ready. Works great and you can even write everything in Ruby ;-) Also, Rails does work with multi-threading.
        • kylebrown 14y ago
          Or you could just use node.
          • bad_user 14y ago
            If all your app ever does is to fetch Twitter feeds, sure.
• gfosco 14y ago
  Basically they switched for... personal opinion. That's all I can really gleam from the post. You can do it all in Node JS, they just didn't want to. Screw all the frameworks, I am working with bare-metal Node and loving every minute.
  • Kynlyn 14y ago
    "You can do it all in Node JS" People like you scare the shit out of me. Golden Hammer is a new concept to you, isn't it? He actually did lay out the reasons, but your religious zealotry won't let you see it because someone isn't loving your sacred choice of technology.
    • gfosco 14y ago
      Lol.. They don't have to love it. They also don't have to write a blog post explaining why they stopped using it. It was done to generate press, because really no one here ever heard of their app before this. They gained, by slighting Node, and that's why I commented.
  • czzarr 14y ago
    definitely agree with this. I can understand why 37signals use RoR, because they built it and know it inside out. But for a newcomer diving into rails now is difficult because the ecosystem is so huge it's hard to navigate, and everything is so integrated and you usually end up bundling a ton of thin that you don't need. With node everything is modularized, it is much more easier to understand what's happening under the hood, and streams are freakin awesome.
    • triathlete 14y ago
      Completely agree. I tried to learn rails and gave up partly for this reason. I have been using node for a while now and LOVE it! I really dont understand why people bash node.
      • eropple 14y ago
• MatthewPhillips 14y ago
  The author seems to be confused about what Node.js is. > NodeJS is a very young framework, and packages around it are very immature. Node.js is not a framework. It is a JavaScript engine and standard library. Node is comparable to the MRI.
  • buerkle 14y ago
    A standard library is nothing but the default framework built into the runtime system.
    • MatthewPhillips 14y ago
      I don't see what you mean, the author is comparing Node.js to RoR so what you are referring to as a "framework", is not the same thing as the author. He is referring to a framework for writing web applications. Node is a "framework" for writing JavaScript applications that are compiled by V8 and executed on a *nix or Windows machine.
  • heroic 14y ago
    First thing is that NodeJS is not a JS engine, V8 is. Second, http://notinventedhe.re/on/2011-7-26 http://notinventedhe.re/on/2011-7-26. That is from http://nodejs.org/community/ http://nodejs.org/community/ which makes the terms quite right, i'd say.
    • MatthewPhillips 14y ago
      Node is V8 and a standard lib. Node is not an abstraction around http (which is what RoR is).
      • heroic 14y ago
        "Node.js is a platform built on Chrome's JavaScript runtime for easily building fast, scalable network applications." From nodejs.org
• mmahemoff 14y ago
  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 things the framework doesn't cover by default? Rails versus NodeJS isn't apples-to-oranges. Rails is an opinionated framework for web development, Node is a low-level evented framework. This is important because right now, Node has no Rails equivalent. It has Express as the equivalent of Ruby's Sinatra, but for a higher-level web framework, there are several possibilities and none of them the outright leader. This is the situation Python found itself in circa 2006, before Django became the de facto standard for web apps, and (speaking as a mostly-outsider) its seems to me the Python community is better for it. I truly hope a high-level framework establishes itself as the clear standard for Node development, presumably one which embraces the benefits of dual-side JavaScript.
  • heroic 14y ago
    There is a project coming up - railwayjs. I hope it changes the way people use nodejs!
    • mmahemoff 14y ago
      I hope so, but with the caveat that it's easy to start a project like this and a lot harder to see it through. Various Node projects have shown promise, but haven't gone the distance. If one really gains traction, that's great for Node overall.
    • tjholowaychuk 14y ago
      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.
• andybak 14y ago
  Maybe I'm missing something but isn't node for chat/messaging, API's and other stuff that you might have used something like Twisted for? Why would you use it over Rails/Django etc. for a content-heavy site (i.e. 95% of websites)
  • triathlete 14y ago
    I use node for everything now myself for a number of reasons. The "problem" with node is that its still very young. And its a different programming model then people are used to. So its similiar to the whole RDBMS/document store argument. You use what works for your applicaiton. The thing that annoys me personally is that they make it seems like there something wrong with node. And there isnt at all.
    • andybak 14y ago
      Does it provide any of the functionality that you get with a Django/Rails style framework? Or is it at a lower level?
      • triathlete 14y ago
        Yes of course via express.js and railway and several other frameworks. Again node itself is just a set of libraries on top of of v8. So its not a proper comparison. Personally i use express.js and roll my own framework essentially because i prefer to work that way.
      • andypants 14y ago
        There's are some web frameworks that are aspiring towards Django/Rails-style, but none that have a similar ecosystem of plugins and developers yet. The most popular web framework, express.js, is a bit more lower level, and is similar to Werkzeug from Python or Sinatra from Ruby.
• Spyro7 14y ago
  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, Node was chosen for just one reason – he wanted to develop the entire application in JavaScript. Other than this, it does not seem that he took the time to research the Node development environment before deciding to develop his application in it. 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. In addition to this, as several other commentators have already noted, Node is not directly comparable to Rails. Node is basically an event framework and standard library that bolts onto JavaScript. Node would be more comparable to something like Python's Twisted or Ruby's EventMachine. The author was probably using one of the frameworks available in Node such as Express.js, Railway.js, or Geddy.
  • heroic 14y ago
    Actually since the app was developed at startup weekend which gives you 54 hours to make a presentable demo, I'd say testing was not the first thing on their mind.
    • triathlete 14y ago
      Plus if they already knew rails. I use node mostly now and wonder why people would use anything else. However if i had alot of expertise in rails i would probably use it for most everything as well until i was comfortable enough with node.
    • mgkimsal 14y ago
      And it's generally nowhere near 54 hours... more like 42. We nominally started at 6pm on Friday night, but teams weren't formed until 9-10pm. Pitches were demoed Sunday afternoon, and 48 hours from the start on Friday - Sunday at 6pm, it was all over. I've no clue why they SW fixates on the "54 hours" number. 42 would be far closer to the truth, but perhaps more intimidating for people?
• fooooobar 14y ago
  This qualifies as news?
• j45 14y ago
  Wow, Node is being turned away from because it's too new, and Rails is the destination because it's established? I remember a few years ago Rails using the argument of re-inventing the wheel was the only way because there was presumably no other capable web framework out there. We all know better now and I hope celebrate choice that's relatively equally capable :)
  • VeejayRampay 14y ago
    Maybe some day people will finally realize what's so awesome about Ruby on Rails. It's not the libraries and the fact it's been around for almost 8 years now. No, it's simply the language. Ruby is a fantastic language and an addictive one at that. Once you get a feeling of how productive and expressive it is, it's enough of an incentive to keep at it. The same goes for Python by the way, another GREAT language. One day people will realize that Javascript just doesn't cut it.
    • j45 14y ago
      I think you totally missed my point. I was just speaking to how Railists too often, do not openly consider or think anything productive, well structured, or maybe even great could have existed before, or at the same time as Rails for the web. We forget the difference between a language and a framework as well. Too many folks short sightedly compare a language to a framework. Frameworks will always evolve and change, and few rarely do anything new or novel, just like languages may, but they're entirely different things.
  • petercooper 14y ago
    And people switched away from Rails back then too :-) http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_switched_back_to_p_1.html http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_swit...
    • sparknlaunch12 14y ago
      Is this article from 5 years still relevant? I know you said 'back then' but curious to know whether one should stick with php.
• sasha-dv 14y ago
  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.
  • gordianknot 14y ago
    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.
    • sasha-dv 14y ago
      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.
• brown9-2 14y ago
  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?
  • radicality 14y ago
    I didn't understand that either. MongoDB works very well with many other languages; just recently I was using it with Python, and the driver and API work very well. I guess since MongoDB stores data in BSON, which is the binary version of JSON, the javascript object format, the author decided that JS is closest in spirit to Mongo.
    • andypants 14y ago
      The mongodb shell uses javascript, and stored functions and map/reduce functions and more all use javascript. So if you use mongodb, you'll be using quite a bit of javascript anyways.
  • triathlete 14y ago
    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.
    • brown9-2 14y ago
      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.
      • MatthewPhillips 14y ago
        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.
• fiaz 14y ago
  The important point in posts such as these is that execution matters, not the tool you use. If the tool you decide to develop with fits, then use it. If you find out later it doesn't work, then switch. Sure, the tool you use can affect your execution, but that only means you have to understand how you want to execute before even selecting a tool. I think it would be a big mistake to read such a post and come to the conclusion that Rails is somehow superior to node.js.
• javajosh 14y ago
  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.
  • clarkdave 14y ago
    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.
    • javajosh 14y ago
      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.)
      • bad_user 14y ago
        If you have to ask yourself that question, then you haven't really worked with a scripting language like Python or Ruby.
  • heroic 14y ago
    What java service?
  • SiVal 14y ago
    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?)
• philjackson 14y ago
  I'd love some elaboration on these points, especially the one about testing as it's an area that interests me.
• sh1mmer 14y ago
  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.
  • heroic 14y ago
    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.
    • philbo 14y ago
      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 https://github.com/dandean/tubbs [2] https://github.com/flatiron/resourceful https://github.com/flatiron/resourceful
  • triathlete 14y ago
    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.
• claudiusd 14y ago
  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.
• bad_user 14y ago
  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?
• mbostock 14y ago
  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.
• nkoren 14y ago
  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.
  • yannski 14y ago
    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 !
• triathlete 14y ago
  For anybody wanting to learn about node the NodeUP podcast is excellent.
• LoneWolf 14y ago
  First of all I would like to say that I'm no fan of these 54/whatever hour coding rushes, I think it makes people go too fast with poor planning and NO time for testing anything, even for developing looks short, I would rather take my time to plan anything before writing a single line of code. About Node I have played with it and it looks nice but at the end of the day I just returned to Java and PHP (can't talk about ruby never tried and not sure when I will), why? First, all the Node talk seems to revolve around the hype it generated recently, why I don't know. The idea of the async is nice but stall it with something that takes long to process (and needs to send a response) and you are screwed just like any other language, but I think node may be worse as far as my understanding goes its a single thread dispatching stuff (am I right? please correct me on this if I'm wrong). Libraries for it, there seem to be too many of the same kind all of them with different ways of working that is not easy, and when I tried it none did what I wanted.
• petercooper 14y ago
  This reminds me of Derek Sivers switching from Rails back to PHP 5 years ago :-) http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_switched_back_to_p_1.html http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_swit...
  • wamatt 14y ago
    Haha great find. Thanks. I agree, I think it would have been important to also say just how quickly Node.JS has developed. I'm a firm believer it has a very bright future, but this is not a zero-sum game.
• rmATinnovafy 14y ago
  My take on this is that it is more about getting the MVP out with "whatever" (in this case Node), than anything else. I do this all the time. Some ideas get mocked up in python, others PHP, some in C#, etc. Then if it sticks, I look at the needs it has and pick the best tool for the job. Sometimes it Rails, others its .NET. Though it is quite interesting to read about it from someone else's point of view.
• jroseattle 14y ago
  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 heart, and one can only build a successful application if you follow the programmatic model as it's designed. It doesn't matter how simple or complex an application may be, if a framework is being bent to work in ways in which it wasn't designed, the application may not work so well. Reading between the lines, what I'm getting is a picture of a team that has encountered productivity issues with the current stack and is migrating to a more familiar stack to increase productivity. Nothing wrong with that tradeoff, but I always look to what future tradeoffs are being made: "cache everything and gets the work done ASAP" is great until you need finely-grained control of your queries. I'm sure they thought well about their decision, but if asked to make a wager -- I'd guess that certain problems are being traded from one framework to another.
  • prospero 14y ago
    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.
    • jroseattle 14y ago
      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.
• edwardtrunk 14y ago
  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.
• sparknlaunch12 14y ago
  Ok. So for a beginner coder looking to build web sites and mobile apps on weekends. They are not looking for a career or job coding. What language? Assume they know html, CSS, Javascript, SQL. Where do they go and spend their next 12 months? When do the differences matter?
• ronreiter 14y ago
  It saddens me that so many developers need to learn why it's a mistake to build a system in node.js right now, just because it's "cool" right now. A variation of this post showed up on HN about 20 times already. The lesson is simple - don't use node.js to build big apps, it's still immature.
• kajala 14y ago
  If you think how the whole web development has been changing from server-side generated views to more "produce data and send it over as JSON" style services, Node.js and others start to make a lot more sense. That said, the post has point that on more established platform you can expect to be more productive since you have more established work flows and standard libraries. Btw. note the terminology: Node.js should not be called "framework", it's a platform. "Framework" is something that runs on platform and you extend/modify it's functionality by writing code. "Library" is something which you call/use from your code.