I give more points go to the highly respected Ruby on Rails framework for web applications. As I get deeper and deeper into channel development (using Java – yuck!) for our upcoming L****** portal, I have come to a realization. Java is a sandbox. To build an application, I could choose an infinite number of ways to achieve the same result. This isn’t just limited to the application logic created to achieve a result. Infinity also applies to the architecture of the application. I could use OO, or procedural programming. I could use direct database queries, or use an Object Relation Mapping (ORM). I could use the Model, View, Controller architecture, or something arbitrary. In short, there is so little direction in the Java language, that it is very easy to reinvent the wheel. Often not for the better.
Software has continuously been evolving for the better half of a century. Better designs continuously replace older designs incorporating lessons learned. Newer designs provide fail-safes against the pitfalls that all developers run into. So why look at Ruby on Rails to program something in Java? In short, a sandbox is a waste of time. While flexibility should never be underestimated (*cough* ASP.NET) , having structure is just smart. When you look at the structure for Rails, you are looking at the best minds in the industry, implementing the newest technologies (not the old dogs still pushing COBOL).
Why write verbose and repeated code for simple database operations? Rails doesn’t – it uses the ActiveRecord ORM. Java could leverage the same technology with solutions like ActiveObjects. (Not like Hibernate which breaks the mantra of “convention over configuration”).
Java could also make use of MVC design for routing and dispatching requests. L******’ code flow goes from a .class file, to an XSLT transformation request. Outside of XML data processing, this method is lacking. A better solution might be Struts, which mirrors some of the Rails functionality.
As I learn more about Rails, I end up applying more Rails conventions to Java.
Zone of Mr. Frosti 
First, I don’t know Ruby nor Java. Well, I’ve played with Java a little bit, and read enough about Ruby to know that I don’t see point of yet another object oriented language; you can stick your hand out and twenty of them will fall in.
That being said, I haven’t even bothered to read about Rails (directly). Call me old fashioned (or call me a programmer), but using a framework for the sake of using a framework makes no sense to me. Yeah, it gives you all kinds of whiz bang stuff “for free,” but in the end you are limited by it. For example, scalability. I’ve seen more than a few articles in the past months that lament Rails’ ability to scale. Here’s one I found via Google — http://shebanation.com/2007/04/14/frictionless-rails/ . There are a few more, with discussion, at slashdot. All frameworks add overhead to your application. That goes for Rails, .NET, etc. So, the same application written in vanilla Ruby has a much greater potential for running well under higher loads than one written in Ruby utilizing the Rails framework.
The only thing I’ve been able to deduce from the discussions I’ve read about Rails is that it promotes good programming practices. And I think most of that comes from the language. I’m not sure about that, though.
I guess what I am getting at, is that a programming language is _supposed_ to be a “sandbox.” A high level language such as Java, Ruby, or C is supposed to give you the power to write complicated programs in a human readable form. Frameworks are designed to take away all of the heavy lifting, but at the cost of your freedom and power.
Sorry to rant about Rails and frameworks here, but I had to get it out. Read http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html and replace “Java” with “frameworks” and the point remains true.
LikeLike
I like frameworks because of the speed of development. Remember that processing power is getting cheaper and faster, while the human mind’s ability to comprehend is staying the same (or diminishing). Frameworks naturally extend the nature of OOP’s idea of not reinventing the wheel.
Why would I write custom code to bind to a database and perform CRUD operations, or write a class to handle pagination? I could spend weeks working out all of the bugs and making the code stable, or I could leverage something that works instantly.
A framework vs. sandbox is analogous to using built in functions/modifiers vs. custom writing your own.
LikeLike
Faster development != better end result.
Yes, processing power is getting cheaper and faster. But does your computer really seem that much faster than your last? I’m pretty confident in guessing that it doesn’t. Why? Because of the mentality you just exhibited. Fledgling developers don’t have any concept of why they should care about small and efficient. So the programs they churn out are either based on 100s of megs of some framework, or written poorly without any real grasp of algorithm development. Thus, their programs run slowly no matter how much hardware you throw at them. Point being, just because you can afford new, faster, hardware every year doesn’t mean a program should be well planned, and optimized.
The previous paragraph should answer your questions about why you should write a database handler or pagination code. But I’ll elaborate anyway. In the case of the database interaction, I counter with why not? It really doesn’t take that long. Five minutes and you’ve got it out of the way, and written directly for your specific scenario/need. Using some generic framework abstraction, you have to mold your situation to the framework’s requirements. So you still spend time working out the details of how to interact with the database and if your scheme will work with the framework’s ideas. I don’t see how that saves much time.
As for pagination. A class? Oh please. Including white space, comments, templating, and a couple other things, the index page on my site is generated by 94 lines of code. I’m sure I could reduce that if I really felt like it. If you _did_ feel the need to write a class, then your point is still kinda off. The whole idea behind implementing the pagination stuff in a class is so you can reuse it later, and keep it abstracted from the main program. So, write the class once and then use it in 5000 other projects if you want. It’s still a cheaper solution than a framework.
Use frameworks if you want. I don’t really care. I just don’t think “omg it’s so much easier to use prewritten code!” to be a good way to go about programming.
LikeLike
On the contrary, with the way that Rails is designed, it’s fairly easy to scale Rails applications, it just works a little differently than your average web application built in ASP.NET or PHP or C, etc. Just look at the book by Ezra Zyg-somethingrather. Good stuff.
There’s no reason to use a framework for the sake of using a framework, of course, unless you’re simply evaluating it, etc; however, if the framework makes your life easier than it is a very poignant addition to your development environment.
Why is Rails a good thing? Well, the MVC design pattern is a great choice for building complex web applications. This particular framework has a very, very active community that is actively updating and fixing the framework, making it more and more friendly to use and develop with. Tools like Capistrano for deployment automation and various other tools specifically targeted for Rails web apps add a great deal to the value of Rails, as well as various plugins that make simple yet tedious tasks such as tagging amongst many various little things very easy. Plus, it’s written in Ruby, which is a supremely elegant language and completely object oriented, unlike C, PHP, etc.
If you’re aiming to produce a website written to handle millions of requests per second on the order of Amazon or Google, building your final product in Rails might be a mistake. But, what Rails allows you to do is to rapidly develop the concepts and design of your application and see it actually working. Then, if you need to optimize to support such massive quantities of traffic, you start afresh, pulling what you need from Rails (such as Routes, Caching, etc), and using each Rails component individually, such as ActiveRecord for database interaction, if you choose to do everything else on your own. What the Rails-built version provides you is a rudimentary base to work from and a good architectural design based on the MVC pattern to build your application from scratch if you can’t get Rails to scale as high as you’d like. (That is if you think you’re good enough to get your application to scale better than what Rails can do.)
Insofar as frameworks taking away freedom and power, this is not necessarily bad, but also I don’t think Rails does this to you. Specifically, you could just as well use whatever parts of Rails you want individually, again ActiveRecord being an obvious example, for whatever purposes you had. Rails just doesn’t limit you in developing web applications in practice, from my own experience. In fact, it really gets out of the way. To get started, really all you’d have to do is run the little startup script, modify the routes, and start working on the actual application code. Fairly simple if you ask me.
One of the cool things about Rails is that it, not taking away freedoms, but relieves the developer of a lot of the tedium of getting the database connectors written or setup, etc. Every bit of the files you work in in a Rails application is Ruby, giving you full freedom to fuck with whatever you want. Rails just provides a fairly consistent system to which you base your applications on. Consistency is one of its best design traits, making getting rolling on a new project very quick.
As far as what Joel wrote, he’s right: people that don’t think don’t make good programmers. The end. It has nothing to do with specifically with frameworks other than frameworks people who aren’t programmers even more capable of producing something tangible. (That’s not a bad thing.) It just saturates the community with more people asking the same, simple questions. Not always a bad thing. The Ruby community is pretty good about redirecting new users to the appropriate information, so this isn’t necessarily a bad thing.
So, in summary, you don’t lose anything by using Rails specifically (though there are a number of frameworks where this isn’t necessarily the case), especially not freedom or power, but gain a great deal of consistency, simplicity, etc. Also, using the framework doesn’t keep you from thinking, but it does allow those not necessarily expert programmers to futz around and get something usable.
LikeLike
But we’re not talking about simple 94-line long blog, we’re talking about applications, where encapsulation is an important design trait in an application or framework. In an application where pagination is used numerous times, you would want to encapsulate the code out into its own unit for the sake of reuse but also for the simplicity of testing and polishing each individual piece of functionality.
Just how well do you think your 94-line blog will perform in terms of scaling? Does it generate static files in order to prevent processor load? Cool, Rails does that, and if you have to have some specific section always dynamic, it allows you to cache just parts of the pages, etc.
Really, there’s very few reasons to not use Rails to handle all of the mundane details of building web applications for you. Hell, the more you use it, the easier it is to use, etc.
(Again, not talking about 94-line long blogs but real applications.)
LikeLike
Oh, and slower development doesn’t always mean a better end result.
The distinction for Rails is that it is focused on faster iterations of functionality; you get up and running with rudimentary functionality quicker and allows you to start making changes like a sculptor continually making cuts in a block of wood.
Plus, the benefit of using prewritten code is that it has been tested and known to work before, and in the case of Rails and other frameworks, it’s being actively developed by a whole community of developers, some of them actually being good at optimization et al and being able to resolve problems and spot issues much faster than writing everything from scratch each time.
LikeLike
I’ll keep this short.
1) You say to use the framework to reduce development time, but then you immediately say that you should start over from scratch after the application is written. That doesn’t save time, that adds unnecessary complexity. Plan the project and write it once.
2) My 94-line example was just that, an example of how _simple_ pagination is. I wasn’t promoting it as some sort of high traffic über important web application. But since you ask, yes, I think it would scale pretty damn well. And it does generate static content which is served from a cache. Which is, oh, two lines of code.
3) Also, an application is an application. It isn’t “real” because it is huge and used by thousands of people. So, I don’t appreciate the implied insult.
4) I know slower doesn’t mean better either. That was not the point. The point was that slapping some boards together and calling it the Biltmore doesn’t make it so.
Whereas you can only think of a few reasons not to use something like Rails, I can only think of a few reasons TO use something like Rails.
LikeLike
1) Starting over from scratch is not what I described: the biggest development time cost is figuring out everything that the application will do, how it will do it, and how all of the pieces fit together, etc. You know, how the application will actually work. Coding is a small part of the process. Going from something that will let you get functional very quickly to something specifically tuned sharing similar concepts and designs in the architecture means you definitely don’t start over, you just specialize your working idea into something that is production ready. Really, you don’t need to scrap rails to get production ready, but for something that serves millions of users each minute you might consider rewriting the application implementation in C or something similar. You don’t lose time by doing this; it’s just another step int he iterative process.
2) No doubt, pagination is super simple, and Rails has produced a fairly simple implementation. You could certainly get by with writing much less than 94 lines of code to get a functional blog running in Rails, much less, and would scale very well with very little changes (changing from operating in development environment to production, which is one line change in a config file).
3) But a blog is hardly an application that provides functionality and very dynamic qualities; there’s an enormous distinction between serving static content to consumers compared to letting the consumers produce their own content based on previous decisions and allow them to interact with the content. You really have to keep in mind what you’re making to determine your platform and environment: you wouldn’t buy an HPUX server to host your blog.
If you want super simplicity, go for it, roll your own shit that hundreds of thousands of people have already written: waste even more of your time. But if you’re conscientious about not rewriting already written code, and hell, if you’re conscientious about writing pretty code (for maintenance and sanity) then you would do well to choose a framework or stick with your own set of libraries or framework if you’re so motivated.
People write blogs in Rails to get familiar with the framework where they don’t have to figure out the application in the process. “Real”, in the sense I meant, was something more involved than, literally, nearly purely static content. (The only truly dynamic part would be allowing comments from users.)
4) That makes no sense at all.
The whole idea of using a framework is to not rewrite code and to have a community working on some of the most basic backbone functionality in most, if not all, web applications. I find working with a large community to continually polish and fix and improve to be a very good thing. That alone is nearly good enough reason not to seclude myself away from all of that and think that I can create all by myself something that is superior, and if that is the case, I might feel inclined to share my superior knowledge with a concerned community.
Just saying.
LikeLike
Not to sound like someone’s mother, but both of you have some very good arguments. James is right, frameworks are a lot of overhead, and applications like a blog probably don’t require such. But as Matt mentions, scalability, and maintainability is a big issue with larger applications and more functionality.
Lets take the least common denominator with which we are all somewhat familiar – the HUB’s website. I didn’t use a framework. The code all makes sense to me, but (1) its quite ugly, and (2) quite difficult to modify or extend by someone else. Had I used a framework like Rails, I could have saved a lot of time by not worrying about common operations like routing, database operations, and pagination (of which there is none). This would have left more time for me to work on the website itself, and not the backbone. Rails applications can only be written one way (arguably good or bad). Also, the conventions that people would learn by working on my code base are arbitrary to my thinking, instead of something applicable elsewhere.
James, you might have been scared off of frameworks by working with ASP (or similar) where there is a feeling of frustration. Rails is good about being there when you need it, but replacable when you don’t. (ex scaffolding)
My problems with Java extend outside of it being a sandbox. I hate strongly typed code where nothing is implicit, down to coversion of variable types. Screw that, its WAY to much micromanaging. As my final food for though, you might want to view the now infamous “Better Web Application Development” screencast by an ex-Java developer, Sean Kelly: (its really worth your time!)
LikeLike
I know one of the huge arguments the Rails core developers provide for the way Rails is designed is its convention over configuration idea. The idea is that if you just have something work in a consistent way, and most things behaving in a very consistent manner, you know what to expect from something you’re just coming upon for the first time. By convention, something works this way, and if you need to change it, you can, but if not, you don’t have to do anything.
That’s one of the stronger parts of Rails’ design.
LikeLike
It’s not that I’ve been scared away from them, it’s that I’ve never liked pre-generated code. Such code forces you to work to someone else’s style. I do not like that. Plus, I don’t like object oriented programming 9 times out of 10. I much prefer tried and true structured programming. When you get down to the nitty gritty, you won’t find very many object oriented based projects. As mentioned in the Joel article, if you don’t know C you won’t be working on the Linux kernel. And I don’t mean C++.
The HUB website, as I left it, was an organized mess. It wasn’t _bad_, but it could have been better. But I don’t think it was really that difficult to follow. There was just a lot of, “oh! can you add this?” stuff in there. (I.E. the staff scheduling portion.)
LikeLike
In my opinion, it really was bad. It was a nightmare.
By the way, OOP languages are just as tried and true as “structured” programming languages, or functional or procedural if that’s what you mean. C++ sucks, there’s no doubt about it, but Smalltalk has been around for ages and is very good, Objective C also rocks, Java is very good (depending on who you are and what you’re doing), Ruby is an exceptional OO scripting language, Python too, etc, etc, etc. What’s so tried and true about non-OOP languages compared to OOP languages?
Also, subjecting yourself to someone else’s style isn’t something that you’re unfamiliar with, I bet you. If you develop in PHP, you’re subjecting yourself to the core PHP library developer’s sense of design for each method parameter, etc. If you’re developing in ASP.NET (god help you) you’re subjecting youself to how the designers envisioned building web apps with controls and views, etc. Again, with PHP, you’re inflicted with having to wrap your code with those PHP tags. Heck, you subject youself to other people’s styles all of the time in every aspect of programming and development.
The point is, you get used to it, and you can learn a lot from those people’s styles and the thought they put into it. Using someone else’s style is very educational, and often can be more beneficial to your skill increase than you might first like to admit.
Reading through and using Rails has taught me a good deal about web application development and design. Good practices for large projects, etc. You might not think so, but Canvas is a very good product of the understanding that Rails gave me of good design for larger projects and its architecture. Blogs don’t really suit it, necessarily, but you could use it to build a blog. But what it makes easiest is structuring larger applications.
So, I guess I’m saying: I find that participating in other people’s styles from time to time, especially at least to try it, teaches me and reveals to me about programming and being better at it than not; I find that OOP languages are just as tried and true, absolutely, but I find moreso that I think moreso in terms of objects and structured, layered architectures like objects, etc; I find that we are always subjecting ourselves to others’ styles continually in our everyday programming anyhow, and that there’s no escaping it.
No reason to limit ourselves and alienate ourselves from new programming experiences. You really must try it before you can judge it.
LikeLike