With JBuilder available to produce 100% pure Java applets, applications and JavaBeans, we should not forget that Delphi is also capable of producing interesting internet solutions with ActiveForms and Web Modules...

ActiveForms
Delphi 2.x could not produce ActiveX controls, not without a third-party tool that is. Delphi 3 fixed that with the so-called One-Step-ActiveX feature. At first sight, this was a wonderful feature of Delphi 3. However, more detailed exploration learned that you can only turn a component derived from TWinControl into an ActiveX control, and you cannot make an ActiveX control out of components that rely or connect to other components (such as the TTable and TQuery components that must connect to a TDataSource, or all the data-aware components, etc). In practice, this means that the wonderful One-Step-ActiveX feature is really lacking for serious internet applications.
Fortunately, we can work around this problem, by putting all components we need into one "container" and converting the container into one big ActiveX control. Of course, the best representation for this container would be a Form in itself (so we can just design it like we're used to), and the name for the entire ActiveX container hence turned out to be... an ActiveForm. ActiveForms can be treated like ordinary Forms in that they can contain any component, including a TTable, TDataSource, TDBGrid, TDBNavigator, etc. and they can fulfil the potential of ActiveX for Delphi programmers.
Like any ActiveX control, an ActiveForm needs a Win32 platform to be executed. But given this Win32 platform, an ActiveForm is just a regular ActiveX control, and can be used inside other ActiveX-supporting development environments such as C++Builder, Visual Basic, PowerBuilder, and also in Internet Explorer. The latter means we can use ActiveForms to distribute internet applications over the internet or intranet.
Compiling even a simply ActiveForm project can lead to an .OCX file of 300+ Kb, even when using only a few controls and a couple of lines of code. Compiling with packages, especially VCLx0 (standard) or VCLDBx0 (data and data-aware controls) can bring this size down to less than 50 Kb, while even an ActiveForm with some more functionality can be kept less than 100 Kb in size. Packages do add a lot of extra size (the VCLx0 package is more than a megabyte) but these only need to be deployed to a client once, and can even be pre-installed, whereas multiple ActiveForms (and multiple versions and revisions of ActiveForms) all benefit from the reduced code size and hence reduced download time.
Since an ActiveForm is just another Win32 application, even when run from Internet Explorer, a number of unexpected things can happen to unaware users. For one thing, the ActiveForm can access the entire machine, and if the user if logged on to a network, so is the ActiveForm. And - much like a virus - an ActiveForm can do just about anything to your machine (format harddisk? send e-mail messages? corrupt databases? anything you can imagine, and usually a lot more). Especially when downloading from the internet (and not from the internal company intranet), we should indeed treat an ActiveForm or any ActiveX control just like a potential virus. Authors of ActiveForms and ActiveX controls can use code signing, which only verifies that they are in fact the author, but still doesn't say anything about the control itself. Internet Explorer has some security settings that can be set to high (don't accept any non-code signed ActiveX control), medium (give a warning, but let the user decide) or low (accept all controls with no warning). Developers like us should use medium, but normal end-users should always use high [does this imply we're not normal? - Ed.]
Apart from the potential security problems, ActiveForms also require the BDE on the local (client) machine when using local databases and tables. Even if an Alias points to a database on a shared file server (on an intranet for example), the BDE is still needed on the client machine. Using MIDAS, consisting of TClientDataSets, DataSetProvider and Connection components, one can turn an ActiveForm into a multi-tier application where the database part is also on the web server (or even on a separate database server).
However, a more practical solution is to use ActiveForms only within a company's intranet, where we can control (and freely influence) the client machines and give them an Alias that can point to a database on a shared fileserver. This also means we can make sure every client machine has all required packages pre-installed, and we don't have to worry too much about security issues (within a company, I think it's safe to assume that ActiveForms developed by your own co-workers can be trusted, or at least won't do any harm on purpose).

Hence, I conclude by stating that Delphi ActiveForms are a great asset for a company's Intranet Solutions.

Bug Report: ActiveX Controls in Internet Explorer 4.0 (or higher)
According to Microsoft, "because of some architectural changes in Internet Explorer 4.0 (or higher) that were needed to support a wider range of controls more efficiently, some ActiveX Controls may not perform exactly as they did in Internet Explorer 3.0. A common cause of this is that the control was not created as Apartment Model Aware."
Delphi 4 solved this problem, and ActiveForms made with Delphi 4 (or higher) will support the Apartment threading model.