Web Application Programming
Posted by Richard Sat, Sep 10 2005 00:03
There are many debates as to the best language and environment to develop in. Most of my primary development in the past 3 or so years has been in a J2EE environment. For the first several years developing in this environment, I thought it was a great environment and provided many of the necessary functions in the provided APIs. As I used it more and more, the limitations became more obvious.
Before J2EE
I had done all of my development using PHP, ColdFusion and some other products that I won't even mention here. ColdFusion and the other product were short lived because they required purchasing the server software. My PHP programming, at the time, was very ugly and I was mixing code and display logic. To say the least, it was difficult to maintain the code, but very quick to write.
Using J2EE
When I switched to using Java, the defined structure was welcomed. It was lacking the separation of display logic and business logic. The first couple of applications I wrote used Servlets and all of the display logic was in the Java code. I had looked at the JSPs, but they looked liked PHP all over again since you could write Java code in with your display logic.
During this time, I was searching for an alternative that separated display logic and business logic. Then I was involved in a large project that was going to be based heavily on XML. The use of XML led us to use XSLTs. There were considerable improvements in the speed of the transformations which included caching of the XSLTs. The application was successful and still in use today (fairly easy to maintain, after all, I did help write it).
I used a similar approach on a different project (XML and XSLT). This project went fairly well, but we didn't have nearly as much funding as the other project. With the lack of funding for a powerful server, there were a number of times I ran into server limitations. This Java application was written in a full J2EE stack and tended to hog a lot of memory. As memory usage increased, the CPU usage increased to deal with garbage collection and any swapping that was done by the OS. This was the first time I really started to question using Java for this type of application (we were talking 10-15 active sessions - probably not more than 5 requests/second maximum). I had wondered if it was written in PHP if it would have performed better and used less memory.
Looking for Something Better
While working on another side project at a slightly later time, I was introduced to the Smarty template system for PHP. This seemed to overcome the issues I had with PHP earlier since it separated display logic and business logic. Since I was coming from an environment that was very structured (business logic goes in EJB, parameter handling goes in the Servlets and display logic in the XSLT), PHP still seemed a little too undefined for me. Smarty handled the display part, but what was the best approach for capturing the model and controller parts (see MVC)?
Development was extremely fast with a dynamic language. No compiling. No deploying to a container. I just had to save the file and I was ready to roll. Since this was in a LAMP environment, this was an easy environment to setup and was readily available.
Improvements in Java
More recently, I have started developing Java applications using the Spring Framework with Hibernate to do the ORM (object/relational mapping). We are using JSTL with the Spring MVC. This combination kept Java code from being written within the JSPs. With Spring, much of the setup is in XML configuration files which filled a void that was lacking in J2EE/Java.
Since switching to Spring, I find my myself modifying and editing XML files to tweak the setup. There seems to be a number of places where values have to match up. This is getting easier as my usage increases, but I still have many opportunities where I am tracking down a problem in an XML configuration file. Even with Spring, I am still in a memory intensive situation for development and I must deploy the application to a container.
Combination of Structure and Quick Development
A few months ago, I went to a NFJS conference. I thought I was going to learn about some of the latest and greatest Java technologies. Instead, I was introduced to the Ruby On Rails framework. It was at this conference that my opinion of Java really shifted. We were introduced to a better representation of a object oriented programming language in Ruby where everything is an object - there are no primitive types. Rather than numerous configuration files, Rails[rr] favors convention over configuration. Rails also provide a very structured architecture following the MVC pattern. When actually developing, there is a Ruby web server that dynamically picks up the changes you make to files. No deploying! Rails has built in testing mechanisms to promote test-driven development(TDD).
Conclusion
Ruby On Rails appears to contain the right features for developing web applications. One of my complaints about Rails is the difficulty in getting the environment setup. For any type of production environment, it is recommended that you use a web server running Fastcgi. This means you must compile and install Fastcgi, the ruby-fcgi and any modules used to connect to the database. These are difficult sometimes and may require additional libraries to be installed. This seems somewhat painful coming from the Java arena where applications can run on a number of environments (of course, there are classpath issues that I won't go into).
PHP and Smarty seem like a good combination (the LAMP stack) since they are available a number of places. If a framework becomes available in PHP that is similar to Rails, it would definitely be worth looking at.
As for Java, I will continue to do most of my development in Java using the Spring/Hibernate stack. With this in mind, I think we will start to look at alternatives that allow us to become more effective/productive developers even if some do not think so.
