Does anybody else get a little question mark over their head whenever they read about the "novelty" of being able to use javascript on the server?<p>Certainly everybody must remember ASP, which let you write all your server-side code in Javascript way back in 1998. You can still do it today, even in ASP.NET MVC.<p>And just like Node, nobody ever really shared much rendering code between the client and the server using that technology either.
"The Ruby community has been criticized for being exclusive and harsh."<p>I haven't found that to be the case at all, unless you're asking questions that are easily solvable with a quick Google search (and that mostly stems from the flood of inane questions from Indian "programmer mill" graduates).<p>Node's community also benefits from the fact that a lot of people are still trying to wrap their heads around events and callbacks, so they naturally help each other through the process.
Im not sold on node. Why should i ristrict myself? There are async librarys in lots of languages you can use them if you have a problem that suits the async modle but you can use other models to if they are better.<p>The other thing with node is that it is single threaded do do multicore you have to use process witch are slow in communicating. This could work now because we often only use quadcores but in the next years we will have many many more. Is it a solution to start node up for say 16, 80 or 1000 cores?<p>Im not ranting on node I hear it works fine for some stuff but the benchmarks that got everybody so exited in the beginning was not really that practical.<p>If I write a low level it might be fast because it maps to the C stuff good but if I write a big application with lots of layers of JS will it still be fast? (I know that V8 is getting better but it there jet for big server applications?).<p>Hope somebody can talks about this.
It's more like "Everyone is talking less about Rails" - the only new kid in Rails block is Haml/Sass and Rails is obviously stagnating compared to the hype it had couple or more years ago. Ruby/RoR is more about evolution now: Rubinius, JRuby going for stability, SalesForce adopts Heroku as one of it's development platforms - look, even one of Big 4(DTT) hires RoR-consultants now.<p>JavaScript on the other hand is booming both on client (SproutCore, Backbone, Cappuccino, CoffeeScript, GWT) and on server (Node). JS is just more "hackish" today - browsers are evolving day-by-day, taking more and more functionality from server - RoR isn't key to success anymore, it has become just another alternative for your REST backend.
Why Everyone Is Talking About Node: The very smart guys at Joyent are packaging it and pitching it perfectly.<p>The mobile platform has been gaining steam and so real-time interaction is becoming more important. Joyent was smart enough to see this & find a way to put their current infrastructure (lots and lots of invested $$) right into the middle of this. Node is well packaged as a solution to this. Very smart.<p>No doubt Node is the right solution for a lot of problems. And the guys working on it are very smart. But personally, I think that Node and Erlang compare somewhat like Lisp and C. At least at this point...
Love this comment:
"I'm still firmly convinced this recent enamour with node.js and particularly with the javascript programming language is the single biggest case of Stockholm syndrome ever."
<a href="http://mashable.com/2011/03/10/node-js/#comment-163390713" rel="nofollow">http://mashable.com/2011/03/10/node-js/#comment-163390713</a>
"It allocates web server resources on an as-needed basis, not pre-allocating a large chunk of resources for each user. For example, Apache might assign 8MB to a user, while Node assigns 8KB"<p>What? Apache may allocate 8MB of stack space for each thread, but that doesn't mean it consumes that much memory. This is distorting facts.
Where does the author get the idea that JavaScript is easy? As a Ruby and Node developer, JS is much harder. Fewer libraries, less syntactic sugar (e.g. 3.hours.ago, 3.times) and a prototype object system.
If you're into Node.js and Redis we (Voxer, interviewed in the article) are actually hiring engineers. We're building a Walkie Talkie for iPhone and Android.<p>In more technical terms Voxer is a low latency messaging system for voice, images, and text. We have an iOS client in the App Store, and an Android version is in the works. We've had explosive growth in the last couple of weeks and are now in top 25 in a bunch of app stores and we are looking for someone to help us develop the server side components and make the system scale.<p>Email me gustaf@voxer.com if you want to know more and I'll connect you with the right person.<p>Our servers are built out of Node.js, CouchDB, and Redis. If you are excited about node, server-side JavaScript, and new databases, this is an opportunity to work on this technology full-time.
<i>A misunderstanding of the technology is also a risk. Former Twitter engineer Alex Payne’s claim that Ruby was slow continues to haunt general conversations about Ruby to this day</i><p>The more things change, the more they stay the same! Chatter about slow will hang on even when the facts contradict.
What I find fascinating about node.js is that it is one of a long chain of products that represent the constant repackaging of old ideas - with better results.<p>Twisted has been around for a long time and was the best (IMO) platform for building real time apps. Many of the first great comet apps were built on twisted. But you really have to work at using twisted - the docs aren't great, the reactor / deferred patterns take some time getting used to, and finally and most importantly the community isn't effective in evangelizing their product (sorry Glyph)<p>Another issue seems to be timing. Low latency apps have a current buzz and you see people rediscovering old collaborative ideas like Push to talk (referenced in the article). I wish them luck - PTT has failed spectacularly in the past but maybe will have a strong second life in a world full of smartphones. Node.js seems to riding this wave - and the backers leveraging the buzz to drive interest in the platform.<p>I also wonder if location is an issue. The Twisted team had a strong core in Boston while the Node interest seems to be coming out of the valley - and leveraging that environment's idea pressure cooker.<p>It also seems that node.js would benefit from a good implementation of the generator pattern that would enable you to write asynchronous code in a (somewhat) iterative style. Unfortunately I don't think that V8 implements any of the ecmascript extensions pioneered by Mozilla that implement yield, list comprehensions, and other fun stuff.
Thanks to Mongrel2 you can do real time in Ruby too or with the language you happen to like the most or for which you have the right "business logic" libraries.<p>Having code in production running both NodeJS and Mongrel2, I am happy to see both of them growing.
FWIW, the author of the article said that she's going to do a little more investigating and likely change the language she used about the Ruby community.<p><a href="https://twitter.com/elight/status/45924501715828736" rel="nofollow">https://twitter.com/elight/status/45924501715828736</a>
Why do people cheering for new web technologies like to spread FUD against Ruby/Rails?<p>From the article, Ruby developers are assholes, Rails doesn't scale (for an umpteen time) and Ruby has high barrier of entry compared to Javascript (I don't know what does this even mean).
I'm confused by the statement that "only one company came out of rails rumble". I freelance for a startup that has a profitable SaaS app that was born at rails rumble 2007.
You would think a Rackspace sponsored article about Node.js would mention Nodejitsu, a Node.js hosting company built on top of the Rackspace cloud which has created Node.js libraries for Rackspace's cloud apis.<p><a href="http://blog.nodejitsu.com/nodejs-cloud-server-in-three-minutes" rel="nofollow">http://blog.nodejitsu.com/nodejs-cloud-server-in-three-minut...</a><p><a href="https://github.com/nodejitsu/node-cloudservers" rel="nofollow">https://github.com/nodejitsu/node-cloudservers</a><p><a href="https://github.com/nodejitsu/node-cloudfiles" rel="nofollow">https://github.com/nodejitsu/node-cloudfiles</a>