There comes a time, for many Web sites, when the transition from static HTML to dynamic HTML has to be made. Whether it's a static company Web site that needs to become a dynamic online store, or a simple collection of family pictures that's become too large to manage with HTML alone, a decision has to be made to move to an environment that makes it easier to build and maintain the site. Deciding to use server-side programming to create your site on-the-fly can become the only option, but what language you decide to use can be a difficult and important decision.

Server-Side Options
Server-side programming options are plentiful. Each offers its own pros and cons, and each promises to be the best choice. Examples of languages used for dynamic Web site development include Perl, PHP, ASP (and .NET), ColdFusion, and Java. Factors, such as cost, can quickly drive you to one language. The cost could be in software licensing, server usage, or server management. Some of the options, like Perl and PHP, are distributed freely, which can have quite an influence over someone looking to step into the dynamic world. These two are also commonly found on most Web servers, further increasing their appeal. Java, which is also freely available, is also found on many servers. If you're just starting to get into dynamic Web site development, it's unlikely you'd have your own server and would rent or lease it from a hosting service provider instead. A quick Google search will show you that the number of hosting companies is amazingly high. What you'll also find, after checking out some of those companies, is that Web servers running Perl/PHP usually cost less then Java ones.

Java on the Server
The use of Java as a server-side programming language has increased during the past few years. The way Java is used has also changed dramatically. Applications are commonly written to use the most powerful and robust architectures available. From EJB-driven database access to XML based extraction, everything new and exciting in Java requires more configuration and coding. User interface architectures are also everywhere, allowing easy integration of the complex backend processing in Web page development. To an outsider, or someone new to Web development, Web applications written in Java can appear to be bloated, unmanageable, and a headache to be avoided. Most of what you read about Java is based on new technologies. Someone entering this world can be easily overwhelmed with all of the APIs, configuration options, and complexity that the Java community seems to embrace. This leads the new programmer away from Java and into the other options available like PHP.

Java Server Pages
Java Server Pages (JSP), like other scripting languages, contains a combination of HTML and code to be interpreted and executed by the server. In the case of JSP, the code is written in the Java programming language. JSP can also contain special tags that appear to be HTML but are really references to additional Java code to be executed by the server. These are known as tag libraries. Before JSP existed, Java servlets were used to write out HTML to the Web browser. This made it difficult to make simple changes to a page because the servlets contain many print statements to output the HTML code. Making changes to the servlets also required that they be compiled before getting deployed to the application server. JSP simplified this process by letting the developer work with a simple text document. The application server takes this document and generates and compiles a servlet. This is an important difference between Java and the other Web languages. Java code is compiled, while PHP, for example, is not.

Does this mean Java is faster than the other languages? The simple answer is yes, but the reality is that there are many factors that play to what makes one system faster than another. The way the code is written can have a major impact on the performance of the application. Other factors, like server performance, database performance, and other external bottlenecks are also influential.

Editors and IDEs
When working with JSP, you can use any kind of editor you like. Most Web developers wouldn't think twice about using a simple text editor to edit HTML or other languages like PHP or Perl, but when people think of Java they often think of an integrated development environment (IDE) like Eclipse, Sun's JavaStudio Creator, IBM's Rational Application Developer for WebSphere or BEA's WebLogic Workshop. If you're going to be developing a full-blown J2EE Web application, then an IDE would be the way to go. If you are just doing JSP development, then you can choose something simpler. It's often easier to use an IDE designed for the language you're working with because the IDE can add important development tools, such as code assistance or syntax checking. Although these features are desirable, they're not necessary. In the end, JSP developed in an IDE works the same as the code written in VI. Relying less on the tool can also help you be a better programmer because you'll learn from your mistakes instead of just having them corrected for you.

Web Architectures
The architecture of a system can determine how robust it will be. The architecture also determines how complicated it will be. For many people, Java application development brings to mind a three-tier architecture that separates the display logic, business logic, and data retrieval. The Model-View-Controller (MVC) architecture is a common example. A typical MVC design would include JSP for providing the user interface (view) to the client, and servlets (controllers) working between the JSP and the persistence layer (EJB, Hibernate, etc.) for data access (model) and application flow.

An MVC architecture is an ideal paradigm for larger enterprise applications. It lets different types of developers work on a system's components independently. It also provides much better scalability and maintainability, but it does introduce more overhead that can slow performance when compared to a simple two-tier architecture.

The two-tier architecture is, very simply, the code and the database. The code is a combination of display logic and business logic. Some people may argue that the Web browser is a third tier. The important point here is that the presentation and business layers be combined into one.

If you're just going to be working on a site for yourself for personal use, or even business use, the multi-tier architecture is more work than needed to handle the site. A two-tier architecture is commonly used in other languages and it can be easily implemented in JSP development. When evaluating the Web programming language options, Java is often thought of for large-scale sites while other languages like PHP are thought to be for smaller sites. JSP development can be done as quickly and easily as the others, often with better results.

Keeping It Simple
There's a time and place for every type of architecture. If that weren't true, we wouldn't have all of these architecture options available to us today.

The two-tier architecture is an excellent choice when putting together a family Web site, a personal hobby site, or even a small business site. In situations where one person is solely responsible for a site, it can be easier to build a site with just JSP. Even if there are a couple of people who will work on the site, it can still be done if they all have similar capabilities. With this architecture, the JSP contains all of the display logic, business logic, and database retrieval code. Anyone working on the site would need to understand all aspects of Web development.

Suggesting this type of development can be a source of argument. Many software engineers strive to develop applications using just the multi-tier paradigm. They argue that it offers easier development because components are separated, which also promotes component ownership and specialization in the developers. Componentized design also promotes reuse. It can also be argued that multi-tier architecture provides better scalability and maintainability. These are valid points, but there are opposing arguments to be made.