HTML and/or Java?  Click on any item to view... Contents + Introduction + Concepts Product Positioning Comparison Matrix ScreenSurfing vs. ScreenScraping HTML Challenges HTML Advantages HTML and/or Java? + Operations + Customization + SurferScript Guide As you may have read, HTML as a delivery mechanism for 3270 or 5250 screens introduces a different user interface, which for some users can be describe as "incompatibilities". In general, most if not all of these incompatibilities are not present if the integrated browser language Java is used to deliver 3270/5250 screens. This is due to Java's ability to fully "paint" the user screen as well as have full control over the keyboard; these are both not possible with HTML, even with the latest versions of JavaScript. Why then, did Screensurfer originally deliver using HTML instead of a dedicated Java terminal emulation applet, which could format the screen identically to a standard screen and provide compatible keyboard mapping? (note that with Version 2 both of these incompatibilities have been significantly reduced, as Screensurfer V2.0 has HiFi HTML and the SSKeys keyboard re-mapping control). Screensurfer is not a "status-quo" solution When an organization implements new technology, it does so for any number of reasons which generally include: cost savings, increased productivity and competitive advantage. Screensurfer can provide all of these benefits, whereas a dedicated Java terminal emulator cannot. If a new tool or technology is to introduced, it will require new development, support and training for all involved; shouldn't the most be gained from such an effort? A dedicated Java terminal emulator, such as one provided by OpenConnect, can provide a quick and secure delivery of terminal emulation sessions to users at popular Web browsers. For existing users, where current network costs can be significantly reduced by switching from a VAN (value-added network) to the public Internet, a Java emulator may just be a "slam-dunk" in terms of justification as a replacement for the current emulator and network. But the Java solution doesn't integrate with the Web browser; it simply uses the browser as a fancy menu system and as a "host". Once launched, the Java applet continues in its own primary window frame, separated from the browser and its standard user interace; interconnection with other Web information sources and "back button" (built-in review) are both not available. In addition, the Java solution incurs a large download overhead the first or subsequent times it is initiated; this is not particularly well suited for "public" Internet access or even Extranet use. How much are you really improving applications? Enhancing existing Java solutions requires graphical user interface coding in Java, and all enhancements will execute at the client (fat client syndrome). This leads to a tendancy to simply leave the applications alone, and use the Java solution as simply another terminal emulator. This leaves the entire access to host applications "same as it ever was"; if you are implementing Web access to mainframe applications, an enhanced 3270/5250-to-HTML solution such as Screensurfer offers far more benefits over time, and provides a far better client approach particularly for tapping the huge opportunities in the ExtraNet and Internet realm.