RailwayJS
railwayjs.com
railwayjs.com
I'm still on the fence with Node and have yet to give it a real try. I think what will finally get me to jump in is something between the two. The sensibilities and structure of Rails with the great realtime features in Meteor. Just sayin.
EDIT: This does look fantastic by the way, a great contribution to the community.
I am curious as to what most HNers think of doing server side development in JS. It's obviously the flavor of the month, but I have yet to see the appeal. JS is certainly not a bad language, but it seems a lot more tedious than, say, ruby. The nesting of callbacks, the lack of built in OO infrastructure (given that most of us are trained with class based inheritance), the many quirks associated with making the language accessible to nonprogrammers. Am I missing something? Is there a really good reason to use JS on the server?
In, say, Ruby, you've got EventMachine for something equivalent but it's definitely "bolted" on to the language. Python has Twisted, with which I have no personal experience. In PHP, there are really no options.
The Node / EventMachine / Twisted version of nonblocking IO is built on the Reactor Pattern. The common use case is to minimize IO delay. Whenever there is IO, a NodeJS script will cheerfully continue execution of other code, whereas in PHP and other purely synchronous languages, the script would block while waiting for the result. In practice, this has more use cases than just IO, of course. For example, one can send heavy computations to background processes and execute other code while waiting for the result.
So back to the original point, yes, writing nested callbacks can be more difficult to decipher than "flat" code, but the results may very well be worthwhile if you are looking to squeeze maximum performance out of your hardware.
That you can actually do in PHP, for example with gearman:
http://docs.php.net/manual/en/gearman.examples-reverse-bg.ph...
On the flip side, code can be hard to maintain and you need to be more disciplined so that you can read the code later otherwise it becomes a callback spaghetti. Doing everything through callbacks also requires a mental shift.
Like with everything in life, there are pros and cons and tradeoffs. So choose wisely :).
If you write modular and/or functional code, JS code bases can be just as easy / hard to maintain as any other language.
Gevent in python for example is pretty popular and similar is the case with Em-synchony in Ruby.
I have used callback objects but really that is not even close to what one can achieve with Fibers or Greenlets.
It's fast, easy to setup (npm install), and relatively hardened, while still keeping everything JS.
As for static assets, those should probably be served from a CDN anyway, if one is concerned with performance.
It's a fact that you can create functional abstractions in JavaScript. Just like you can in Python and Ruby.
This is basically just restating "Javascript has first-class functions."
While first-class functions are nice, it's only the barest tip of the iceberg when it comes to what's needed for true functional programming. When you add more and stronger assumptions to your functions and types - referential transparency, static typing, immutable data structures - you get more and more back in functional expressive power and the tools that make it possible: memoization, concurrency, tail recursion, lazy evaluation, pattern matching, and so on.
The less assumptions you allow in the language, the more these powerful functional techniques and abstractions simply won't be possible. You still stand to gain from a modular, functional style, but you will have to go back to working around the inherently imperative language in most cases.
It plays a lot more smoothly with MongoDB and I find it far simpler to hook into more modern functionality with Websockets and client side JS rendering. I had a few issues with jugglingdb (which I forked and fixed) and it's all going smoothly.
I still use Rails for some sites but Node and railway.js let me bootstrap the whole API on MongoDB in a few days and get very acceptable performance.
http://www.unlimitednovelty.com/2012/08/debunking-nodejs-gis...
https://github.com/faye/faye-websocket-ruby
Faye is the the most feature complete websocket implementation out there and it works quite well.
The alternative of using node.js for everything sounds good but I am not really sure, how good node and its web frameworks are for building typical CRUD applications. Rails really solves building database backed applications problem pretty well.
I receive some kind of request in a Rails controller. I need to send, as a consequence, a notification via the web socket. How does it get from point A to point B? In Erlang, it's all likely to be quite contained and fast, and not involve writing anything to external queueing software, and to boot, it's all going to happen in the same unix process, rather than having one process that's the Rails server, and another that's the eventmachine server.
I don't know Node.js and how you'd handle sending messages from point A to point B, but I'd be interested in hearing some opinions.
I really like the idea of locomotive's 'initializers' directory - Any files you put in here are loaded at boot, in order. I use files in here to set up things like configuration, databases, logging, etc. With railwayjs these all ended up in the environment files which was hard to maintain.
The one thing I really didn't like in RailwayJS was the convention of putting all your database models inside one file (schema.js), I had to over-ride the built in ORM (JugglingDB) at the time because it was lacking features and define a customSchema() function to use mongoose, and this file ended up being really large and a bit of a mess. I tried separating things in to individual model files but I couldn't get it working without messing with RailwayJS code.
Probably a lot of the problems I had are now resolved as this was a few months ago, but I'm sticking with Locomotive from now on :)
Node.js isn't a framework. AND it's not a programming language. Node is ostensibly a set of libraries and a runtime environment. I've been to a few Node meetups over the past few years, and inevitably people (not just newbies btw) will ask "what will be the Rails for Node?" But I think making this analogy is wrong. It's wrong for two main reasons, the first of which is that it implicitly compares Node.js to Ruby, which is a category mistake. More importantly though I'd argue, it's wrong because making the Rails for Node analogy deprives the developer (you!) of the opportunity to allow an emergent programming paradigm to change the way you think about programming! So how should Node do that? My fantasy for how Node.js will evolve in the next few years is that it will be a series of node packages which can be easily dropped in and out of my programs. I believe that the goal of the third-party node package development community should be to encourage this modularity, because I think it is the right abstraction for what Node.js actually is, and not necessarily what some people might wish it was. It's easy enough to set up EventMachine in Rails and then you can use your familiar stack, but I'd encourage anyone looking to use Node.js to fully embrace it and use it as an opportunity to explore new workflows, and not just try to fit your old stack into an event loop.
hashbangs URLs are so 2010. :p
... more Node.js web frameworks: https://github.com/joyent/node/wiki/modules#wiki-web-framewo...
For example now I'm working on "RIO" (railwayjs + socket.io) module, which will unobtrousively add socket.io capabilities to framework. It also solves auth and user-to-user communication problems.
Another big way to go - client side. We have some information about application structure that could be used in client-side, and duplication through backbone on client-side is awful idea, why not just give and transarent API for it. And this is separate module too, not bundled in railway.
So, this is a biggest difference in my opinion, anything other we implementing are basically the same.
Definitely agree and that's why I am still undecided whether I want to use vanilla Express or a high level framework. RailwayJS is my top choice right now as it is built on top of Express and seems pretty modular. Tower also seems good but I dislike the fact that it is written in CoffeeScript.