The Java Boutique: Free Java Applets, Games, Programming Tutorials, and Downloads - Introduction to Java - Q and A Comparing Different Web Application Development Technologies

Articles : JavaBoutique's Introduction to Java : Q and A :

Comparing Different Web Application Development Technologies

Q

I was wondering if you had information or knew of a site that went into the advantages and disadvantages of developing a web based application in either:

Java
HTML/Javascript
VB OCX
DHTML
VFP Active Doc

Was not sure if this even existed without extensive drawn out research

A

I don't think that I have seen a site or a book that contains such a comparison explicitly, but I think I could have a go at it :)

For me, there are five main factors that I use to determine which language/technology to use for a web project. These factors include the following:

Browser/Platform Compatibility

What browsers do my target audience members use?
Will they be 100% Netscape, 100% Internet Explorer, or some other mix?
More specifically, which versions of the browsers are they using: 3x, 4x, 5x?
Finally, what platforms do they use for web surfing: Windows, Mac, UNIX?

The issue here is that there is no technology other than HTML 3.0 which you can reasonably depend on to work across all browsers/versions/platforms.

For example, if you use Java JDK 1.02 you can be pretty sure that you'll hit 98% of the web browsers in use today because even the 4x browsers support 1.02. However, if you use the 1.2 Java SWING classes, you will most likely alienate 90% of your clients unless you package the entire SWING library with your applets (and force them to download the beast).

Similarly, the decision to use client-side Active-X cuts out 75% of the market (users who have older versions of IE or use non-IE browsers)

To get a good idea of what the average user uses to surf the web, check out http://www.browserwatch.com

Thus, you must make an executive decision about where to draw the line in terms of least common denominator.

I cannot tell you what you should use because it always depends on the project and the project requirements, but I can tell you what my personal "general" rules in October 1999 are:

Java

I tend to use Java JDK 1.02 AWT for enterprise applications because no other interface technology provides the same quality of interface widgets while remaining dependably cross browser/version. I also like the threading and networking tools of Java.

I would not use JDK 1.2 SWING for anything other than Intranet applications. However, I think it is reasonable to use 1.1 event handling with 1.02 widget set and methods based on the statistics provided by browserwatch suggesting that 4.5 browsers make up over 80% of the market share.

HTML/JavaScript/dHTML

I use HTML 4.0 and classic window/image/form widget manipulating JavaScript without much hesitation. However, I do not use dHTML and the other JavaScripting tools that are not cross platform. In the rare case that I use dHTML for a project, I will always send out a browser specific version that is determined on the server-side.

I would never use VBScript for client-side scripting. However, I would always use VBScript for server-side ASP.

COM/CGI/Perl

Server side technologies don't depend on browsers or platforms. However, I would not use client-side COM (Active-X) ever. No reason to alienate Netscape users.

Speed of execution/delivery

how fast does the application need to be in terms of download time
and how fast does the application need to be in terms of screen to screen execution.

JAVA

Java is slow on delivery and fast on execution. Thus, it is crucial to make applets as light as possible. This is very possible with good coding practices. Be careful with compressing or archiving applications though because JAR, ZIP and CAB compression is not supported by all browsers. however, once the applet is downloaded, they run very quickly.

HTML/JavaScript/dHTML

This will be fast on delivery but slow on execution. Generally, every time the user needs to do something serious, they need to recontact the server to submit form data. client-side scripting can handle some things, but most of the time a web based app using HTMl forms will need to go back to the server three or four times in a session. As a result, the user must sit and wait on every submit button press.

ACTIVE-X

Like Java, this is slow on download and fast on execution. Unlike Java though, Active-X objects can be stored locally so that the user need only download them once. This, of course, is a security issue.

Development Time

How long do I have to develop this application.
Does it need to be delivered in one week or one month?

JAVA

Java is fairly fast to develop. Most of my large java projects come in under 1.5 months and small projects can be done in a couple of days. Java also has the benefit that it forces you to build object libraries so that by the end of several projects, you have a fairly decent set of tools that you can apply to the next project.

HTML/JavaScript/dHTML

Fairly fast as well, but often, you must develop multiple versions of the code for multiple browser bases...thus you write 3 apps for every one. Futsing with dHTML in particular can take days and days to get right. How the heck do I get that frame border to line up!!!! :)

ACTIVE-X

Fast and easy to build using Microsoft Visual Interdev!

NOTE FOR ALL

Just because you have finished your client-side code does not mean you are done. Don't forget that you have to have a Servlet, CGI, or ASP back-end to process the client-side stuff.

JAVA SERVLETS

Like applets, servlets can be built very quickly and the syntactical sugar of Java helps you create your own object library. Servlets are perhaps the best choice for enterprise-level apps because of the scalability, database connectivity, and business java beanifying ability they provide.

CGI

Perl CGI runs everywhere. It can be made to be as fast as Java or ASP when you use an embedded perl processor in the web server. It has a huge body of tools that you can use to develop apps such as www.extropia.com or www.perl.com. Perl/CGI is probably the fastest server-side technology to develop with but may not be the most scalable.

ASP/COM/JSP

ASP and COM can be fast to develop using Interdev, but I have found that most ASP developers write cruddy code with the IDEs and as a result spend a lot of time debugging. This will get better over time. I have not used Java Server Pages (JSP) but find the technology too proprietary.
PS: If you want to use COM and ASP you pretty much need an IIS web server which means that you throw security to the wind (imho).

Features

Is there a need for enterprise interface widgets and functionality? For example, does the application require a grid that can hold a million rows by a million columns with dynamic column sorting?
Does it require multi-threading?
Does it require network programming like manipulation of sockets?

JAVA

Java JDK 1.02 provides all the widgets I ever need....when you use a third party library like Microline or KLGroup.

HTML/JavaScript/dHTML

Very limited widget set when you concern yourself with cross platform development. In another year and a half or so when Microsoft wipes out Netscape's poorer implementation of the DOM, and a larger percentage of web surfers have moved to compatible browsers, I would consider dropping Java on the client side completely. But it is not yet time.

Remember that with corporate clients, if 90% of the market appears to be using 5x browsers, then the remaining 10% will be corporate users (your target audience) whose IT departments have not been able to upgrade (for lots of valid reasons).

ACTIVE-X

Awesome in terms of features. COM is a pleasure to use and opens up a massive library of tools for you to use. But this is only really useful for intranets and requires an IIS web server.

Maintainability

Is this application likely to evolve quickly over time?
Does my client have the ability to hire follow on contractors to continue development once I am gone
and what will the level of competence be in those future partners?
That is, if I write something too complex, can it be supported by someone else at a reasonable price?

JAVA

Java is fairly easy to maintain but it is costly to hire developers.

HTML/JavaScript/dHTML

Very hard to maintain even if you are using objectified GUIS like SSI. Small changes can make large impacts and there is no syntactical sugar to enforce good object oriented design. Code often turns into spaghetti very quickly.

ACTIVE-X

Similar to Java

CGI/PERL

When done right, this is very easy to maintain

ASP

Yuck. It will be another year before I see people writing good code on average. ASP lacks the structure that keeps programs well-designed.

Follow-up

Selena Sol contributes to the JavaBoutique's Introduction to Java. Selena curently works for Barclays Capital in London, one of the leading global investment banks in Europe and has worked as a software developer for the National Center for Human Genome research, Microline Software, Neuron Data, and Electric Eye in Singapore. Selena is perhaps best-known for creating the Public Domain Web Script Archive (Extropia) and writing several books on Web Programming (Perl, CGI, Java).
Email: selena@extropia.com

Applet Index
(sorted alphabetically)
A B C D E F G H I J K
L M N O P Q R S T U
V W X Y Z #s

The Java Source
(applets w/source code)
A B C D E F G H I J K
L M N O P Q R S T U
V W X Y Z

How to Add Java Applets to Your Site

New on the Java Boutique:

New Review:

Time Management Made Easy with the Quartz Enterprise Job Scheduler
Why not just use the Java timer API? This open source scheduling API boasts simplicity, ease-of-integration, a well-rounded feature set, and it's free!

New Applet:

Reverse Complement
Reverse Complement is a simple applet that converts DNA or RNA sequences into three useful formats.