Earlier quoted context omitted.
The main reason Node.js is gaining popularity is because it is blazing fast, scales very well due to its IO + event driven architecture and it has the best support for websockets (see socket.io). 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 shif…
node.js isn't really that fast for traditional apps, but if you were to compare, it's pretty much on levels of nginx and it's actually slower serving static files. only in few cases node.js shows its power, i.e; real-time apps/games. i wouldn't build any full-blown websites in node.js. only a certain piece on the site i'd do it in node, like a widget or something.
RailwayJS
31–40 of 50 posts
Re: RailwayJS
#32Neat project! To echo what everyone else is saying, thanks for putting this out there. 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 t…
http://www.unlimitednovelty.com/2012/08/debunking-nodejs-gis...
Re: RailwayJS
#33Earlier quoted context omitted.
node.js isn't really that fast for traditional apps, but if you were to compare, it's pretty much on levels of nginx and it's actually slower serving static files. only in few cases node.js shows its power, i.e; real-time apps/games. i wouldn't build any full-blown websites in node.js. only a certain piece on the site i'd do it in node, like a widget or something.
Yep, you shouldn't be using node to serve static files anyway. This is something a reverse proxy such as nginx should do. Node can then be used to serve either as a pure API (serving json with express is the easiest way) for a webapp or render the webpages.
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.
Re: RailwayJS
#34Earlier quoted context omitted.
If it's about higher request capacity, PHP scales horizontally with its share nothing, no application server architecture. I'm not advocating, just sayin'.
Nonblocking IO doesn't preclude horizontal scaling. 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 cas…
That you can actually do in PHP, for example with gearman:
http://docs.php.net/manual/en/gearman.examples-reverse-bg.ph...
Re: RailwayJS
#35Neat project! To echo what everyone else is saying, thanks for putting this out there. 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 t…
I think the sweet spot for this kind of thing is when doing websockets. For a "normal" site, Rails is fine; it does a ton out of the box, and I like the language more than Javascript. However, the websocket story with Rails is not as clear as with something like Node, Erlang, or Go. This is worth repeating: 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.
Re: RailwayJS
#36Earlier quoted context omitted.
I think the sweet spot for this kind of thing is when doing websockets. For a "normal" site, Rails is fine; it does a ton out of the box, and I like the language more than Javascript. However, the websocket story with Rails is not as clear as with something like Node, Erlang, or Go. This is worth repeating: http://www.unlimitednovelty.com/2012/08/debunking-nodejs-gis...
May be not as much clear. But Ruby world has plenty of options for Websocket as well. I have built production Websocket server on top of Goliath and Faye and it works like a charm. https://github.com/faye/faye-websocket-ruby Faye is the the most feature complete websocket implementation out there and it works quite well.
Re: RailwayJS
#37Earlier quoted context omitted.
Nested callbacks in JS means functions are first class members of the language.. ... thus ... Functional programming is possible in JS.. ... thus ... You can create beautiful abstractions with your code.
First class functions != Functional programming language
It's a fact that you can create functional abstractions in JavaScript. Just like you can in Python and Ruby.
Re: RailwayJS
#38hashbangs URLs are so 2010. :p
Re: RailwayJS
#39Earlier quoted context omitted.
No problem. We can all have different opinions, but the good thing is we are all innovative, experimenting developers :).
Perhaps I'm missing something but how is this a matter of opinion? If one wanted to avoid callbacks, which were the OC's original issue with node, one would break up the callback spaghetti into distinct, possibly prototyped objects, and glue them together with node's events. How is that any more difficult to maintain than, say, Python classes? If anything, I personally like the ability to choose the coding style with…
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.
Re: RailwayJS
#40Earlier quoted context omitted.
May be not as much clear. But Ruby world has plenty of options for Websocket as well. I have built production Websocket server on top of Goliath and Faye and it works like a charm. https://github.com/faye/faye-websocket-ruby Faye is the the most feature complete websocket implementation out there and it works quite well.
Yeah, it's not like it's impossible with Ruby, but especially compared to a system like Erlang - to my way of thinking - it can start to look a bit clunky when you try and get lots of pieces talking to one another if, say, most of the rest of the application is in Rails. Or at least that's my impression, maybe I'm wrong?
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.