Elsewhere on this web site, we present an ActiveX control that simulates
a rolling die, based on a sample application from Special Edition Using Visual C++ 4.2,
written by Kate Gregory. We
demonstrate how to make an ActiveX control work for both
Netscape and Explorer users, and show how to workaround some of the
problems involved in using a control for a Netscape user.
We also present the same rolling die written as a Java applet, and as an ATL
control from Special Edition Using
Visual C++ 5.0, also by Kate. That naturally leads to
a discussion: if there is a thingy, a gizmo, an
application of some sort that I want to write and embed
in my web pages, should I write it as an ActiveX control
or as a Java applet? If I am writing an ActiveX control,
should it be and MFC or ATL control? Here are the sizes,
in KB, for the dieroll:
| Component |
applet |
MFC control |
ATL control
ReleaseMinSize |
ATL Control
ReleaseMinDependencies |
| applet/control |
8 |
29
(cab: 14) |
45 |
52 |
| MFC dll cab |
|
700 |
|
|
| ATL DLL |
|
|
18 |
|
| Total |
8 |
729 |
63 |
52 |
Let's summarize the issues involved:
- Java applets cannot fire events and ActiveX
controls can. For some people, this will be the
only issue that matters.
- ActiveX controls built with MFC need about 700 K
of DLLs, which are already on the desktop of most
Windows 95 users, C++ developers, or users who
have downloaded any other ActiveX control. Users
without these DLLs will have to wait while they
download. Controls built with ATL are
substantially smaller but still much larger than
the equivalent Java applet.
- ActiveX controls are installed on the user's
machine and added to the Registry. This means
that the second time the user accesses a control,
there is no download time at all, it just starts
running. On the downside, users may resent having
their hard drives and Registries filled with
controls.
- Right now, only ActiveX controls can be
incorporated into Word, Visual Basic programs,
and other Windows applications. Later, when
applets are Beans, and Beans wrap OLE/ActiveX,
this won't be an issue any more.
- Java applets do not have the same licencing
support, or a distinction between runtime and
design time use, as ActiveX controls. That makes
it harder to retain exclusive use of your own
applets.
- Java applets are more cross-platform than ActiveX
controls today. There is no Unix ActiveX yet.
Netscape users need a plugin to use ActiveX
controls. Java applets work in Explorer and
Netscape, on Windows, Mac, and OS/2, and Unix.
- Java applets are sandboxed. To give one example,
they cannot open an image file from a site other
than the one where the applet came from.
- ActiveX controls run about 10 times faster than
the equivalent Java applet. In a little
demonstration like this, speed doesn't matter at
all. There may be circumstances where it does.
Keep in mind that all of these issues are temporary.
Whatever Java is missing, someone is working to add it.
Whatever ActiveX controls are missing, someone else is
working to add that. Within months some or all of these
issues will no longer be issues.
What about ease of learning? There are lots of
different scenarios here:
- If you already know C++, already own Visual C++,
and have some Windows programming experience,
you'll find writing an ActiveX control much
easier than learning Java.
- If you know Java, you can write ActiveX controls
in Java, but at first glance there appears to be
less Wizard and MFC support than there is for C++
developers.
- If you don't know C++, you may find learning Java
less work than learning C++. However many Java
courses assume you already know C++, so finding
Java training for non-C++ programmers can be a
job in itself. (The
Willcam Group, now known as CDI,
offers a two-day qualifying
course for non-C, non-C++ programmers to
enable them to take their Java for
C Programmers course. Full disclosure: Kate
Gregory is one of the instructors for Willcam's
Java curriculum.)
- If you're a Mac, Unix, or OS/2 user, you're going
to find a lot more Java tools than ActiveX tools
at the moment.
All in all, they both have advantages. The application
you are planning to build, the skill set you already
have, and the way you plan to distribute the thingy will
determine which to use. If you need events, you will have
to go with ActiveX. Java is better for the Internet and
for cross platform situations. On an intranet of Windows
machines, go with ActiveX, especially if you have control
over the users and can distribute the DLLs to them in
advance.
|