Alternatives To Applets On The Client Side?

Choron asks: "Anybody will agree that Java Appplets are great for developing complex applications for the client side, with good (but not perfect) portability. Now apart from Tcl/Tk or esoteric technology such as embedded Inferno or developing a plugin (so much for the portability), are there other solutions for developing both portable and advanced GUI applications embedded in a browser?" Currently, I think Java applets are the only way to do client-side applets with any degree of portability, but who is to say that this will always be the case. What may the future hold for applets, and will Java be the sole driving force behind the technology?

Comments

applets

[Tumbleweed]

It depends on what you want to do, but using Flash or Shockwave, you can do a _lot_. The pros and cons of those compared to Java make them an interesting choice for _some_ uses. It also depends on what platforms you have to support - they are hardly as portable as Java.

WebStart

[The Mayor]

First, I'd like to take issue with your comment about portability. Applets suck from a portability standpoint because Netscape has a stuffed implementation of the JVM. Use Sun's Java Plug-In. It works nice. And Java on almost every platform (even Mac, with MacOS X, but not yet BeOS) is pretty good. However...

Take a look at Sun's Java WebStart. It looks to be Sun's successor to applet technology.

The idea is basically to create a web-enabled application. It allows you to create full blown Java applications. Every time you run a WebStart application, it checks to see if there are updates for the .jar files on the web. If you're not connected, no problem--you just use the older .jar files. If you don't want to upgrade, find--you just click "no" when it asks you if you want the latest .jar files. Since the .jar files are cached locally, there's no horrendous download every time you run the application (as with applets). It's extremely easy to set up your application to be WebStart-enabled. And, I believe (but don't quote me on this one) that you can make your applets WebStart-enabled, too (adding caching to applets).

Re:WebStart

[The Mayor]

I just checked further into WebStart's capabilities for applets. Here it is, available from the developer's guide for WebStart:

The Applet-Desc Element
Java Web Start has support for launching Java Applets. This support provides easy migration of existing code to Java Web Start. An Applet is launched using the applet-desc element instead of the application-desc element. For example:

The JAR files that make up the Applet are described using the resources element as for applications. The documentBase must be provided explicitly since a JNLP file is not embedded in an HTML page. The rest of the attributes correspond to the respective HTML applet tag elements.

The main-class attribute is used instead of the code attribute. The main-class attribute is assigned the name of the Applet class (without the .class extension). This attribute can be omitted if the Applet class can be found from the Main-Class manifest entry in the main JAR file.

Note: Applets must be packaged in JAR files in order to work with Java Web Start.

I hope that helps. My original suspicions (that WebStart does support applets) is now confirmed.

Cheers!

What is the goal of your application?

[funkman]

This really drives which direction to go. Also - what is your target audience? If your audience is confined to (gasp!) IE 5. Then you will be amazed at what you can do with Javascript and how much control you have of the client - changing table cells on the fly/adding drop down boxes/etc. Of course this also works with Netscape 4+ but getting the syntax to work on both machines is not fun.

If your application is just presentation like where the data stands by itself (customize a {fill in the blank}) once it is launched - then Flash may be the way to go since all the data can be confined to the Flash applet. Flash can talk to the external world also in a worst case scenario - its just the degree of difficulty of programming goes up.

portable & advanced == 0

[geophile]

Sorry. JavaScript is portable. Flash, etc. are advanced.

You don't mention lightweight. On that count, only JavaScript qualifies.

JPython, etc

[babbage]

My understanding is that Java isn't the only language that can be run on the standard JVM that comes with most browsers. The best example of this is JPython -- an implementation of Python written for the Java virtual machine. I haven't used it, but my understanding is that it takes normal Python code and generates Java-esque bytecode from it that can be run on the JVM. There are also efforts underway to port Perl to the JVM, but I'm not sure what the status of that effort is (something for Perl 6.0? I'm not sure at the moment...).

You don't really make clear what you're trying to do or what your problem with the standard Java applet scheme is, so it's hard to be much more helpful than this. If you just want to make applets without using Java (I don't care for the language myself, as it happens) then something like this might help you. If on the other hand you want a more fundamental change, circumventing applets altogether, then it doesn't really matter what language you're writing them in. In that case, then some of the other suggestions (Flash, Quicktime, etc) may be more appropriate for you.

Flash5....

[ndfa]

As the last post mentions the new version of Flash5 with its actionscript is a good alternative. It does allow good control on UI and is much better now in doing sersious work. THe ability to use XML to get/send data to the server was pretty interesting when we looked at it back when it first camme out. A few things we found..... XML works very nicely to do most things (data in tables/other forms/reports) and was easy to setup on the client side. The client side is damn light and is pretty fast, not to mention it worked (we did not do anything TOO fancy, just the basics) on both Linux/Mac and windows. We did not do tooo much testing but it was nice..... the thing that caused problems was how the damn xml was being sent back.... i believe its content-type was NOT set to text/xml but rather application/x-www-form-urlencoded which caused way to many problems (hell i had to hack into JakartaTomcats code to get anything to work!)....... dont know if they have fixed this yet.
try it out and see if it fills your needs, its a bit pricy to get the developer licience, but actionscript is pretty nice with the new changes and most things work well. Damn developer env. is not avail. on linux (runs ok in vmware though!)

Re:Flash5....

[ndfa]

Its funny cause that was also one of the reason we gave to not go with flash (well apart form the fact that you could not recieve the xml using an app serverlike Tomcat!).... But as you noted, there is the ability to make a library and it would be interesting to see one that worked as well as Swing, cause then thre would be good reason to take a look at flash again!