As with everything, scriptlets have pros and cons. There are good reasons to take them into careful account, and as many excellent reasons to avoid them. It's up to you to decide time after time what to do. We can't hope to give an exhaustive coverage: our only goal is to provide you with some of the most evident features, whatever they are.
Undoubtedly, scriptlets are simple, and easy to write and maintain. The prerequisites are limited to a basic knowledge of the DHTML object model, and familiarity with a scripting language. This is not a strong constraint, and the same requirements hold true for any HTML developer. You have no need to learn complex, though powerful, programming languages. Above all, if you're already an expert scripter you have no need for further knowledge. You're already up and running!
Scriptlets may be used wherever ActiveX controls are accepted and also provide an efficient way to embed DHTML documents in your desktop applications. They're certainly small, often less than half the smallest ActiveX controls, but not as fast as binary executables. Scriptlets, however, are an excellent way to help you in transferring the graphical capabilities and metaphor of Web page metaphor to your applications, giving them a new, and richer, user interface.
Finally, due to the extreme simplicity of the scripts, you can also use scriptlets to prototype controls that you intend to develop further with other, more specific, tools, like the Microsoft Active Template Library (ATL). Assembling a scriptlet never takes long, so you can test ideas with the same ease you draft forms and dialogs with Visual Basic.
Because scriptlets allow you to define properties, methods and events exactly as ordinary ActiveX controls, it's easy for you to define and tune their public interface. Then, when you have finished, you certainly have a better understanding of the design required, and can start working in other environments that ensure better performance, or give you any other benefit you may need.
On the other hand, scriptlets are made of pure text and don't support code protection or licensing. They easily lend to undesired code inspection and modifications. More, development tools that really make programming scriptlets a snap are still to come.
In the previous paragraph we've given an overview of the main advantages and disadvantages of scriptlets. Now we'd like to go on in a bit more detail, trying to answer the questions that a developer might reasonably ask. The first one is certainly: "OK, I'm a Web developer used to writing JavaScript and/or VBScript code. Why do I need scriptlets?"
Not all developers really need scriptlets. However, it's not just Web developers that may need to take a closer look at them. scriptlets may also be of some use to Visual C++ and Visual Basic programmers. This is because of the features of the Active Desktop-enhanced shell of Windows 95 and the upcoming Windows 98. Both the new Windows desktop and the system folders have a WebBrowser control in the background. The WebBrowser itself has been improved to support PIDLs, that is, identifiers for the shell's namespace objects, files and folders included. Because of this, you can have HTML pages inside the desktop and the folders. The WebBrowser control, though, is the same as that used by IE4 and supports both DHTML and scriptlets.
This might not sound exciting at first, but it means you can write traditional applications much more easily and seamlessly by adopting and exploiting the Web interface. Your desktop program can be composed of DHTML pages, scripts, images, ActiveX controls, even without an executable module to put it all together. Not to mention what you could do in terms of Intranet facilities.
On the other hand, if you're developing Assembly code and are used to spending all your time squeezing even the last byte from the machine, well, it's quite unlikely you need to learn about scriptlets.
Before deciding, consider the following points.
You write scriptlets using script languages and have no need to know any other programming language. This is a really good thing if you aren't an expert programmer, but it is not even a primary and decisive reason for adopting or not adopting scriptlets. In fact, to give scriptlets a good and useful design you need to be a bit familiar with the basic concepts of object-oriented programming and hold some notions of software components internals. However, don't get this wrong: simplicity and ease are an advantage.
In addition, your entire cycle of editing, compiling and debugging takes a really short time to complete. Furthermore, in most cases it is all reduced to saving and refreshing the page by pressing F5. You have a text editor opened in a window and IE4 in the background. Edit the code, save, switch to another window, press F5, and voilŕ, les jeux son faits! Easier and faster than Visual Basic and Delphi too. Because of this, you can also seriously consider scriptlets for prototyping ActiveX controls.
For the very first time it is possible to write reusable HTML code. This is an aspect of primary importance in any large-scale Web-oriented project. Furthermore, this reusability is obtained in the best and most understandable way: by means of components. With scriptlets, you take advantage of all the power and the richness of the DHTML object model and shape components that logically extend the standard collection of objects offered. Scriptlets are a layer of code that hides the details of HTML and DHTML making it easier for you to develop your Web code.
Scriptlets can be used everywhere, both on Web pages and Windows folders. They are pure ASCII text, so you don't need sophisticated tools to maintain them. The intrinsic simplicity of the script code decreases the level of maintenance. Outside HTML documents, Scriplets require a specialized ActiveX control to be inserted, say, in Visual Basic forms.
What constitutes a certain advantage—that is, being composed of text and not binary code—is also a drawback, for at least a couple of reasons. First and foremost, performance! The browser needs to interpret them and this tends to slow down the execution time. Second, clear source code is dangerous from the perspective of reusable and distributable components. Anyone can spy on your code, be they authorized or not. But, putting aside this aspect of security, human readable code means that anyone can attempt to read the code and modify it, sometimes introducing errors.
Another key point is the accessibility of scriptlets from different browsers. This is a factor that might prejudice their wide market's acceptance.
Scriptlets have a double role: they are not only HTML pages but also software components. These two roles are a bit antithetical. While a Web document is made of pure text and must be coded as simply as possible, a software component is unreadable by construction. While a page is written to be duplicated, a software component is not! Being clear and readable means that someone can modify it too. Sometimes such updates might be unauthorized and even harmful to the code's robustness.
If scriptlets become a standard, then it will open up an entirely new market for developers. This scenario, however, poses a serious problem. How to safely license and distribute scriptlets while protecting and safeguarding both the users and the developers? When it come to this, I think, something will have to change. What about compiled and digitally signed scriptlets?
In addition, a scriptlet may contain references to a collection of files (video, images, sounds, controls, other scriptlets or HTML pages). At the moment, though, you have to rely on your own memory to keep track of the file names the scriptlet requires, and call a generic utility to create cabinets or ZIP files.
We will come back to all these topics later in the book. In particular, we'll be discussing packaging and distributing scriptlets in Chapter 14.
At the time of writing, another great point against scriptlets is their lack of transferability between different browsers. Unlike DHTML—which will become an accepted standard worldwide—for the moment scriptlets are Microsoft's technology and a feature specific to IE4. If you're writing Web-based software today, and want to take advantage of scriptlets, then you should be ready to renounce all the users that haven't upgraded yet to IE4. Netscape Navigator, Internet Explorer 3.x and even the preliminary versions of IE4, don't support scriptlets. Depending on how you write your scriptlets and the pages that actually host them, this may result in error messages. More often, however, scriptlets are simply ignored.
Developing multi-browser Web pages is not at all a trivial task. Scriptlets and DHTML are certainly the future—maybe the mid-term future—but I don't think they should be the immediate choice for everyone. This personal anecdote pretty well demonstrates what I'm saying.
I received an e-mail from a guy who attended one of the classes I regularly teach. He was asking me about the JavaScript's Image object which Internet Explorer's JScript didn't support until JScript 3.0, in the final release of IE4. I unsuccessfully suggested that he use DHTML and scriptlets to work around the specific problem, which was obtaining an animated button, not so different from the bitmapped anchor we've discussed above. To all my suggestions, he always replied "Yes, maybe you're right. But I want an audience as wide as possible, and want it now."
At the time of writing, there are no authoring tools that provide you with full support for scriptlets. You can use normal text editors and type in all the HTML code manually or rely on more specialized tools such as ActiveX Control Pad. Microsoft FrontPage 97 and FrontPad Express are of course insufficient to support DHTML and scriptlets. Microsoft FrontPage 98—the first product that supports DHTML— has been released recently, and the new Visual InterDev product provides something closer to the Visual Studios that C++ and VB programmers have access to.
We dedicated this paragraph to presenting and discuss the advantages and disadvantages of scriptlets. Perhaps, at this point, you're expecting a definite answer. Should we or should we not use scriptlets? Well, you ought to become familiar with scriptlets as soon as possible. However, this does not necessarily mean that you have to start writing them tomorrow. Scriptlets are a good solution and response to a precise requirement. They can grow and even eventually replace ActiveX controls, at least on Web pages. At the moment, there some points that need to be fixed, or improved, or simply fine-tuned. This will change and, judging from what we can see today, the answer to scriptlets is certainly positive.