Most of the time, whenever I hit a website that looks "bubbly" in nature, and all prettified in those pastel-like colors, I think to myself, "This was probably done with Rails." And, lo and behold, after some digging into the site's information pages I discover this is actually true. So, I pose the question, not knowing much about Rails but enough about Django to understand how the database stuff works:

Does RoR have any display-specific qualities that affect how a web page looks? Or do all RoR devs naturally use the same Adobe tools to make everything look so ubiquitous?

Ruby on Rails is a server side technology, so it doesn't lend any specific quality to the user visible design. That said, it is a "trendy" technology so people who are likely to write their back-end code with RoR are likely to choose a particular "Web 2.0" style for their views.

It's kind of like saying "I notice that douches tend to wear backwards baseball caps and wear really baggy jeans. Does wearing a backwards baseball cap affect the tightness of one's jeans?" And the answer would be, no, however, a douche is likely to choose both of these clothing items.

I am a n00b in this kind of stuff but lately I've been hearing a lot about how good NodeJS is. Considering how much I love working with jQuery and Javascript in general, I can't help but wonder how to decide when to use NodeJS. The web application I have in mind is something like bit.ly - takes some content, archives it.

From all the homework I have been doing in the last few days, I obtained the following information. NodeJS

• is a command-line tool that can be run as a regular web server and lets one run Javascript programs
• utilizes the great V8 JS engine
• is very good when you need to do several things at the same time
• is event-based so all the wonderful Ajax like stuff can be done on the server side
• lets us share code between the browser and the backend
• lets us talk with MySQL

Some of the sources that I have come across are:

• Diving into Node.js – Introduction and Installation
• Understanding NodeJS
• A Gentle Introduction to Node.JS
• Node by Example
• Let’s Make a Web App: NodePad

Considering that NodeJS can be run almost out-of-the-box on Amazon's EC2 instances, I am trying to understand what type of problems require NodeJS as opposed to any of the mighty kings out there like php, python and ruby. I understand that it really depends on the expertise one has on a language but my question falls more into the general category of: When to use a particular framework and what type of problems is it particularly suited for?

Any suggestions?

You did a great job of summarizing what's awesome about node. My feeling is that node is especially suited for applications where you'd like to maintain a persistent connection from the browser back to the server. Using a technique known as "long-polling", you can write an application that sends updates to the user in real time. Doing long polling on many of the web's giants, like rails or django, would create immense load on the server, because each active client eats up one server process. This situation amounts to a tarpit attack. When you use something like node, the server has no need of maintaining separate threads for each open connection.

This means you can create a browser-based chat app in node that takes almost no system resources to serve a great many clients. Any time you want to do this sort of long-polling, node is a great option.

It's worth mentioning that ruby and python both have tools to do this sort of thing (eventmachine and twisted, respectively), but that node does it exceptionally well, and from the ground up. JavaScript is exceptionally well situated to a callback-based concurrency model, and it excels here. Also, being able to serialize and deserialize with json native to both the client and the server is pretty nifty.

I look forward to reading other answers here, this is a fantastic question.

I am wondering what is the general consensus for uploading moderately large files. I have a web app, and every time a user uploads a file (typically larger than 5mb), the web server tends to hang until the file upload is finished.

The above seems normal, because a single upload can take up a single HTTP request handler. Do web devs take this into consideration and either:

a) Pay for more HTTP handlers

b) Use some other method to overcome this by using AJAX, or other approach

I've heard that it is quite normal for web apps to have a few HTTP request handlers to take care of this, which will cost quite a bit more. On the other, if cost is an issue, then some have suggested trying to upload directly to the web server or storage service (i.e. Amazon S3) directly via Flash + AJAX. The latter method takes a bit of scripting and is a bit messy.

My second concern:

By using ajax to upload files onto a server. Does this still take up a whole HTTP request handler? i.e. does the server hang until the upload is finished?

Even with flash, I would still need to specify a url to upload to. The url would be one of the actions on my controller. Which would mean that processing still takes place on the server side. Is this right so far?

I was thinking. If I were, in the other hand, to use one of the upload scripts (plupload, uploadify, swfupload, etc) to upload directly to Amazon S3, then the processing is handled on the S3 server instead of the local web server. Which wont hang the web app at all. Am I understanding this correctly?

Would like to hear your feedback.

Thanks for the responses so far.

Unfortunately, our host Heroku does not support non-blocking, evented servers. I've also tried flash + javascript based uploaders like SWFUpload, Uploadify. Some variations of the mentioned plugins worked, and some didn't. Spent countless hours of trial and error, but didnt like how the code was being integrated on my Rails app.

In the end, went with manually uploading the file to S3 directly following this link. Which also enables a response back from the S3 server to notify us that an upload was successful, giving us the path to the uploaded file so that we can then create a background job (via redis + resque) to process the file.