Hacker News Reader

Comment by pavlov | Hacker News Reader

In web frameworks, "MVC" has come to mean something quite different than what it originally meant in desktop GUI frameworks like Smalltalk and Cocoa.

Was Rails the first framework to use this interpretation of MVC? Or did it come from somewhere else?

View on HN

At the same time Rails came about there was also Nitro, another Ruby Web framework. It too used this form of MVC.

I much preferred Nitro to Rails for being more lightweight as well as more amenable to evolving from bare-bones PHP-style single-file Web apps to to large, robust sites. (It also had a notion of pipeline transformation of content that was quite slick.)

George Moschovitis, who created Nitro, ended up moving over to JavaScript. (https://github.com/gmosx/nitro)

The Ruby Nitro framework more or less morphed into Ramaze.

(For those curious about Ruby Web framework archaeology dig up a 2nd edition copy of Hal Fulton’s The Ruby Way (2006) and read the Web dev section. Caveat: I wrote the non-Rails parts of that section.)

Nitro and Og yo!

It came from Java, believe it or not: http://en.wikipedia.org/wiki/Model_2

Interesting, thanks.

It seems to me that, in that original design, the JSP servlet acting as a Controller was a multi-use object that would serve many requests?

To me, one of the weirdest things about Rails-style MVC is that a controller is reinstantiated for every request and then promptly thrown away. I'm used to thinking of controllers in desktop apps as rarely-destroyed objects which do a lot of communication with each other.

The Rails-style controller could just be called "RequestHandler" or something like that, IMO.

It's actually kind of funny when you tell Java/C++ guys about how each time PHP receives a request, fires everything up from scratch, does the work, and then throws it all away. A fresh start each time.

Jaw, meet floor.

What's even funnier is that in javaland they took advantage of long-lived objects by having deep and broad class hierarchies, with all code in instantiated objects ... which the PHP community emulated in their frameworks, instantiating a bazillion objects on every request just to throw them away immediately. IMHO it's no surprise that in the techempower benchmarks raw php is orders of magnitude faster than a symfony implementation.

From my investigations, a lot of the time symphony spends just using the classloader. i.e., it can't load dependencies fast enough.

Generally, Servlets were multi-use objects that would serve many requests simultaneously. Except that in the early days, you could tag a Servlet as a SingleThreadModel which would tell the container to only allow one request at a time to be served by an instance of the Servlet. Lots of requests led to lots of instantiations.

This was seen as a terrible practice, whose sole benefit was to allow lazy programmers to have state variables in their controllers, and was promptly deprecated. Only to have Rails and other similar frameworks basically pick it up!

No, Mojavi (PHP) used a similar style.

http://ad.hominem.org/log/2004/06/tutorial_on_mojavi.php

No, both Struts (Java) and Maypole (Perl) predate Rails.

ref: https://en.wikipedia.org/wiki/Struts | https://en.wikipedia.org/wiki/Maypole_framework | http://www.perl.com/pub/2004/04/15/maypole.html

I remember it was what introduced me to MVC. That and pog (php object generator).

Reply on news.ycombinator.com