Complete Web Apps in Ruby Without Using Any Frameworks - How Difficult? Pitfalls

Ruby web pages without any framework from scratch

Writing a simple CGI in Ruby is easy, however, explaining how is beyond the scope of Stack Overflow.

To start, read Wikipedia's Common Gateway Interface article so you have a basic idea of what a CGI has to return. Pick apart the Perl example; You should be able to figure out what's going on easily enough. Read through the article and compare what it says to what the code example is doing.

Next, look at Ruby's CGI module, because it will help you parse incoming form information, and encode/decode URLs and HTML. Look at the table of environment variables, and you'll see the same things passed in that are mentioned in the Wikipedia article. Next, notice the params() method, which is how you access form variables. Follow that by reading the "Writing output" and "Generating HTML" sections, and nose about in the examples. You should be on your way then.

Once you've done that, you should take a look at the Sinatra gem. It's a very nice, easy to use, framework that is well suited for general web use, and, after getting an understanding of how a CGI works, you'll be in a good place to appreciate what Sinatra does for you. Additionally, I highly recommend using HAML with Sinatra. It's a short-cut language for generating web pages, similar to ERB, but less verbose.

You'll find that PHP has shielded you from a lot of the knowledge needed to write a "normal" web application using a CGI. That's OK if you already know that stuff, but it's bad if you have never done lower-level code, or are trying to use different languages, because knowing the CGI layer provides a lot of knowledge that is needed to understand the whole HTTPD stack. Once you know the CGI layer, things like Sinatra, Rails, Django, Mojolicious and all the other frameworks out there suddenly make more sense, and you'll know when to take advantage of them or roll your own. And, PHP's place in the HTTP server will be clearer too, allowing you to pick and choose your tools better for the job at hand.

Creating a web app in Ruby without a framework

Is it possible to make a web app in ruby without using a framework?

Too long; Didn't read

Yes, it is definitely possible. Most of the Ruby frameworks are built with pure Ruby on top of other middleware libraries such as web server interfaces.

Ruby and the Web

Ruby is a general purpose language; therefore it is not specifically designed for web development. PHP, for example, is a language that was written to create web applications. In Ruby you are going to need some libraries to properly handle HTTP headers and web specific elements.

In Python, for example, (another generic programming language) we have a standard web server interface specification called WSGI (Web Server Gateway Interface). Every server that implements the WSGI specification is called WSGI-compatible. And any WSGI-compatible server can run the same WSGI Python script in the same way.

Why am I telling you this when speaking about Ruby? Because Ruby has a very similar concept to WSGI, with the possible exception that it is not yet a standard. Its name is Rack, and it provides an interface to deal with common low-level HTTP/Server stuff you don't want to deal yourself so that we can use Ruby as if we were using PHP.

Ruby, Rack and Apache

Let's take a real life example: Apache. Apache is one of the most common web servers out there. How does PHP work with Apache? With mod_php. How do Python WSGI-compatible applications works with Apache? With mod_wsgi. How do Ruby Rack-compatible applications work with Apache? With mod_rack. Can you see the pattern here? The web server needs to know how to properly link your application to the request/response web context.

Rack example

Without dealing furthermore in this abstract talk, let's focus on an example:

class HelloWorld
    def call(env)
        [200, {"Content-Type" => "text/plain"}, ["Hello world!"]]
    end
end

This example is provided by the Rack website and it explains how a Rack-compatible script runs:

You install rack on your web server (you'll find plenty of tutorials on Google specific to your web server)
You create a config.ru file in the root folder (.ru is mostly Ruby)
You paste that script
You run it with the run method

Et voilà, we have a web server interface. The env hash contains the environment variable from the current request and the array you are returning contains 3 components:

The response status. 200 stands for "Everything is ok". 404 stands for "Not found". And so on.
The HTTP header. These describe the response body. Its length. Its content. And so on.
The response body. This contains the actual output of your application. HTML, JSON, XML, HXML, simple text... whatever.

In PHP for example, all this is done automagically. When you do echo "Hello"; the response status and headers are generated for you by the PHP interpreter.

A note on alternatives

You can dig in this field all you want but most of the technologies listed below are either deprecated or their use is highly discouraged by the community.

In the first years of the web there was a common interface used to run Perl, Python, Ruby, C scrips in the server side: CGI or Common Gateway Interface. This is an interface that can be used by pretty much any programming language out there, but it is generally considered slow.

Some thought to revive this interface by making it faster. And from that, guess what, arose FCGI, or FastCGI. This technology is used more often than you might think. Some PHP scripts are converted to FCGI scripts sometimes to make them run faster. I don't want to go further on this topic, as there are many other references out there.

And finally, you could create your own web server. You are actually not forced to create the web server with Ruby in order to use Ruby. Theoretically speaking, a web server is as simple as:

Listen to a port (80 most of the time) until a request comes in
Deal with the request
Output the response
goto 1

In the real life environment, you don't want to implement your web server yourself for production websites. So I definitely discourage that.

And if yes, why are frameworks chosen by most ruby web developers?

The pros

Frameworks serve the purpose of making your development fast. If you have deadlines, you don't want to deal with low level stuff and you'd love a framework build -blog command that manages as many boring things for you as you can and let you focus on the real application design.

Frameworks are usually open source and have big communities which helps in making the framework better quickly. You can easily understand that a bug in code seen by 10.000 pair of eyes is found 10.000 times faster than code you write for yourself.

The cons

Some frameworks might be too big for your needs and other might be too small. In the Ruby context there's the huge Rails and its little brother Sinatra. One is huge and the other is very small and really gets out of your way. Sometimes you want something in between.

Frameworks are usually very generic. This means that you have to configure things that seems obvious for your context.

Frameworks contain more code than you need. This is a fact that you can deduce by yourself. This usually means more complexity and directly more bugs (even though this is compensated for by the huge community around them).

Are there any potential disadvantages in using a Ruby framework other than Rails?

You can still use gems in all of the frameworks you mentioned, so a ton of stuff is reusable. Want to swap in a new ORM, no problems. Want a fancy shmacy syntax highlighting, no problems. Rails has been making a huge push to move away from the old plugin model to use gems exclusively.

If one of the other frameworks fits your needs better use it. Keep in mind that when it comes to documentation and samples rails has more.

If I was learning Ruby and wanted to try out a web framework I would probably go with Rails not because its better, but because its got much better tooling and documentation.

Tools for someone with low programming experience to create a simple CRUD Web-application?

I have yet to use it, but the http://www.force.com/ platform (which salesforce.com is built upon I guess) is supposed to make it easy to develop data driven apps for more like business analyst roles. There is a cost to host it, but one app isn't that much on a monthly basis and the 30 day free trial would let you figure out if it worked for you or not.

Using Rails as a framework for a large website

Not the speed and scaling discussion again?

In webdevelopment the things that are the slowest is the network communication (receiving the request, getting al your data back), the database (getting all your data from the database), and most of the times it is not about the computation time at all.

While it is true that Ruby and Ruby on Rails seem more focused on programmer happiness, I think that every decent web-application built in .NET or Java has as many levels of abstraction.

The complexity of the environment? I think you mean deploying? There are a lot of options, but the most used options are Passenger (very easy deployment on top of an apache or nginx), or Torquebox.
Torquebox for the moment is the fastest, best scaling solution (based on JBoss Application server), and several big names in the Ruby community are calling Jruby the implementation of choise to deploy your applications. While AFAIK the commonest deploy still is using REE (Ruby Enterprise Edition) and Passenger.

Unless you know you are going to have to do serious mathematical, cpu-intensive operations, I think the question you should ask yourself is: which framework/language will give me the quickest result?

If you are very proficient in Java/Spring, that might be the answer for you. But if your only worry is performance in general, I would say: do not hesitate and go for Ruby on Rails. It is a pure joy to develop in. The ruby community is really awesome if you would encounter any issues: support is just a post away.

And to conclude, I want to add a few very big sites using Rails: LinkedIn is using rails (and jruby), and Twitter still is using Rails for their frontend.

The dangers of using ExtJS on a big project with RoR?

I currently have an extremely large, desktop style app written in ExtJS. It used to run on top of Perl's Catalyst MVC framework, but once the entire View layer was converted to an ExtJS based desktop I started migrating to Ruby on Rails models and controllers. It is equally as fast, if not faster, and easier to maintain and has a much smaller code base.

Make sure that you set your active record config to not include the root name of the model in the json, so that Ext's JsonStore has no problem reading the records. There is an option on ActiveRecord BASE called include_root_in_json you have to set to false.
Make sure that you properly define your Application classes in Ext and maximize code re-use and you are going to want some sort of method to clean up unused nodes in the DOM. Javascript performance can be a real pain unless you are using the latest versions of Safari or Firefox 3.1.
You probably will want some sort of caching method for data on the server to be served to your application in JSON format at the time the page is loaded. This will cut down on the number of round trips via Ajax.
Definitely make use of Ext's WindowManager and StoreManager objects, or roll your own from Ext.util.MixedCollection
Develop your code in separate, managable files, then have a build process which combines them into a single file, and then run YUI's compressor or Dean Edwards Packer on it to compress / obfuscate the file. Serve all JS and CSS in their own single files, including the Ext supplied ones.

Pitfalls in using Silverlight for a spreadsheet-type web application module?

You should know that Silverlight (version 3.0) does not support any printing whatsoever, which to me sounds like a whopper of a showstopper for you (sorry, I couldn't resist). The good news is that full printing support has been added in version 4, but that is still in beta. Rumours say it should be out before the summer if everything works out according to plan, so if that fits with your roadmap I would use SL4 right from the start.

There are no memory limitations in Silverlight, but for the local storage (IsolatedStorage) mechanism there is a default limit of 1MB. But you can easily get around that by asking the users permission to increase the local storage space when he/she starts up the application. More on that here: Silverlight Tip of the Day #20 – How to Increase your Isolated Storage Quota.

(Edit)
Aside from the missing printing functionality that will be fixed in SL4 I cannot see any problems with your scenario. I would easily take the Silverlight route if I were you, especially since you already have extensive knowledge of .NET/C#.