Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
What's your opinion on whether one should write an application for a specific platform or use a cross platform approach and reach more potential clients?
It would be a GUI based application and I'm thinking of using Java.
Most of the applications that I've used built on Java don't run as smooth as the native applications on the respective platforms.
The two platforms I'm thinking of are windows and macs.
If I was creating the app just for my own use, and I had to choose one system, I would choose to focus on the mac.
I would like to hear your thoughts.
I would use Qt and yes, definitely target Cross Platform...
The major reason isn't in fact what you think it is (being cross platform by itself) but actually that by targeting multiple platforms your code by some freaking weird magical reasons tends to end up with far better code quality. I've seen this happen countless times in my own projects. Every time I add a new platform the quality of the code increases and the code becomes more clean...
Also every serious app should have as few "dependencies" as possible, being cross platform means you have less dependencies... ;)
Then as a "bonus" you get to your app to run on multiple platforms...
Requirements, requirements, requirements.
In all seriousness, "it depends" is the right answer.
Truly cross platform is hard work; Working where you/your users are familiar is worth something. Solving the problem in an effective manner is really the highest priority.
Cross platform development, in general, is a bit overrated as an artform. Java is the leading technology here, but even in this case, most Java programmers don't really go cross platform. There are a few spectacular examples of tools like Vuze and LimeWire and JRipper which work pretty well just about anywhere, but these are exceptions, statistically speaking. Most Java apps, especially of the corporate variety, are coded with one platform in mind, and they never really move around.
If you want to go Mac and Windows, consider spending time in the Limewire and Vuze codebase. Both of these apps work extremely well on both platforms.
You will definetly need two builds. One build probably won't do.
I suggest to develop it first for the platform you feel comfortable with, and where you can make use of all platform gimmicks; in this case, this would be OS X.
Later, if your app is successful for the Mac, look at porting options. It's IMO not worth to put effort into porting until it is certain that there would be significant interest in the app in the first place.
In this day and age, is there really a good reason to write native code?
Yes. The languages and libraries available do not allow excellent programming to be done well. At best they allow one to write code that works ok across platforms, but never excel.
Pick one and focus on it. Focus on that audience (you'll find the audiences are different in their tastes and desires anyway).
Once you've got an app people are clamoring for on the other side, and just before someone makes a competitor, evaluate the cost/benefit to porting your finely tuned and well designed product over.
If you try to 'serve two masters' you'll make design decisions based on what's easiest for both platforms, and that's not a good design process.
-Adam
If your app uses an MVC design, you can write portable model classes using C++, and native controller and view classes for each platform you want to support. That gives you the best of both worlds - portability where that's practical, and a native interface for which your users will thank you.
I agree with your observation about Java applications versus native applications, although I'm sure that an experienced Java programmer could probably make it work.
The bottom line is that the programming APIs for both Mac and Windows are the best tools to use for building interfaces on their respective systems. If you want your app to run smoothly on a particular system, you should use that system's API.
If it is absolutely essential to have a cross-platform implementation, consider writing all of the core functionality (non user-interface portion) for your program in a library that can be compiled for both systems (c++ is an obvious choice), and then build a nice user interface for each target system that can makes calls to the common library.
IMHO, this discussion should be answer by the customer needs.
Most of the time IT provide solution, the way the solution is build is only a detail for the customer.
However making the code reusable could be useful in case your first choice of development environment was wrong.
many other criteria may come into the thinking.
for instance if your software is for health care you may want to support for 10 years, then you have to select an OS supported for more than 10 years (forget windows and mac). etc.
Depends on how much time you wish to spend on the application. Fastest way is Java, otherwise you can build your model with C++ and do separate GUI code using MFC and Cocoa.
Why don't you consider Web Application.
You can build rich UI Web site running in browser which runs everywhere and all platforms,
If you are familiar with Java, you can try GWT for the 'Weblication'
Check out the demo page of GWT
Make it a web app ?
Otherwise Java i guess. It depends of many things, type of your app, target etc.
I have had good luck with cross platform Java using SWT. This will give you a nice native-look on any OS, and there aren't a whole lot of problems out there that require any JNI code. With any luck, you should be able to distribute the exact same codebase to both targets, and it should just work.
Having said that, you should evaluate whether or not you really need the cross platform functionality. At the very least, it will require you to test the GUI layer of your app on each OS (testing layouts, presentation, etc). With a large app, this becomes cumbersome very quickly.
In either case, choosing a cross-platform language from the start will give you flexibility in the future. If you were to write native code from the start, it would be non-trivial to port the code to another platform. It would likely be accompanied by several bugs, and would also require a port of all the test code to the new platform. You would run into synchronization issues with any new features, bug fixes, etc. With Java, you can write JUnit tests which will run in both OS's, and any bugs or new features will be propogated to both versions automatically.
It really does depend on your specific application. If you are anticipating a user base on both OS's, then that should dictate your language choice.
It is possible to get a nice looking Java app to run on Windows, Linux and Java - look at SBCommander for example - and note that you can run it and look at the UI even if you don't have the hardware that it's supposed to control.
On the other hand, one thing I've found very hard to do is to write a cross-platform app that looks and behaves like a native app on each platform; there are just too many different assumptions about how an application should behave.
It really depends on who your users will be. Don't go cross-platform just because you can. There needs to be a real need regardless of the tool. And testing is going to eat up quite a bit of time. You'll still need to thoroughly test on both platforms.
I use REALbasic to create a wide variety of cross-platform desktop applications from a single code base and it has worked well for me and my clients.
Quite often I find PC developers attempt to capitalize on the Mac market (some do successfully). In turn, they development the application in the described above "cross-platform" architecture (Java, or some Qt framework, etc...) The result is usually, a hideous looking application with poor OS integration support and the community backlash commences in the reviews.
My advice, port it. Do a good job, understand your market before dumping your cross-platform product in your carpet bomb marketing approach.
Related
I saw some other similar questions on this topic here but they were not very helpful so I a posing this question.
What is the fastest way to convert a reasonably sized, simple web app to a Java desk top based client targeted for pc and mac? Unfortunately I can not share a whole lot of details about the app here due to various reasons. The most complicated UI in the app though is a page that contains a multi level threaded discussions (please see here for an illustrative example of what I am talking about.) The current web app is based on python so I can not re use anything from the server side code (dont think this is an issue)
I have never done any swing or awt or any other Java based thick client GUI work. My thinking is more or less defined by web based applications. I am capable of doing end to end web app development (including backend and decent UI using HTML, CSS and JS) using Java or python. For your answers please focus on Java solutions only.
So here are my questions
What is the best framework or tool I should use? I found some of the following tools on the web as part of my research.
Awt - does not look like this is a good choice.
Swing which I believe is bundled with regular Java SDK/JRE. - This may be my best
bet.
SWT which seems to compliment Swing in some fashion.
Griffon based on an article here. This framework uses Groovy ( I
have no clue about Groovy, btw) Adobe Air flex. Any open source
frameworks?
What are some of the other issues that I need to keep in mind? Some that I would like your comments on are:
How does the fact that it needs to be deployed on the client complicates things? Since we are using Java, I believe this to be a non issue. I am aware of the usual trade offs between a web based app and a desktop app (e.g. ease of deployment and upgrades etc etc.)
How easy is it to create a one click installer and bundle the app and the environment needed - eg. JRE etc?
The product needs to work on Mac and Windows. Does that complicate things in any way (Again, since it is Java I am assuming there are no gotchas but would like to be forewarned if there are any)
What is the framework or technology that may be good to have on the resume as a skill set?
My deadline is a max of 2 months - would that be enough for a reasonably simple web app given that I need to learn all of these technologies? I am just trying to get a sense here - I know it is most likely impossible to give an accurate answer - just assume I am smart enough and can pick up any unfamiliar tech stack fast enough.
Thank you!
GUI toolkit
Given "Mac and Windows", I'd say that settles my recommendation as "Swing" (perhaps with SwingX1).
I agree with your assessment of AWT. It does not support formatted text in any component out-of-the-box. It also lacks trees, tables (and other components) & people with recent experience using it. Note though, that it is also "bundled with regular Java SDK/JRE" just like Swing, it is just that it is older and less enabled than Swing generally.
If anything complements Swing it would be SwingX. SwingX is built on Swing and provides advanced controls that are not available 'out of the box' in the J2SE.
Swing and SWT are mutually incompatible - use one or the other.
I have no experience with Griffon.
Swing is the most used of the options outlined, so for getting help (ignoring other potentially important factors in the decision), it would be a good choice.
Note 1) Add SwingX if they have any groovy components that present threaded conversations easily, but I suspect a JTextPane would suffice.
Deployment
As far as deployment goes, that is a little more tricky than it seems. Many desktop computers do not come with Java as standard. Those that already have it, might have an old version.
To ensure a JRE of the right minimum version to run the app. is available, use the deployJava.js (mentioned, with links, in the JWS page below).
To provide a 'one click' launch experience for the user, look to Java Web Start.
Cross-platform gotcha's
Unfortunately, though Java is x-plat, there are plenty of things that programmers can do that stuff that up. E.G.
Not accounting for the platform default:
File encoding (file.encoding2)
Line break (line.separator2)
File separator (file.separator2)
Coding fixed size ('absolute layout') apps. that will be shown as different sized apps. on other OS.
...
Note 2. That is showing the property to use for each.
Timetable
Obviously I cannot speak for you, but I can tell you that I would have had no chance of going from 'which technology' to a 'deployable app' within two months.
Hope you're more capable than me! ;)
You said that you wanted a Java solution, but be aware that there are plenty of Gui options in Python, and you already have your web application written in Python.
Groovy is a different programming language than Java, but Groovy runs on the JVM. Do you want a Java solution or a JVM solution? I ask because you mention Griffon.
Assuming you want Java, I think your main options are Swing, SWT, JavaFX 2, and Apache Pivot. Oracle has said that they intend for JavaFX to replace Swing as the GUI platform of choice. That said, JavaFX 2 is in its infancy, and only a preview release is available for Mac right now. The upshot of JavaFX and Apache Pivot is that you could use the same code for your web application as your desktop application.
You can try doing so in small steps:
* As a first step you can create an applications with SWT and embed your application in a browser control.
* Then you should move pages and some controls from the web app to the desktop one by one.
In this way you can get a minimal application in hours :)
P.S. If you want an iOS app with this approach it's worth looking at this open source project: http://en.wikipedia.org/wiki/PhoneGap
I have to develop an ERP System for a 2,000+ end users organisation.
Could you please suggest me with comparable points that among (Java or .Net)
in which technology I should invest money and time? Although I have done
some average projects in both, but this project is going to be very big in near
future in terms of scalability.
I want to know your experiences and some tips from you people, so that I can develop
and deploy this project efficiently.
I rate .Net > Java for this project only due to less development time available.
We have to use some Rapid App Development technology.
I have to deploy this on Cloud (Azure or Google App engine).
It will be better if I got answers from those people who works in both (.Net and Java).
I will appreciate answers from your experiences.
I would suggest creating a very small proof-of-concept project in both technologies, which do something real - like allow people to log in, see messages, and allow them to type in new messages, and log out again.
Even if the project is laughably small, if you do it well, you will have a finished product on each platform which have shown you by experience how things works and if you like the way you had to do them. You will be able to see if you can debug in the cloud, if you can profile when load testing, if you can do fast work inhouse which then works well when deployed to the cloud.
And you will need to figure out things. Are the online resources good? How responsive is the StackOverflow community for each platform when you ask questions?
Personally, I consider the ".NET is Windows-only" to be important. Except for that I do not believe there is any technical showstopper for either platform.
I think both approaches can be used to deliver this successfully. I would expect you to have the same amount of success/pain with either choice. When it comes to making a decision you should base it on the amount of expertise that you have to hand. That is, your own and that of your existing colleagues and the resources that you can acquire (new recruits, contractors, consultants etc.).
That said a couple of technical notes:
The Java approach tends to have more freedom, i.e. more frameworks and choice of technologies for various solutions (although GAE will bring in some restrictions).
There is less choice in the .NET space, but that is not always a bad thing. E.g. you tend not end up in tireless debates about the logging frameworks.
Java is starting to age as a language and C# is a bit nicer, however there a number of newer languages that run on the Java VM (Scala, Groovy, Ruby, Clojure).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I've just finished a relatively large project for the Android, and it's left a bitter taste in my mouth with the knowledge that it will never run on one of the most ubiquitous handsets this side of the solar system (the one by that fruity little club).
So, for my next project, I want to write it in a way that makes most of the components easily transportable between the iPhone and Android platforms. The way I'm thinking of doing this is by coding most of it in Objective-C, and then adding the platform-specific parts in more Objective-C and Java respectively. On the Android side, this will require using the the NDK.
My knowledge of C is good, but my knowledge of Objective-C is close to zero, and I have no desire to learn C++. How sane is the approach above, and is there a better one? Is there any way I can code in Java and still reach the un-hacked iPhone market? And how likely is it that the people I know (iPhone users) will have an Android phone by next year?
Step back and think about what in the end you will logically be able to share.
The UI models are fairly different, the components are different. In the end what you might be able to share is data object classes, possibly some algorithms. It's not even like you could realistically end up sharing network code as in the old days because you aren't directly using sockets, you are using HTTP libraries.
So will all of the effort you are putting into this really find a payoff in the end? It seems to me the end result will be a brittle mess that is hard to update, and is mediocre on both platforms instead of being great on either.
Why are you writing applications? To make life easier for you, or your users?
Others have said basically this, but I'd like to make it more explicit. Your best bet is probably to write:
Cross-platform data models & core logic, using:
bits of GNUstep (Obj-C), or
CF-Lite (C), or
Whatever you'd like, as long as it's cross-platform :P
iPhone-only interface code, using Cocoa Touch (Obj-C)
Android-only interface code, however they do it for the Android.
That's as close as you can get; any attempt to write cross-platform interface code will undoubtedly result in a mediocre app on both platforms. But making all the rest of your code portable and just wrapping a device-specific interface around it is done all the time and has been worked great for some iPhone developers.
Objective-C without Cocoa is not so useful and won't bring you much closer to haveing a working iPhone codebase. You'd probably be better off writing your core in C with Core Foundation and using either Java or Objective-C for the platform specific parts. Apple has open sourced a large chunk of Core Foundation as CF-Lite, and it's toll-free bridged with Cocoa on OS X (i.e. you can use many CF classes interchangeably with their Cocoa counterparts).
My guess, which has no experience to back it up, is that you probably could write Obj-C with Google's NDK somehow, given that GCC exists for ARM, is open source, has an Obj-C compiler and a basic Obj-C runtime (which if it doesn't already probably could be hacked up to work on a new architecture), etc.
That might also be a lot of work for questionable benefit.
And of course "Obj-C" (without the NS classes) means something very different than "Cocoa", which is what most people really mean when they say "Obj-C". You might be able to re-use some of GNUstep for some that, but... Honestly, I doubt it. Sounds again like a lot of work.
So, yes, I think it is possible. It's also a lot of work and I don't think it's worth it.
Given what you've said, if I were attempting this, I would be tempted to write as much of your core logic as possible in C, then wrap it with two separate GUIs for each platform.
Coming at this from a different angle... I know that you said you wanted to try and stick with Java, but if you know C# then you could go with the MonoTouch framework for the iPhone. Mono is essentially and open source implementation of the .Net stack. The Mono team is working on bringing Mono to the Android so you could basically write a shared C# library for your business logic and have different Views/Controllers per platform. This would all be in C# of course and it is a bit more expensive, but it does solve the problem of writing everything in different languages.
I believe it is called MonoTouch on the iPhone and MonoDroid on Android.
The Apportable SDK is an Objective-C approach to write once and deploy to both IOS and Android. It will cross-compile a running IOS Xcode project to an Android SDK.
See here for sample apps that run on both platforms in minutes after download.
I'm not sure about Android but with the iPhone you can essentially write straight C as long as you wrap it up in Objective-C classes.
The Objective-C runtime has not been ported to Android yet. It shouldn't be too much work, but still, without a working knowledge of the language I doubt you'll have an easy time porting it.
What you are trying to do is going to be hard for a generic application, but should be possible for games, if you choose to develop the game in plain C (which is supported by both the Android NDK and the iPhone). You'd have to write up some glue code to pass input events from the Obj-C and Java environments into your C code, but that shouldn't be much of a problem - Objective-C allows you to directly call into your C code and there are plenty of example projects which do exactly this for Android.
I haven't tried this myself or finished watching the talk yet, but there is a Google Tech Talk on Developing iPhone Applications using Java up on YouTube that looks pretty promising.
XMLVM is a project which is capable of translating (some) Android applications to the iPhone. For more infromation, visit http://xmlvm.org/android/
I realize this may be a tad late, but it seems the industry is going in the direction of web apps these days to achieve app portability. That is, embedding a web-browser in your "skeleton native app", and writing javascript, css and html for Android, iOS and the other major smartphone platforms.
There are tools that help you with this. You might want to check out PhoneGap and Sencha Touch, but there are many more. Note that this approach may not be ideal for real-time/animation-intensive apps.
Here is a talk from facebook's mobile # scale conference where two teams (dropbox and orchestra) used similar approaches. Dropbox used C++ to create libdropbox and Orchestra (mailbox) used Objective-c to create libmailbox.
Again, they wrote their front ends in the platform native language and used their cross platform libs for core logic and data.
Key benefits I took away: Mailbox went from ios to android in 5 weeks because it was just building UI code. Dropbox can beta test changes to core functionality that are in the shared library with Android beta deployments were it's easier to do massive deploys at scale for beta builds.
If you can wait until later this year (exact amount of time unknown), Adobe will have AIR for Android and a compiler to iPhone. Thus you can write an app in AIR for the Android and use most of the same code to compile to the iPhone.
http://labs.adobe.com/technologies/flashcs5/appsfor_iphone/
Even if you can't wait see: http://www.insideria.com/2008/12/actionscript-to-cocoa---protot.html where it explains the similarities between ActionScript and Cocoa.
Also check out: http://labs.adobe.com/technologies/air2/ for the AIR version capable of using the touch screen.
So you can soon write once and deploy to Android and iPhone using ActionScript 3.
If gathering requirements for a medium-to-large web-based project, at what point should one consider using Java-based back-end, JSP, etc, over a scripting language like PHP, Python, or Ruby?
Hearing "use the right tool...", when is Java the right tool for web-based projects?
What is the "Best" language is often degrades to an emotional debate rather than practical. Champions of each language are extremely good at making arguments for why each language is the best. I ususally look ata couple of factors:
A) What languages are you and your team confortable with?
B) Is there an existing application/system to be extended or integrated? If so, what languages are most effective for such an integration
C) Are there built in or redily available libararies, components, etc that will allow you to more effectively produce results in one language over another
My decisions almost always boil down to what language/platform is my team going to be most effective on both developming and maintaining.
In my opinion, the language decision cannot be made independently of the larger development and runtime platform. This is implied by what James Conigliaro wrote, and also by what jonnii wrote, but neither called it out specifically.
Making such a decision, people often use unwarranted relative weightings for different evaluation criteria. For example, one of the criteria might be "runs on iPhone." But if you are not actually developing on an iPhone, you really don't care.
"Performance" is another criterion that can get an unwarranted weighting. Most Intel-based servers today, costing let's say $2000 without storage, are plenty fast to support a fairly high-volume web site regardless of your choice of language. If your load exceeds that which can be run on a single server (don't assume!), or if you need to share the server among different workloads, then perf may become more important. But generally your app load will fit in a 1-server box.
The development environment, including the IDE but also the source code control, the configuration management, and defect tracking - I guess what you might call application lifecycle stuff - is more important, in my opinion, than the language per se.
Another aspect you may wish to consider is, the "pull" the language itself will have on devs for your team. In the early days of Java, you could attract devs just by saying "we're doing it in Java." Now, that phenomenon has largely faded for Java, but in pockets it may still be true for other langs and platforms. This factor may or may not be important to you.
Pick the language/platform that your team is most comfortable using, the one which matches your deployment target and that you're mostly proficient in.
I have over 20 years of programming experience and I learned one important fact: it doesn't matter which tool you use, as long as you're comfortable using that tool. For larger teams, all team members must be comfortable with the choice you made.
I always tell people that it doesn't matter which tools you used to create an application. All that counts is if it will work as expected.
I'm planning to use Java for a project served using Google App Engine (Java support, of course). This is not The Answer [tm], but only my 2 cents :-)
Whoever has the libraries you need:
If you want to customize something pre-made, use PHP. This will usually be shopping carts, forums, and CMS
Java will have more libraries for random things (like fetching RSS feeds)
Don't know about Python/Ruby on Rails;
Rails is simple to learn, well organized and well documented. It's also agile and RAD (rapid application development). It's not perfect, but you could give it a try. It's another take on the web development. Java web framework are not so easy to understand and start is not so simple IMHO.
If you have to build a large web application, with rails you could separate the monolith app with different apps and then use ActiveResource restfully.
http://guides.rubyonrails.org
Almost always :-)
What I mean is that you can do any web project with Java/JSP adding more or less to the mix ( Spring, iBatis, etc )
But, as already pointed out, there are cases when you decide to use something else because for instance your team has a lot of experience with younameit and no experience with java or things like that.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
When java was young, people were excited about writing applets. They were cool and popular, for a little while. Now, I never see them anymore. Instead we have flash, javascript, and a plethora of other web app-building technologies.
Why don't sites use java applets anymore?
I'm also curious: historically, why do you think this occurred? What could have been done differently to keep Java applets alive?
I think Java applets were overshadowed by Flash and ActionScript (pun unintended), being much easier to use for what Java Applets were being used at the time (animations + stateful applications).
Flash's success in this respect in turn owes to its much smaller file sizes, as well as benefiting from the Sun vs. Microsoft suit that resulted in Microsoft removing the MSJVM from Internet Explorer, at a time of Netscape's demise and IE's heavy dominance.
1) AWT made for horrid UIs. Swing improved on that but it was too late, because...
2) Microsoft dropped support for Java in the browser (its propietary MSJVM), and before it did, it would only support the last version it released, which was roughly JDK 1.1 compatible.
3) So today you cannot be sure that an applet will run on the majority of non-developer machines, unlike flash.
Same can be said of ActiveX by the way.
For what it's worth, Sun is pouring money and resources into applets again. They've made some really significant improvements in JDK 1.6.10 to mitigate a lot of the 'clunkiness' applets used to exhibit. For instance, with this update, you can display your own custom loading image/animation while your applet loads, and the plugin has been put on a major diet to improve performance.
They've also embarked upon an initiative to directly compete with Flash and Silverlight - JavaFX.
Whether or not the market will respond to any of this remains to be seen, but it's certainly a fascinating move on Sun's part given Flash's dominance in the market place.
By the time Java's GUI API stopped totally sucking, everyone was using Flash. And even today, Java is no where near as good as Flash at doing fancy graphics.
I assume it's because java is a "real", ie. general purpose language. To make an applet, you have to write code, and there aren't any shortcuts.
Now that flash etc have come along, you can pretty much just drap and drop your way through making a cool animation for your website. This is a much lower barrier for entry - you don't have to know how to program in order to get a flash animation working. So flash proliferates, and java applets are hardly used anymore.
I think applets are collateral damage in the battle between Microsoft and Sun.
At first, the JVM was very slow to load and demanded too much memory.
Then, when increase in computing power made the JVM possible, Sun played hard as it attempted to control all things Java:
As part of another private antitrust lawsuit filed against Microsoft by Sun in March, Sun sought a preliminary injunction requiring Microsoft to include a current Java virtual machine (JVM) in the Windows XP operating system. Microsoft said the decision to include the JVM this week is a direct result of the latest legal entanglement with Sun, but Microsoft plans to disband support for Java in Windows following Jan. 1, 2004. Microsoft Reverses Course, Will Include Java VM In Windows XP--For Now
They took forever to load up and get going in the browser, and then for a lot of people they didn't work. When they finally did load, the interfaces were ugly and clunky. I think the poor user experience was a big step towards making applets obsolete.
So to answer the original question I have a question of my own - you ask "Why don't sites use java applets anymore", and my response is "why would anyone want to?"
I see them a lot in acedemic settings (hosted on department or faculty sites), but you're right in that they are not very popular.
However, remember that Java's big promise has been achieved. We have Flash, Java Applets, Silverlight, and ever-improving JavaScript frameworks.
Now if I made add a personal opinion - I think that Java applets are inelegant. They tend to look ugly, the Java runtime makes its presence in the OS far too known (in terms of runtime visuals, updates, and the ugly installer). Flash is much better with its rich media environment and its transparent (and ubiquitous) deployment.
People still use applets. But you are right, there are tons of different solutions out there. For example, take a look at javafx
I think compatibility issues were a big problem. Most notably with IE and Microsoft's Java VM which wasn't as standards compliant as it might have been.
Even with the Sun JVM you could have problems. I've had fun where I've had two 3rd-party Applets requiring different versions of Java which causes all sorts of problems. Sun have tried to solve this problem by replacing Applets with Java Web Start which gives you a link in the browser that launches the application in it's own window instead of inside the browser. (In theory with JWS you can have different applications using different VMs but it never seems to work for me as well as it should.)
Advancements with JavaScript have also made it possible to developer much richer web pages so a lot of things in the past that you could only do in Applets can now be done simply with AJAX.
First, they not gone. You can still find lot of applets on the Web, lot of people use them particularly to demonstrate algorithms and such.
Advantages: can leverage existing libraries (math, physics, sorting, graph, etc.) and it is faster than Flash.
Inconvenience: it might be risky to target a recent JVM (although Sun did a good job on automatic updates, looks like lot of people are using Java 1.6 already), load time is a bit slow (even though great progress have been made there).
You can still find lot of game applets too, like Bookworm, with the added advantage, perhaps, to have part of work already done to run them on mobile phones...
Second, I can predict a regain of interest with JavaFX. Applets on steroids, able to break legend of "applets are ugly"... :-)
Last, a library like Processing makes super easy to create graphical intensive applets, and you can find lot of them on the Net, eg. on OpenProcessing where the worst (beginners in programming) is near the best!
I wonder how widespread the JVM actually is? In the case of Flash, IE5 preinstalled it, giving it a large automatic user base. But unless the JVM was included with the OS install, users wouldn't have it. I suppose as a developer you target the largest install base, meaning choosing Flash over Java.
There are Java applets here and there; definitely not widespread though.
i believe it's their ugliness that kept them away from the modern web. flash brought the design, javascript brought a convenient way to make some cool things on a client. being a box inside a browser (just like a flash, though, but much uglier) applet technology was put away.
actually, the only thing that might be missed is the possibility to have a 'client-server' type of communication inside the web, because java applet could have a stateful connection. on the other hand, you would have to put some server on the other side and open a port for it, which just was too much house-work for shared hosting environments.
applets still live in some different areas, like control centers for roads, tunnels, power plants and stuff like that.
People are still using applets, at least for the company that I am working with. The applets are used mainly by internal users.
I feel that applets have their benefits, as companies which employ Java at the server side, most probably will have a large pool of talents who are better skilled at Java.
Although perhaps other technologies like Javascript, HTML/CSS or flash are more popular or more fanciful, but the talent pool could be better employed to create web apps with Java applets as it is a language that they are already familiar with through their work with the server end stuff.
It could be faster for the Java talent pool to deliver a change request with Java applet solutions at a higher accuracy than any other technologies.
Sometimes, the most important thing in a technology solution is its functionality and how fast people who need to provide support for them can react to changes.
The JVM is very widespread, especially in the coorporate world, at least where I've worked, there was always a JVM installed.
I'm currently working on a Java Applet, but in general, I would never an applet unless I had to. But then again, I wouldn't use Flash or Silverlight, either. Applets have a slow load time, and look out of place in webpages. Also, Macromedia/Adobe have outmarketed the good ol' applets.