With VisualWorks 5i, live browser based content finally arrives for Smalltalk. Smalltalk applets give developers a way to deliver dynamic applications to a web browser, whether it’s IE or Netscape. With VisualWorks 5i applets, there’s a whole new world for Smalltalk, and this document will explain why Smalltalk is a better choice than Java for delivering live browser applications.

First, what is the VisualWorks Smalltalk plug-in ?

Smalltalk or Java ?


 
 

Why is it better than Java ?

This severely limits what a Java applet can do; it’s the primary reason that Java applets have a very limited presence on the web. Intranet developers primarily avoid the browser, instead writing Java applications. In other words, one of the primary initial selling points for Java has been defeated by the limitations imposed on it. ActiveX components do not live with a sandbox; neither do other plugins. For this reason, Sun is now moving towards a digital signature based system. Even so, they are still very tied to the sandbox. A Java applet is completely at the mercy of the browser. If the browser crashes, the applet is taken down with it as it runs inside the browser’s address space. It’s very difficult to run disparate systems in the same address space; VisualWorks doesn’t do this. For this reason, VisualWorks is a lot more stable as an applet than is Java.

Smalltalk has five reserved words and an extremely simple syntax. A lot of companies are trying to transition legacy Cobol and VB developers into objects. Java erects two roadblocks to productivity and learning: Java applets not only must live within a sandbox, they must be constructed differently from java applications. This can mean extra maintenance for developers needing to create web based as well as client based versions. Smalltalk applets are constructed in exactly the same way as are Smalltalk applications – you don’t need to learn different rules based on the targeted platform. Java applets can really only communicate directly with the server that launched them. This limits the range of what they can do, and the range of enterprise capabilities they can access. A Smalltalk applet does not live with these restrictions, so the developer is free to communicate with all existing corporate resources using whatever existing messaging infrastructure is in place. The Java applet simply cannot do this in a straightforward way. VisualWorks applications are ported via a binary FTP; Java applets (and applications) are ported by tweaking across multiple JDK releases and multiple vendor VM’s. Since Cincom controls the Smalltalk VM, the porting cost aproaches zero. In any large system, the performance of an application will require tuning of the memory management system. In a standard JVM, a developer has access only to the minimum and maximum memory sizes; they cannot specify the sizes of the various VM memory zones; nor can they specify the garbage collection policy. The VisualWorks developer has complete control of the sizes of all VM memory zones, as well as the policy of the GC system. The difference between a highly performing server and a poorly performing system is the tuning of these parameters. If a developer cannot modify these parameters, then it becomes very difficult to ensure optimal performance. Sun is still trying to mature the various JDK libraries, and is constantly trying to churn out new ones. There are many inconsistencies in these libraries, and Sun’s desire to create a ‘whole’ platform has driven them to favor creation of new code rather than the maturation of existing code. Given this, Java developers must not only build an application, they must work around various immature aspects of the JDK. VisualWorks Smalltalk developers do not have a perfect system, but they do have one that has seen close to twenty years of maturation; the core libraries are stable, mature, and field tested. The Smalltalk developer has far more time to focus on application development as a result.
 
 

In Summary: Here’s Why Smalltalk is a better choice than Java !

Please send comments to:  James A. Robertson