Today Rails turns 10 years old
github.com
github.com
I think the thing that was so amazing about Rails when it really got popular was that you could build almost any sort of web app you could imagine and everything would just make sense. The full-stack, the conventions, the fact it took much less time to get something working than its competitors...it was SO much easier to build stuff and stop reinventing the wheel.
I can't tell you how many times in the PHP world I had to figure out how to write code to send hand-tuned SQL to the server just to do basic stuff. Obviously, these days you can do cool framework-y full-stack stuff in PHP as well, but in many respects that was a response to the rise of Rails. (Actually, I must admit, I built a PHP 5 framework somewhat inspired by Rails before I jumped onboard the bandwagon...what prompted that was Zend announcing their PHP 5 framework, at which point I figured I'd either drop my framework and go with Zend or...just go with Rails, learn Ruby, and stop fighting it. I'm so thankful I decided to do just that!)
So thank you Ruby, and Rails on your 10-year birthday. You have made this programmer a happy man.
True. I know lot of guys made killing with Wordpress, Drupal, Perl, Java. Networking, etc., Career success is nothing to with any particular technology.
Ember existed before backbone.js by about 2-3 years under the name sproutcore.
http://en.wikipedia.org/wiki/Ember.js#History
Backbone.js's first release was in 2010.
Backbone.js was the starting point of the huge JS MVC community that exists today. Primarily due to it's simplicity and Rails-esque nature, where as Sproutcore was unwieldily and enterprise-software-esque until work on Ember started.
Rails had many early predecessors as well but Rails was the one that did it right, and spurred that style of framework's popularity.
Sorry for the earlier "well, actually." :)
Most people don't realize how ground-breaking Rails was back then. It basically went against the common assumption that long up-front setup is just part of the project. I seriously had people complaining that they couldn't bill as much on small projects if that became standard. The 15-minute blog might be a joke today, but back then, it was an awesome way of showing that Rails focused on making things quick to start (I don't like to say easy, it never was).
I am also surprised on how much of the general concepts from the 0.x versions survived. Sure, things have gotten bigger and parts got replaced, but the general structure is still the same.
Thanks for all the effort and love!
https://web.archive.org/web/20050403015716/http://www.rubyon...
It was fun to research all this stuff. It's interesting to see how far back some of this stuff goes. For example, Rails gets much of its power from Ruby's flexibility. Ruby is heavily inspired by Smalltalk. The first research version of Smalltalk came out in 1972! The MVC pattern was also first developed at PARC, back in 1978.
It fits in better with my thesis if it came out in 2004. ;-)
No doubts on that... get undercover again! quick! :)
Jamis Buck was there: http://weblog.jamisbuck.org/2004/10/2/rubyconf-day-two
Francis Hwang: http://fhwang.net/2004/10/03/RubyConf-2004-Day-2
It's amazing how few people were there and how marginal Ruby was in 2004.
Oddly, I'm starting to think Java might be the future of everything if it can shed it's huge_config.xml + FactoryFactoryFactory obsession, which I believe is happening :)
You know how fairly often when writing OO code you want to have an object that takes a bunch of optional inputs in its constructor? That's trivial in Ruby because you can just stick those in a hash, merge the defaults with that hash and you have your options. In Java that won't work because you don't have syntactic sugar for default arguments and the syntax for creating maps is... complex. So you naturally think you need one place to handle all of the complexity of constructing the object and then you think of the factory pattern and you apply it.
Imagine, though, that some of the objects you use in order to construct the object you now have a factory for also become similarly difficult to construct. You don't want your existing factory to know about the complexity of how to construct those, so one idea would naturally be to offload their construction to something else, which passes them into your original factory. It's not a huge leap to then figure out you can put this in another factory and now you have a factory of factories. Repeat.
I'm sure there are other reasons why, but for me that's the most common one. When I used to write a lot of Java, I used to often have to resist the temptation to do that.
I hope what I wrote makes at least a little bit of sense...
Another (related) java culture mis-feature is the tendency of "horizontal abstraction". Rather than building useful abstractions, there seems to be a tendency to move parameters from (initialization) code to xml to ini-files that generate xml to... All the while not really building up vertical abstractions where there sits something simple on top -- but rather just shifting the complexity "sideways" -- moving it around rather than collecting and simplifying.
I think part of this started before generics were introduced, as an artefact of java being a "compiled" language without any dynamic code-generation. So everyone ended up writing their own, strange, meta-programming language based on XML. Which can be fun as an exercise[1], but pretty poor in terms of tooling/ecosystem.
What java probably needed from the start was something like groovy -- and yes, my impression is that the ecosystem is becoming more sane.
BTW, java doesn't have multiple inheritance (well, it might have now that you can add some (static)code to interfaces[2]) -- it has (weak) contract based programming (via interfaces).
[1] http://www.amazon.com/Program-Generators-Java-Craig-Cleavela...
[2] http://docs.oracle.com/javase/tutorial/java/IandI/defaultmet...
Jython (then called JPython) came along fairly early, in 1997 and feature complete but never took off for testing or gluing Java code. Jacl, a Java version of Tcl, also came around 1997 but virtually no one used it. Beanshell was built before Groovy, removing static typing but keeping the rest of Java's syntax. Groovy duplicated Beanshell's use case but brought closures and terse collections syntax, but didn't get any significant users until the Grails project spent a year (2006) retrofitting it with a meta-object protocol so it could be used with Grails. A second growth spurt happened in 2009 when Groovy added a DSL syntax to its already klunky grammar so Gradle could use it. Though you could argue Groovy's use in Gradle builds isn't very significant because the build files are typically 20 to 50 lines long, using the DSL syntax only and not making any use of the actual Groovy language features. And Gradle may not use Groovy as a build language for much longer. Calling Groovy an "overhead in the IDE-to-Gradle communication", the recent Gradle 2.0 roadmap [1] says:
"Android Studio demonstrates the enormous potential of a deep integration between the IDE and Gradle. At the moment, the price we pay for this is often mediocre responsiveness: every time the IDE makes a query of Gradle, the configuration phase is run before an answer can be given. The folks at Google are implementing some smart workarounds for this. But what is ultimately needed is a fundamental solution within Gradle that eliminates the overhead in the IDE-to-Gradle communication."
[1] http://forums.gradle.org/gradle/topics/revolutionary_new_gra...
It's interesting that Gradle seem to be moving away from Groovy -- especially considering the section on configuration: It appear they're moving towards a functional-flavoured architecture -- and at the same time further specializing Gradle -- so that it'll (probably) be a better build tool -- but also quite useless for other tasks/customization. Or rather; it would appear the project will not be much of a driver in improving Groovy for projects that need some form of dynamic configuration etc.
On the other hand Gradle will (presumably) serve as nice architectural model to follow for other projects (move towards a functional style, rather than programming dependencies in a procedural manner with a hacked up xml dialect).
Perhaps one of the core issues have been projects mixing complex configuration requirements (eg: routing for tomcat) with simple requirements (eg: username/password etc -- stuff that works well in a ini-like format). I suppose that if you've determined you need complex/powerful configuration, you'd be hard-pressed to include a second form of configuration in your project. After all simple xml files are almost as readable and easy to work with as ini-files... And yet, for a lot of projects, it's ended up being a bit of a mess.
But my guess it's a natural progression from a standard Factory; Factories allow instantiation without specifying any type, and FactoryFactories afford the same flexibility, but just for instantiating a Factory without knowing it's type.
This was probably reenforced by the fact that life was easier if you built to interfaces rather than implementations, so factories were good for this.
I actually love the design patterns book, but I sometimes curse it - especially when stumbling upon things like the AbstractSingletonProxyFactoryBean. WTF!
http://docs.spring.io/spring/docs/2.5.x/api/org/springframew...
Show HN: Ruby on Rails (rubyonrails.org) 220 points by DHH 3 hours ago | flag | 312 comments
Was Rails the first framework to use this interpretation of MVC? Or did it come from somewhere else?
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.
Jaw, meet floor.
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!
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.)
ref: https://en.wikipedia.org/wiki/Struts | https://en.wikipedia.org/wiki/Maypole_framework | http://www.perl.com/pub/2004/04/15/maypole.html
http://www.transcribed-interview.com/dhh-rails-david-heineme...
"The architecture of Rails is that it's going to be full stack. Which means this is not going to be just one piece and then you have to go out shopping for another ten pieces to build an web application. I wanted something more... you have the entire box. With Rails today, just using Rails and nothing else, you can build an awesome application from the bottom up. That meant including the database, the templating, the MVC structure, bla-bla-bla. The core reason of why I wanted to do this was because I wanted all the pieces to fit together just as well as an integrated Apple stack. Apple products were definitely a leading inspiration for the design of this."
Personally I've found myself fighting Rails when trying to do things in it, but it is one of the tools I started out learning since the number and quality of tutorials out there seem vast. I too owe something to Rails for being of generally good quality.
They returned the joy and excitement I felt when I first got that ASCII eye to blink from the 250 lines of BASIC I typed in from the back of a magazine.
And I've never been happier as a developer.
That being said, I don't use Rails. I use Django, but we all owe a debt of gratitude for the path it illuminated.
I started using it sometime in about 2005/6 and am still very happy with it.
Sad to see it fading away. But to be honest ... I am not using it anymore.
http://www.google.com/trends/explore#q=ruby%20on%20rails%2C%...
It's just no hype any more, but at least for half a decade. So it's also no decline.
I asked DHH, "So where's the Brazilian Ruby community?" and he kinda mentioned it didn't exist yet. FISL back then was mostly python and java. Damn, it's almost 10 years since I moved to Brazil...
I don't know if it's just me being an old man, but every time I see people fighting with grunt / angular / ember I think of dhh and his "look at what I'm not doing".
Wait you said best practices built in :)
Also, technically, it's a Ruby benchmark. The Rails version is going to be locked to 3.1.3 for as long as possible. The benchmark does not reflect speed improvements in the Rails codebase.
Though, yes, Rails serves less requests per second than many other things: http://www.techempower.com/benchmarks/