Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

Alternatives To Applets On The Client Side? 21

Posted by Cliff from the should-we-try-something-other-than-Java? dept.
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?
This discussion has been archived. No new comments can be posted.

Alternatives to Applets on the Client Side? More

Alternatives to Applets on the Client Side?

Comments Filter:
  • 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 (Score:3)

    by The Mayor ( 6048 ) on Monday January 22, 2001 @11:22PM (#488874)
    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 [sun.com]. 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 (Score:3)

    by The Mayor ( 6048 ) on Wednesday January 24, 2001 @12:36AM (#488875)
    I just checked further into WebStart's capabilities for applets. Here it is, available from the developer's guide for WebStart [sun.com]:

    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!
  • But Flash programs - at least the ones I encountered (e.g. the simulations for http://www.future-ceo.de/ if I remember correctly) were EXTREMELY slow. For example it was no problem for me to type (really used sentences and notes) faster than the computer was able to draw the characters. Heck, that machine (only 233MHz K6 but SCSI-monster) is fast enough for multi-track audio editing!

    The last time I remember a "speed" like that, was on my rusty 4.77MHz 8086 (later upgraded to Nec V30) using MS Word 5.0 in (Hercules) graphics mode...

  • Since you are going against a database and need formatted fields, going with a java Applet may be the way to go. You still can do formatting in Javascript - its just that you are reinventing the wheel doing so and praying the client can handle the Javascript without crashing.

    Personally, I would look into using a java Applet and use some EJBs for the data access and session management. Keep as much logic as possible out of the applet and keep it in the bean. You'll have the advanatage later on of possibly converting the Applet to a series of html pages and the business logic is still confined to the bean.

  • 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.

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

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

  • 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.



  • 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!)
  • 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!
  • You can do very impressive thinsg with QuickTime's wired sprite stuff, and it embeds in all browsers on Windows & MAc, and can be emailed about easily too.

    http://www.matthewpeterson.net [matthewpeterson.net] has some cool exmaples, including alarm clocks, drawing app and a chat app.
  • That's right, and I've used a trial copy to see what potientials it had. The fact is that its XML stream feature is very handy, but what bugs me is that using it would mean having to write any GUI component from scratch. Say I want to have a resizable table with scrollbars for instance, I believe it would take quite some time to develop it, when many GUi components are already available with Java's AWT or Swing. I haven't heard of any UI components library for Flash, but if there were one, that would greatly help. My other concern is the power of the ActionScript language. Apart from that, Flash animations do look really cool and quite fast too, no doubt about that.
  • WebStart kicks ass to provide easy access to applications/applets for end users, update features rock too ! However, on the requirement I have is that the application should run inside the browser (IE & Netscape), so that excludes WebStart, from what I know.
  • Well this is kind of right, but given the compatibility problems between browsers and the lack of advanced UI components (we're limited to the HTML form ones or hack some new ones, like those dynamic trees for instance), so I didn't pick Javascript as a solution to the problem. However, you're right that it's damn light, and the fact that it's interpreted also makes it much easier to debug.
  • Good point. The application should be useable from IE & Netscape, however we need a "advanced" UI components (formatted fields, ...) and be able to communicate with a remote database server. Javascript is nice, but it doesn't offer many UI components, and there are quite a few portability issues, as you pointed out. If only it was Python instead...
  • You're right, there are quite a few other languages available you can use to produce Java Bytecode, such as Scheme, Eiffel or Lisp (more here [tu-berlin.de]).
    However, having a VM run inside the browser (with the Java plugin or not), consumes much resources and the startup time is a little long (several seconds on even a decent computer).
    That's right, I don't really mind about what language to use, it could either be Python or Flash script, but it should be lightweigtht, portable and ideally should come with a bunch of standard "advanced" components (formatting fields, tables, trees,...).
    I know it's tough requirements, but there must be a damn product/project down here that meets them, isn't it ?
  • Thanks for the link, however I don't really see how you can create UIs easily with Quicktime, I guess it's the same problem as Flash, you have to make you own UI components (fields, tables, ...) by hand, which is kind of expensive in terms development time.
  • Completly right, WebStart supports applications and applets, however both run OUTSIDE the browser, I don't see any way to use it inside the browser, too bad.
  • Comment removed based on user account deletion

  • 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...).
    Larry Wall was asked about that when he spoke at the Cincinnati GNU/Linux Users Group [clug.org] last night. He pretty much rolled his eyes, shrugged, mentioned a masters candidate's thesis he'd just passed that had asserted that it would be very difficult to do, and went on to talk about a conversation he'd had with someone from Sun who'd admitted that part of the design goals included making it extremely difficult to port C to the JVM.

  • Depends entirely on the complexity of the vectors being drawn. If you've just got a few simple boxy widgets it will be quite fast, then it will be OK. I regularly use flash on my P166MMX and it's about the same speed as windows for well crafted Flash.

    ps. I hate flash.

    -- Eat your greens or I'll hit you!

Slashdot Top Deals

If a thing's worth doing, it is worth doing badly. -- G.K. Chesterton

Close