Here is an interesting post that occured in the ABCD Flash user group.
————————————————————-
If the GUI will be front-end Web-based I sincerely believe that Flash is a better option than using Java Applets.
Here are simple but compelling reasons to choose Flash over Java:
1. Java is installed at only 80% of the browser vs. 98% of Flash. (and it’s isn’t installed by default on XP or Linux)
2. There are many compatability problems between different versions and platforms in Java.
3. Java requires a much (**much**) larger download.
4. Even for the simplest application Java requires at least 8MB of memory just to load the VM, and it has long load-up times.
5. Java is generally very slow doing graphic operations, and Flash is faster and scalable due to its vector graphical nature.
6. Although Java and Actionscript (Javascript) are both cousins of the language C, they differ substantially. The learning curve for Java is rather steep in comparison to Actionscript. It is said that there is a 3 million Java Army — but how many of them are savvy in J2ME and/or Swing?
7. Flash does UI excellently (java can only hope to catch up) and you can built a GUI with minimal scripting experience with “out-of-the-box” Flash components.
I understand that Java might be a better back-end server-side solution in some cases but I don’t know enough about it to comment on it.
However, I would like to clarify and update some of Catie’s “CON-Flash” comments with the latest information about the most recent version ofÂ
Flash MX 2004. See my comments below:
CON-Flash
– Horrible horrible debugging/error-reporting capabilities – this was the
one thing that convinced me that it would be a huge headache to develop a
complex application in Flash. When things failed, the application would
still run but just act strange instead of failing with some proper
information on why the failure occurred. This makes debugging and
troubleshooting complex interactions incredibly difficult. Flash MX has
greatly improved its debugging capabilities but I still see this as a major
drawback for application development in Flash.
In Flash MX 2004 debugging has become much easier and better to track problems.
Flash provides several tools for testing ActionScript in your SWF files.
The Debugger, lets you find errors in a SWF file while it’s running in Flash Player (you can also STOP the application). Flash also provides the following additional debugging tools:
The Output panel, which displays error messages and lists of variables and objects (see Using the Output panel)
The trace statement, which sends programming notes and values of expressions to the Output panel (see Using the trace statement)
The throw and try..catch..finally statements, which let you test and respond to runtime errors from within your script
The availability of comprehensive compiler error messages, which let you diagnose and fix problems more readily.
Using Flash MX 2004 Professional you can use Data binding which is a series of actions that take place in response to events, such as the following:
The data of a component property changes.
A web service call is completed.
An XML document is fetched.
All actions that are performed by data binding or web services are reported to a log.
When you run an application that turns the trace on, a detailed log of data binding and web services events and actions appears in the Output window. The following are the types of things reported:
Executing bindings
Calling web service methods
Fetching XML documents
Status and result events from WebService and XML components
Valid and invalid events from validated data fields
A variety of errors, invalid settings, and so on that are checked for
By running your application and then examining the log, you can often find out why things are not working as expected. Sometimes an error is explicitly reported—for example, a missing web service parameter. Sometimes the data is bound to the wrong component, or to no component, and so on. If you find that there is too much information in the log, clear the Output window by selecting Clear from the context menu, to keep the log as short as possible
– ActionScript is a *lot* less powerful than Java – ActionScript doesn’t
support basic things — for example —Â manipulating files (this could be
for security reasons, but there is no ability to certify your flash
application and then gain access to the user’s hard drive as there is with
applets and java apps for example).
Agreed, but I believe that file manipulation will be added in future versions.
You can manipulate XML files.
– Very limited Reusability of code – flash applications can’t re-use code
created in other flash applications without some serious copy and pasting. I
imagine you could attempt to get around this by building little modular
flash movies that can be imported into other movies, but this seems like
design gymnastics to get around a problem that doesn’t exist in java.
Additionally, if you wanted to build an application framework that was meant
to be extended and used in a variety of different ways this seems virtually
impossible in Flash (though it might be interesting to talk to some serious
macromedia developers and see if they have some insight as to how one might
do this)
ActionScript 2.0 (new to Flash MX2004) is a restructuring of the ActionScript language that provides several powerful new programming features found in other programming languages, such as Java. ActionScript 2.0 encourages program structures that are reusable, scalable, robust, and maintainable. It also decreases development time by providing users with thorough coding assistance and debugging information. ActionScript 2.0 conforms to existing standards and is based on the ECMAScript 4 proposal.
The primary feature of ActionScript 2.0 is a familiar model for creating object-oriented programs. ActionScript 2.0 introduces several new object- oriented concepts and keywords such as class, interface, and packages that will be familiar to you if you’ve ever programmed with Java. You can easily extend Classes now.
The OOP model provided by ActionScript 2.0 is a “syntactic formalization” of the prototype chaining method used in previous versions of Macromedia Flash to create objects and establish inheritance.
Strict data typing ActionScript 2.0 also lets you explicitly specify data types for variables, function parameters, and function return types.
– lack of built-in GUI components that support applications (Java/Swing
encompasses the concepts of application development such as menus, dialogue
boxes, etc.) Flash has no such libraries so you either need to build these
components from scratch or grab some open-source ones online
Flash has a whole family of standard built-in components ( Data, Media and UI–including menus, scroll panes, text-areas, radio buttons etc, ), and many (many) more are available from third party developers (free-ware and $).
 Components are movie clips with parameters that allow you to modify their appearance and behavior. A component can provide a wide range of functionality. A component can be a simple user interface control, such as a radio button or a check box, or it can be a complicated control element, such as a media controller or a scroll pane. A component can even be nonvisual, like the focus manager that allows you to control which object receives focus in an application.
Components are designed to allow developers to reuse and share code, and to encapsulate complex functionality that designers can use and customize without using ActionScript.
Components are built on version 2 (v2) of the Macromedia Component Architecture, which allows you to easily and quickly build robust applications with a consistent appearance and behavior.
Components allow you to separate coding and design. They also allow you to reuse code, and download components created by other developer
or create your own components.