To do some justice to Java, it has served us well. Also, the problem domain that web applications nowsday has to deal with has grown. A whole lot larger than before, especially in the area of enterprise application, or distributed computing. So, in order to adapt to each particular types of problem, Java developers have evolved, and introduced, the standard frameworks to ease development on such problem space. This approach seemed reasonable, until we reached the point where the standard framework tries to be too generic, one-size-fit-all thing. The consequence from this is that, even when we want to create a rather simple application, we have to gone through the same kind of steps as those who create enterprise applications have to do.
But that's not the only problem. Because as the size of the (standard) framework grows larger, at the same time there are more giganic frameworks showing up here and there as well. So, at one point you'll start to wonder, "isn't there an easier approach of writing web apps, without all those complexities of the frameworks?".
So far, I've been dealing mostly with JSP and JSF. Before then, I have been fiddled with ASP when I was back in highschool. So far, I found JSP to be too low-level (in general sense, of course; if you have a good set of tag libraries, this issue probably isn't applied to you). It's so much like JSP gives you a brick, and you have to do all the rest, in order to build a house. JSF, on the other hand, is a component-based, event-driven framework, which is pretty much a ASP.NET WebForm counterpart, so thinking in terms of component speeds things up quite a bit. But, well, it's not a whole lot faster. Why?
The reason is that there're so many things to configure before you can get the app up and running. The usual suspect for things that gone wrong is one of those XML config files. For normal web app, you already have one XML (
web.xml). Then, if you decide to use JSF, and Hibernate, you'll have many more config files to deal with. And, to many people (including me), having more XML files in webapp, in inself, already introduces us yet another set of problems to deal with. A simple application that linked back to a database can take hours, or days to develop (and fix those inconsistency bugs), even when an idea about it is so simple.Then one day I learned about Ruby on Rails. It's a web framework based on OOP called Ruby (obviously). And, from looking at the video tutorial on the web, I must say that this is the step in the right direction. At least, for general purpose web site that does not need to be highly scalable, and follow the CRUD pattern. By having most of the scripts doing things for you, and writing less code, writing web app becomes less intimidating, and can actually be quite a fun experience. One implication of writing less code also means that there're less room for you (as developer) to make mistakes; it also means that code reviewing/debugging will not be so tiring anymore.
But does this mean that I'm gonna ditch Java (and other programming languages) for Ruby. Probably not. One thing is that the ease and power of Rails didn't come solely from the elegance of Ruby; to me, those strengths actually come from the Rails API itself. This is because Rails is created to solve a very specific set of problems. Instead of introducing a very abstract, general purpose API like other language (Java, .NET), where you can mix-and-match to create a variety kinds of problems, Rails simply gives developers a 'just enough' API to create a typical web app really quickly.
For the past few days I have heard yet another framework for java named Seam. It's a framework based on EJB3 and JSF, which makes JEE enterprise application a whole lot easier to create. But because, to my understanding, EJB3 isn't finalized yet, and there are currently only two (free) servers that supports JEE 5 (JBoss and Glassfish), I probably have to think more if I should go this route...
No comments:
Post a Comment