I don't think a "JBE" would be the right way to go - why clooning all the features of flash instead of using flash?!
Java allows to create fully-featured applications inside a browser and that is what its used for. If you want blinking stuff with alpha-chanels but almost no functionality use flash. OpenLaszlo shows how "great" it works...

I think, one thing that makes the flash successful is the presence of the Flash IDE. This tool made Flash developers create flash multimedia easily. IMO, if Java enhance its multimedia capability and provide a drag-and-drop tool like that of Flash to create multimedia, applets will be seen again scattered on the web.

It's still in a com.sun.* package.

That's the killer, IMHO.

This (well characterised) delay at startup is certainly one of the problems.

This (well characterised) delay at startup is certainly one of the problems.

That 's problem. Otherwise it's good. Look at PointCast.com which is Swing based as ex. .V

Applets take too long to load, and the plugin freezes the browser for 10-20 seconds. Simply unacceptable. For me this is the main reason to avoid applets. Please solve this problem, learn from Flash plugin, and applets will gain popularity.

The main problem preventing use of applets in my current application is that applets don't respect the z-index. The applet is always on top of other elements. My site uses drop down DHTML menus. When we tried to use applets the menu goes behind the applet no matter the z-index setting. Applets should play nicely with other things on the page. ActiveX seems to have the same problem. Flash is the only thing that I have found that uses the z-index.

either use an application that requires a browser *only* or use a web started Java application clearly indicating that Java is required on the client first (with a "get Java" button nearby). Applets would have worked better if all major browser vendors would have included the Plug-In more consequently. As IE dominates the browser space and does require to install Java before applets work, a developer can build Swing apps without the requirement to run inside a browser right away.

Applets have failed because they are resource hogs, and because it takes too much time to download the JRE. I am a Java programmer, yet I'm not happy when I find a page that uses applets, because there is a quite noticeable lag (even if I already have a java IDE up and I'm using Java 5), and because the java runtime will stay loaded and suck memory even when I left the pages using applets. I keep an eye on the system tray, if the java icon appears, I close all of the firefox windows and restart it, otherwise I keep the browser open all the day...

One thing to add, The webstart application loader really needs to be made more attractive. Your average user expects top notch appearance because, like it or not, it's integral to the web experience and important factor that contributes to trust. Make that horribly ugly webstart click path simpler and more attractive, and I'll feel a lot better about integrating it on a page.

Even with broadband nowadays, users that don't have the JRE have to wait a while for the download to occur. Quite a few users would simply close your page rather than waiting a few minutes for a plugin to download. So if you were building, say, an online shop you have already lost a certain percentage of users just for using applets in your pages.

I switched from IE on XP to Firefox on Suse mainly because I was so frustrated with the instability and memory consumption of Java on Windows. Little did I know then, it wasn't a MS conspiracy that Java wasn't working well, SOME of the problem was that the Java community failed to provide a sleek Java plugin. I've now run Java on OSX which PROVED Java can preform as well as any native code. On Windows we know Java stinks because MS won't allow it to be optimized. But what's the excuse for Linux and Firefox!?!? I now use Firefox on Suse with Java NOT enabled for one reason - when Java is enabled the browser becomes unresponsive with 15 Firefox tabs/windows open. With Java turned off I can go higher than 30! And that's without any actual Java apps running! That's just for the plugin to exist. Even stand alone Swing apps perform almost as poorly on Linux as they do on Windows - and sadly they are even more out of tune with native widgets in KDE/Gnome. Pathetic. I once tried to run JBoss and the JBoss console applet on the same machine - huge mistake. JBoss sucked up 400Mb and the console applet sucked up a whopping 350Mb. Enough to overwhelm the memory and swap of any average PC. After trying to open another Firefox window I actually CRASHED my Suse Desktop for the first time. Imagine my embarrassment and shame at the irony that after switching to Linux FOR BETTER JAVA SUPPORT it was Java itself that brought my Linux box to it's knees. You know that when a simple little console program uses almost as much memory as a massive application server hosting over 30 services that something in the plugin architecture has gone foul. While still a Java zealot I now exclusively write server side Java and keep my clients Java-free (unless on OSX). There is no excuse for this. Sun, IBM, Oracle, et al need to wake up and fix this mess before we all switch to dot-net. As it stands today, I (as big a Java fan as can be) would be more inclined to try writing a client using Mono or SWT than trying out Mustang's Swing. It's just sad. Pathetic and sad. John J Yates

Take this quote for example: Critically, the new Web Client will enable PROIV developers, independent software vendors (ISVs) and enterprises to deploy applications over an intranet or ASP, more rapidly than JavaSuite. Alicia Aldis, UK Managing Director, PROIV, says: "The main criticism of Java is that it is very slow. PROIV has never suffered from such drawbacks, and we carried this philosophy forward when developing our Web Client. Web integration is now easier than ever before for enterprises, developers and ISVs." Note the careful use of the phrase "the main criticism". The development Java version of the client was actually significantly faster than the C++ version. All that's left is deployment.

At the time the applets were available the tools were not up to par to allow for widespread use. The compatability issues between the Sun JVM and the Microsoft JVM. The long load times. It saddens me to see Flash so promenant, there is no reason today, why an applet cannot provide the same functionality.

Applets when they came out were pretty much useful only for developers and those who fascinated 'something new'. This was not even 10% of the market as Sun would have expected to cover. Comes in broadband, excellent time to spread Applet mania, but alas also comes in Microsoft, with more than 94% of browser and 80% of OS market, also with a softcorner for Sun. also with not fully compatible jvm 1.1, lawsuits blah blah etc..... making sure the Applet user percentage remain static if not worse. Then there were other reasons like "fairly complex security cert creation and deployment" and of course that humongous size of new jvms.... 15MB!! that alone wud make me not want to install a PLUGIN that big, and then wait for it to show me something like "hello user , do u like my applet?? i am a java newbie hee hee" !!! That said... personally I find applets very useful. I have made really cool applets (like remote desktop using tightVNC behind proxy and firewalls) and continue to use them. And oh....if anybody is noticing.... there seems to be growth in number of applets for . again?!! ... hmmm ... or maybe its just a figment of my own imagination! ;)

IMHO applets earned a bad reputation for two main reasons: 1) When the first big size applets appeared, bandwidth still was an issue: it took ages to download them. And they sometimes did not work as expected (not to say they were buggy :-)) because we all lacked experience at that time 2) Ordinary users often had/have problems with terminology: "Java" got mixed up with "JavaScript" and security concerns of the latter where (incorrectly, of course) applied to Java as well. This often led to the (sad) advice of disabling Java in the browser. Besides these two points, deployment has always been an issue. What happens if not Java runtime is on the target system? The same applies to Web Start, of ourse. I think Sun needs to provide some sort of unified installation process for runtime environments. What I have in mind is a download page at java.com which can be passed arguments that define what virtual machine is needed by a program. This downloadpage should try to determine if Java is already installed and otherwise install the runtime. After download and installation is complete it should redirect the user to the original page so he can then use/download the program that needs the vm.

New comments go at the end. The page after a successful post should show you your post in context. Otherwise you wouldn't see so many dups.

Applets are not interesting because they are treated the same as plugins, i.e. a square in the page in a separate world from the rest of the real web application. If instead applets gave you full access to the DOM of the page like JavaScript has you could write some very interesting applets that would crush existing AJAX applications like bugs. This would also solve the UI problem that applets have and make them seemless with the rest of the page -- because they would just generate HTML...

Applets are not interesting because they are treated the same as plugins, i.e. a square in the page in a separate world from the rest of the real web application. If instead applets gave you full access to the DOM of the page like JavaScript has you could write some very interesting applets that would crush existing AJAX applications like bugs. This would also solve the UI problem that applets have and make them seemless with the rest of the page -- because they would just generate HTML...

Applets are not interesting because they are treated the same as plugins, i.e. a square in the page in a separate world from the rest of the real web application. If instead applets gave you full access to the DOM of the page like JavaScript has you could write some very interesting applets that would crush existing AJAX applications like bugs. This would also solve the UI problem that applets have and make them seemless with the rest of the page -- because they would just generate HTML...

The first thing I always notice with applets is that the fonts are unattractive. The same goes for Linux. Designers pay much attention to kerning and font face...because it makes a tremendous difference in how professional the UI looks.
The other thing about applets is that they rarely work...it's always some type of exception.

I am currently creating applets and the main-problems we have is:
* Slow initial loading time (for the jvm, not the applet-data). The java-cup animation made the whole thing a lot worse especially on slow computers.
* Stability problems: Because of the many components/programs working together broken setups are not that uncommon.
* The last problem is that many users have still old jvm's installed. Our applet is 1.1 compatible although all 1.1-jvms have a hard time working with such a large applet (~1000 classes).

A real problem is that static versioning WAS BROKEN in 1.5_u6, if a developer decides to restrict the jvm his applet should run on sun should not make this descision for him!

I admit it's difficult to actually secure applets behavior on the Internet. On the contrary, inside an intranet, it's possible to buid verry efficient distributed collaborative systems with applets on client side and servlets on server side.

Its amazing that a poll could even be created on this topic without a "10 sec browser lock/ugly grey box" option.

I don't believe that there is a compeling reason to build Applets anymore since we now have Java Webstart. Webstart makes the Applet obsolete since the Applet unfortunately must be contained within an ugly browser.

Much as I like the idea, and Java in general, applets are always slow (even if VM is warmed up and applet in cache) compared to the surrounding page. Most applets look bad, probably because the target community was programmers, not designers. And I get nothing for the trade-off: I just get a box in the middle of my web page that takes awhile to load, usually doesn't look good, and, most often, does one thing. What would make more sense is a very lightweight remote client stub that could be accessed reliably from JavaScript--a way to pull down just the client side of a web service, for example. That might be a good use for applets, who knows.

In my opinion the problems with Applets is that 1. difficult to build a good UI, because one needs to keep in mind that the applet could sometime form the majority of the bulk data transfered over the wire 2. Rather limiting from the browser perspective. The javascript <=> applet bi-directional communication is flaky, last time i tried something, it didnt quite work the same way on IE and Firefox.... which made me settle down with one-way communication javascript -> Java. 3. another limitation from the browser side, is that you can really resize the applet dynamically.. We always need to set a height and width.. This is something that is not often done with HTML content. 4. Packaging and deployment issues are faced by a lot of newbies.. The security restrictions can be circumvented by signing the jar file, but this information is one of the most frequently asked question... May be the documentation about Applets needs to be improved. 5. I guess at the end, the bigest issue is the applet to applet communication on the same page.... There is no clear cut definition of how it should / could be done. 6. Given that an applet is a singular unit, people are more comfortable working with Flash as it not only has a great UI builder but essential things like building polls / forms / animations are also provided for. Given the ease of building Flash documents, why would someone go through the pains of doing it as an applet? 7. The oncoming of AJAX has further cut down the need of applets in the majority of the web applications. Unless there is a specific need for a singular component that does a lot of things at the backend (like communicating with various servers / desktops), there is not much use of the Java Applets. Just my views. thanks, Rogue

MS's incompatible JRE and poor startup/load performance (i don't remember how many times firefox froze/crashed when loading an applet) are the killers. I'd still love to deploy apps (with UI written in matisse) as applets as much as JNLPs.

How simple it could be, Swing based applets as front end and Servlets as back end. I really hope Sun put more effort in solving the startup time problem.

Applets, no matter how small, no matter how beefy the machine always seems to take something like over 15-20 seconds to start doing anything. Presumably this is becaume the JVM takes this long to startup from a cold start. This is simply too long to expect a user to reasonably wait.

when microsoft withdrew support most of the browser ended up with incompatible jre ..

Make it so that people don't even know it's java. This is why Flash works so well.

Microsoft did a wonderful job of screwing up the Applet market. The Microsoft JVM was not 100% compatible with the Java standard. Hence, applets were either written to the Microsoft or the Java standard, but not both. The compatibility issue caused HUGE problems with corporate IT. A little misunderstood.
During Java infancy, OO and Java was misunderstood. Most Java applications looked more like bad structured programs. Added to the problem, novice developers were thrown into Applet development, and Applets had not gone through a refactoring. Applets from then on became the scourge of the Internet. I've seen great applets that are small and very effective. Better than AJAX, DHTML, or Flash. However it requires someone with knowledge of OO and Java.

DHTML is optimally integrated, has no start-up cost, doesn't slow down my computer, and looks better. java-browser-integration often sucks.

1. I would never, every write an applet for anything because browsers don't come with a JRE installed. It's that simple - no built in support. 2. After that, applets came across as cludgy because of their terrible startup time. It was like when you open a pdf file now - you sit there and groan to yourself, know the browser window is going to lock up. Perhaps they've fixed/helped with this, but then see point #1.

It's amazing to think that Java applets are a decade old. Why did they never catch on? I think the reasons are, in this order: 1. Most computers are sold without a JRE preinstalled. 2. Sun reached out to developers and not designers. 3. JRE is the wrong platform for applets. If Sun had stepped back and realized they needed a JBE (Java browser edition) which is more along the lines of SVG, Flash, Sparkle, without all the bulk of the JRE; things might be different. Let's face it, applets just need a runtime like Flash: high level visual/audio framework, XML/HTTP communication, and basic (preferably dynamic!) scripting. Flash is popular because it makes eye-candy easy, has a scripting language (JS), and is backed by a great IDE for *designers*. It's almost laughable the lead Sun had on Macromedia, and yet Flash is everywhere and Java applets are rare! 4. Applets need a declarative, preferably XML, UI description format. Doing everything by code is, well, dumb. 5. Sun allowed the name "Javascript" to be used by Netscape, permanently confusing the hell out of everyone in the dot.com boom that didn't deserve to being doing tech stuff because they couldn't understand the difference. (Which was, what, 99% of the people in tech during the dot.com boom?). This confused the hell out of everyone for a long time. The number of developers who have gotten callbacks on resumes and had to explain the difference probably numbers in the tens of thousands. 6. Few compelling demos, probably in large part because of #2 above; i.e. it's hard to build nice applet demos when the entire framework hasn't been thought out for building nice applets 7. Duke looked like a tooth. Just a tiny example of overall bad marketing. 8. If Java had been licensed like OpenSolaris is now, all the above 7 things wouldn't have made a damn bit of difference, and applets would be everywhere. In other words, the hundreds of thousands of open source developers would have contributed to make Java applets what they should have been, instead of praying for necessary tweaks every two years when a new version of the JVM escaped the lab. (Forget the current Mustang process too -- it's too little, too late.)

Java is slow and ugly to start up the first time. It's not silent and fast like Flash. It needs to stay out of the way of the user experience of the applet. And it just doesn't. And sometimes it gets worse. Not to say it's Sun's fault. I don't know. But in Firefox on my Mac, once an applet shows, it kills the use of my scroll wheel in Firefox until I restart the browser. So I've disabled applets there. And in Windows with VirusScan running, the first time starting up any particular VM grinds the machine to a halt for 20 seconds or so. So even the best case experience is less than ideal, and there are so many ugly quirks in the bad cases. I wouldn't dream of subjecting users to this kind of torture.

Java is slow and ugly to start up the first time. It's not silent and fast like Flash. It needs to stay out of the way of the user experience of the applet. And it just doesn't. And sometimes it gets worse. Not to say it's Sun's fault. I don't know. But in Firefox on my Mac, once an applet shows, it kills the use of my scroll wheel in Firefox until I restart the browser. So I've disabled applets there. And in Windows with VirusScan running, the first time starting up any particular VM grinds the machine to a halt for 20 seconds or so. So even the best case experience is less than ideal, and there are so many ugly quirks in the bad cases. I wouldn't dream of subjecting users to this kind of torture.