At this point in time, Rails is basically the reason I have a career, get paid, and provide for my family. Sure, any programmer could say that about any framework/language/platform they use regularly I suppose, but in fact Rails is the first platform I've been able to leverage to get great jobs and work with great people. Before that, various combinations of WordPress and homegrown PHP code were my bread-and-butter but I also did projects in Java, Python, and others. (I still shutter when I remember what I had to go through to work in Java...)
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.
I also owe much of my professional success to rails dhh and so many others in our community. Convention over configuration is still a revolutionary concept. Thank you!
Rails has also been successful by absorbing or beating competing frameworks in Ruby, inspiring a lot of other languages to come up with similar frameworks...
Javascript owes is a lot of its recent success to Rails. Backbone.js was seeded by the popularity of rails, which brought about Ember, Angular, and other JS MVC frameworks that are extremely popular today.
In the front-end world Sproutcore never made a huge splash and was not used by many companies outside of Apple. Sproutcore was frequenly blogged about and critically popular, but not used by a large amount of developers and companies in any way Backbone/Angular/Ember are... or even the way early versions of Rails were used.
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.
Fair enough, I remember it that way too. I was only looking to clarify what I read in your original post as indicating that backbone.js was the first one. I agree with you that it was the first highly popular framework.
Angular's history is also similarly older - it was created in a rough form in 2009 for data binding purposes. The creator used to work on Adobe Flex, so Angular probably owes much of its design from that.
>> any programmer could say that about any framework/language/platform they use regularly I suppose
True. I know lot of guys made killing with Wordpress, Drupal, Perl, Java. Networking, etc., Career success is nothing to with any particular technology.
I think it does. Some technology requires too much cost and opportunity to learn (SAP, and those costly IBM stuff). Some technology would never click with a person (I never click with J2EE despite being really proficient in Java, and I can't find the right way to work with Wordpress and version control).
I started learning Ruby for fun roughly 6 months before the first release of Rails. Although I rarely use Rails today (more because I rarely work on full-stack projects), it paved the way for a lot of the Ruby community today. That was a lucky coincidence, but I can draw a pretty direct line between Rails and me making a living off Ruby, running two conferences in the space and having met a lot of awesome people in the community.
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.
If you're interested in some of the milestones along the way and the context of web programming back in 2004 and 2005 when Rails came out, I made a timeline for my talk at RailsConf this year: http://www.recursion.org/looking-backward/
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's easy for people to bag on Rails because like anything, as time goes on things evolve and pain points are discovered, etc. But as someone old enough to remember writing Servlets + JSP + miles of XML configs, Rails was such a HUGE HUGE HUGE thing. I remember being so blown away by how fast and easy it was to stand up a new web app. We take that sort of thing for granted today but for those of us old enough to remember stuff like Spring and JEE 1.3, it was incredible.
how about session vs entity beans? or applets? java tried hard to be that magical framework, but always fell squarely on the wrong side of complicated.
I remember going to RubyConf 2004 in Reston. DHH was there talking about Rails. I was sitting there with like 30 other people listening to him and thinking "I dunno man, cgi.rb pretty much does the job for me". If I had been thinking straight I would have rewritten RubyForge in Rails and never looked back... oh well!
I wasn't at RubyConf 2004 (back then I thought Ruby was some weird Perl-ish language from Japan, not worth my attention) but for my RailsConf talk I dug up some old blog posts about what it was like when DDH first spoke about Rails at that conference.
Yeah I only was using it because I was working for Rich Kilmer at InfoEther. We were doing a DARPA gig and I wrote a thing in Java, and Rich said "no no rewrite all that in Ruby". A far-sighted fellow that Kilmer.
Wow, I'm now 38 and recall falling in love with Rails at the age of 28. I was battling with .NET WebForms at the time, Rails was a breath of fresh air. Martin Fowler got me into Ruby about 6 months before Rails popped up. I still write Ruby + Rails almost every day.
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 :)
This is something that, knowing at thing or two about OOP but not being a java pro at all, I've recently come to wonder about: why does Java use all this Factories of Factories ? I mean where does this coding pattern come from? What aspect of the language it represents? Is it because of multi inheritance? Why then in other multi inheritance OOP languages this doesn't happen as much as in Java ?
I don't pretend to know the answer to this, but I can share when I've been tempted to do such things in Java.
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...
I think the FactoryFactoryFactory-(anti)-pattern and bloated xml-configs are an enterprise thing, that by accident became a java thing (as java was adopted by people that were used to fighting with multi-kloc-c++ code-bases).
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).
> What java probably needed from the start was something like groovy
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."
I should perhaps have been a little more clear: I didn't mean to imply there were no scripting languages for java, just that they weren't first-class citizens of the platform (Beanshell being an exception -- but perhaps it too suffered from being a bit heavy?).
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.
I think this pattern was popularised in the Design Patterns book (Gama et al).
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!
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.)
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.)
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.
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.
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!
If you're interested in Rails, I transcribed an interview with DHH about many things, including Rails, which he had with Randal Schwartz on the FLOSS podcast:
"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."
It's pretty amazing how much influence Rails has had on web development, even in ecosystems other than Ruby.
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.
After a few years of Java and C# (especially in finance) I came really close to leaving the software industry altogether. Ruby, and then Rails, brought me back into it.
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.
This is such a key point. I launched a startup in 2003 that was successful, and did it for four years. But at the end of that project I knew that if I had to go back to using a LAMP stack, I was out of the web development industry. Learning Rails brought back my enthusiasm and love for programming.
Rails really hit a sweet spot. It has the right culture and organization to attempt to not go too far off into spaghetti-code land, yet it's also very much about getting things done in the real world rather than writing a bunch of boilerplate junk.
I started using it sometime in about 2005/6 and am still very happy with it.
They all appear to be following the same trend. It could just be that it's no longer the cool kid on the block. Plus the doc seems pretty good so many people go straight to it without google?
No absolute decline, but as I assume that the larger tech space has been growing, holding steady equates to an overall mindshare decline. Unless my understanding of Google Trends is off.
Heh, in 2005 I was in the audience at PUC - Porto Alegre at FISL and watched it live.. =)
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".
Rails is amazing. I wouldn't use anything else for prototyping my system. Baked-in best practices and easy-to-use, there hasn't been anything else that comes close imho.
As the IRFY creator, I freely admit that site needs some love.
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.
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.