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.
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've read a bit on client-side browser languages and tried a few out but I'm not convinced I know of all the options. To make it clear, I'm looking for something that can be processed either through the browser or otherwise on the clients computer with minimal need for additional installations/configurations.
At the moment I know of JavaScript, Java, and Flash ( I'm aware this isn't actually a language, but seems pertinent to mention it still as an option). If at all possible it seems like avoiding Flash would be best, but it's still a consideration. I know there are various flavors of JS and Java but I don't really know of any that make the end-product that different than just the raw language. Java and JavaScript both seem relatively slow when it comes down to more complex and weighty apps, though performance is always improving as our browsers and libraries get better.
All this said, is there anything available or about to be available that will do things better?
JavaScript is the only native browser language that’s widely supported. Flash isn’t native, but it’s the most widely-supported plug-in.
Nothing else yet seems to be installed widely enough to be worth considering in general, although obviously you should always try to figure out what the actual/intended audience of your specific project has installed.
JavaScript performance has come on leaps and bounds in the latest versions of all browsers as it’s become more widely used.
As far as interface programming goes, the only thing JavaScript has built in is the DOM interface, which lets you programmatically control the HTML page that the JavaScript is running on. The DOM interface is pretty raw and basic, so there are lots of frameworks that try to make it more palatable (like jQuery), and frameworks that seek to provide libraries of desktop-like UI controls (e.g. jQuery UI, Cappucino).
JavaScript is the main language for client-side browser development that interacts with the elements on the page, does ajax requests (update screen without a full page refresh), etc. Depending on your specific requirements, I would recommend JavaScript, as its most likely the tool that will accomplish your needs.
Java is NOT a client-side browser language, Java is a programming language, you can write apps in Java and embed them in a website, that is called a Java Applet. This will require that all users have a JRE installed on their machine for your applet to work.
Java has nothing to do with Javascript -- they share some similar syntax, and thats about it.
Flash is a browser plugin, if you want to write a flash application, ActionScript is the language it uses. It still requires that anyone going to view your application have the Flash plugin installed.
HTML5 is the future.
Currently many features are achieved with JavaScript, but these are being wrapped in libraries (e.g. the "polyfill" library Modernizer and even in other languages, e.g. Java with GWT. This is an area in a greater state of flux than most.
You forgot unity.
Unity is an up-coming client-side application development platform. It does require installing just like flash but it's a lot more powerful then flash and seems to be picking up popularity.
Unity has a lot more inbuild framework rather then doing it in HTML5+JavaScript. I would say these are your two main options. For an example of javascript & html5 in action look at cloud9ide
One of the big advantages of unity is the 3D engines.
Java applets are so 1998 and are not an option.
I absolutely love good defender games (e.g. Gemcraft, Protector: reclaiming the throne) as they can be intellectually quite challenging; it's like playing chess but a little less thinking and a bit more action. Sadly, there are not that many good ones out there and I thought I would create one myself and share it with the rest of the world by making it available on-line.
I have never worked with ActionScript but when it comes to on-line games, this is the main choice. I have tried to find a decent 2D game in the form of a Java applet but to no avail. Why is this so? I could write the game, most comfortably, in Delphi for Win32 but then people would need to download the executable, which could deter some form downloading it, and also it would only work on Windows. I am also familiar with Java, having worked with Java for the last four years or so; although, I don't have much experience with games programming.
Should I not be deterred by the fact that all on-line games are written for in Flash and create my defender game as a Java applet, or should I consider learning ActionScript and games development for the ActionScript Virtual Machine (AS3 looks very much like Java... but still, it's an entirely new technology to me and I might never use it professionally.)
Could you, please, just answer the the question in the title? Why Flash, not Java applets? Is it only 'politics'?
Flash is more popular since its penetration rate is huge.
Flash is also more powerful when it comes to create and integrate graphics assets (since Flash CS* is also a vector animation editor).
It's also very easy to embed sounds and fonts assets, to play with bitmap effects, without using any aditional library.
And last but not least, there's a lot of sites who offers ActionScript APIs in order to earn money with your games by adding various ads in it (such as MochiMedia, Kongregate...)
Flash provides a fully-built graphics and sound engine that will handle separate objects ("sprites") on paths and animation.
In Java those features would need to be provided by third-party library. Java does provides the necessary building stones to build such an engine, however.
JavaFX might change this, however.
I can provide a little insight on the Java side: Early in the history of Java, Sun tried to push Java applets as the new way to display dynamic content in a browser. This attempt was doomed to failure by the combination of the following factors:
Java had (and still has) a lengthy load time for the (JRE) runtime;
Java originally had only AWT as a GUI toolkit, and AWT is limited and really ugly;
Java used to be a lot slower before the advent of faster CPUs and JIT compiling;
Java was (many think intentionally) supported very half-heartedly by Microsoft in IE, so it wasn't well integrated and ran poorly.
All this gave Java (deservedly) a horrible reputation, from which desktop and browser Java have still not recovered. To most people, Java stands for ugly, slow and often not working applications. It still suffers from this stigma today.
While both Java and Flash are Turing complete programmng environments, Java is more universal, with a bigger set of libraries for all kinds of different purposes. Sun strove to have the Java environment be universal among platforms, so browser-side Java includes a lot of libraries that are usually not needed. Again, more load time.
Simple answer: the flash player is installed in almost all of PCs, but JRE isn't.
Flash has a much wider install base, that can be the only reason. I personally don't install Java on my machines....flash, of course.
Why write something for a far smaller audience? I'm not saying it's wrong to, but that's usually the reason when you're making games for a profit.
Think of this equivalent with consoles, with the second generation playstation there were hardware add-ons available...but they were useless unless the games used them. You had 3 options as a game developer, package it with your product - driving the price up, assume they have it - smaller audience, or assume they don't - maximum audience, maximum profit. The result is the hardware never really sold much because as a game developer you had to assume they didn't have it.
For me, that equates that to Java vs Flash, if I have to install it, the price for me accessing it goes up...assuming they have the most common thing and you're safe, minimum cost of entry, maximum audience.
However, if you have a great game, I could be convinced to install :)
Flash typically performs better at the kind of drawing, animation and video features that games require, since that's what it was originally designed for. In addition, the strict-OO nature of the Java language does not lend itself well to the kind of ad-hoc rapid development environment that is common for games.
More importantly from an author's point of views, Flash is by far the more commonly-deployed browser plugin. Java just doesn't have the penetration on the desktop. Applets were historically despised for their instability and poor performance (particularly slow startup); whilst that has improved somewhat, Sun are continuing to undermine what user acceptance they have left with their obnoxious bundling updater. It is a brave company that develops anything much for desktop Java these days.
should I consider learning ActionScript and games development for the ActionScript Virtual Machine
It's definitely worth learning JavaScript/ActionScript. (They're almost the same language, sharing a standardised common core.) Then you can apply your Flash scripting knowledge to browser scripting. You can even consider implementing games in JavaScript/HTML itself!
AS3 looks very much like Java...
In as much as it's a C-like-language, yes. However the concepts and practice are very different; you'll have difficulty if you try to write JS/AS like Java.
A lot of flash developers are designers who have crossed over into making games. They used flash as a design tool before a programming tool.
Plus it seems to be something of a precedent now for online games to be written in flash so I guess people do not want to deviate from "the norm"
Future Flash CS5 could creates iPhone applications directly, so you'll be creating games for 2 platform at the same time.
A few years ago client Java was unsuitable for web development because a remarkable part of web users did not have Java installed. ( I don't remember exact numbers, more than 10%).
Now I see the Google Analytics stats for a big site and it tells that >98% of users have Java installed.
Is these stats very biased by Javascript usage? As I understand Google Analytics measure only users that has Javascript.
Is the picture similar on other big sites?
Does client Java have really "stopper" drawbacks compared to Flash?
EDIT: I mean java applets mainly, java WebStart seems to be not suitable for average user.
I mention Javascript only to describe the way Google Analytics works.
When I wrote my diploma project, I had to choose between Flash and Java Applets. Here are some pros and cons:
Java Applets:
[plus] you program in Java, which is mature and stable
[plus] you can use the Java GUI frameworks that pack a lot of punch
[minus] the first time the user hits the page with the applet, the JVM must be initialized and this can take up to a few minutes even on a fast computer
[minus] Applets are not meant to be used as animation media; sure, you can do stuff, but it is like programming in C - you do everything from scratch
example: i needed to show a data packet as it moved between two routers. The packet must be a control of some sort, like a button or smth. This animation can be defined in 1 line of code in Flash, where all objects derive from some base object that can be animated. I could not find a suitable solution in Java.
Flash:
[plus] really really focused on animations;
[plus] ActionScript is actually an OO language
[minus] ActionScript is sloppy, bughish and has only a few supporters. If you are stuck, be prepared to search obscure Japanese forums for solutions
[minus] ActionSCript may be OO, but it lacks a lot of features, like Enums, fully fledged interfaces, threads (!!!!) etc.
[minus] Flash was designed to be used by non-tech people - they just use the authoring tool; I wrote code for everything and it worked, but it was a pain.
My conclusion:
I eagerly await a programming paradigm for animations and rich client interfaces.
ps: Silverlight seems to be a disappointment so far, maybe Microsoft will inject some $ into it.
Mmm, Java seems to be better supported than I though, I searched some stats and found between 92 and 96% of browsers support Java (ie. it is enabled enough to detect it! although I guess lot of Java detection algorithms use JavaScript to detect & report - as you point out - but JS support is very good too anyway, even more in our Web 2.0 era).
Adobe boasts better support, but overall the difference is rather marginal. Anyway, somebody really wanting to see/use the application will activate/upgrade/download the needed engine.
Now, we have to see what JRE is supported! Alas, I didn't found any stat for that.
There, Adobe have an edge: not everybody have Flash 9 or 10, but upgrading is quite fast. While downloading and installing a new JRE is quite a bigger task... Of course, you can target the historical lowest common denominator Java 1.1, or more realistically Java 2 (1.4), but it is still frustrating not to be able to use all 1.6 features...
I have seen some people complaining that Java applets crashes their browser (apparently on Unix systems) but it is more an issue with a minor number of browsers/systems than anything else.
And as pointed out, startup time of a Java applet is quite longer than for Flash (although some big Flash games are slow to load too).
Now, I have seen a number of Processing applets, like the notorious Webpages as graphs, most of them load quickly: lot of the power is already on the hard disk of the user, in the extensive Java library. Processing generates quite lightweight jars, while lot of Flash applets must include foreign libraries... or reinvent the wheel!
Some previous postings are obsolete in regard to comments on ActionScript. ActionScript3. became available in the Flex 2 time frame, i.e., January 2007 when Flex 2.0 and Flash player 9 shipped.
AS3 is a full blown OOP programming language comparable to Java. It has classes and interfaces, inheritance, access protection keywords for class members, constructors, statics, plus some nice things that Java doesn't have: properties, events, declarative data-binding, and closures.
By default AS3 is statically compiled, hence one declares the type of members and variables. This can be relaxed to where AS3 can revert back to dynamic typing ala JavaScript. It is less efficient at runtime, though. Sometimes when dealing dynamic data it is none-the-less useful to selectively employ dynamic classes. (A nice benefit of static type checked language is code completion in the Flex Builder IDE.)
Much of Flex development is accomplished using MXML. This is a declarative XML-based DSL for Flex. MXML gets compiled into ActionScript3 code, though. So what you do in MXML is equivalent to AS3 imperative coding, but can often be more concise, clearer, and more appropriately structured with respect to the underlying graphical Flex form it represents (i.e., MXML is good for coding the views of the MVC pattern).
The bottom line is that ActionScript3 programming of Flex is easy and natural for a Java or C# programmer to learn. The language is not at all the issue. The power of Flex comes in becoming intimate with the Flex SDK and the myriad capabilities found there.
Not an exact answer, as it would be very opinionated, just sharing my experience...
In a recent project, where we were building a WAI compliant site, we were asked to avoid flash objects as accessiblity was a major issue. Applets on a different note don't go very well with most web developers ;). One reason might be the differences in the paradigms of Rich UI vs. web UI.
However, we found applets to be irreplaceable (not speaking for .NET and ActiveX controls) when client side monitoring was needed. The application uses SmartCard based authentication and applets are loaded into browser to listen for client side events (card removal) and alert the server to end session.
In this context I tend to feel that Flash is meant to be eye candy (view) where as applet though designed to be versatile, takes the role of model on client side. It is to be noted that both applets and flash consume CPU cycles on client machine, hence were traditionally suited for tasks involving lengthy computation. Calculators, Report generators, Trend illustrators, Astrological chart generators (yes) and other tasks where data can be fed by user and are results shown immediately make use of these.
A major concern involves lack of client side software (Java, flash plugins). The user experience in such cases is more than annoying.
Noticed some comments about java not updating itself. Now 1.6.0_10 is out, and it's updating itself more easily and automated than before, and you have the option of a new install method, the java kernel one. This automates the install of java components as you need them.
Some text about this: http://java.sun.com/javase/6/6u10faq.jsp
So there are changes, Sun just wakes up with the new Ceo i think. I know it's 1-2 years until this new system propagates but you can start your project and have fun when it's ready maybe. :) Who knows.
Anyway, maybe you work +500% for easy animated features than flash, but if your app is not a simple animation, then you work +500% with flash for some simple 3 line java code substitution :) Depends on your app.
I worked in Java for the last 7 years, and then I recently started on AS3 on my newest project (1.5 years and going). I love AS3 and Flash, and here's why:
The language itself is very similar to Java. The documentation at Adobe is as good or better than JavaDocs.
The AS3 language supports XML as a native type. Parsing XML in Java is a nightmare.
There are nice animation and graphics frameworks for Flash, such as papervision 3D and tweener.
If you use the Flex 3 framework and Flex Builder 3, building interfaces that look as good or better than Swing is trivial. I loved writing UIs in Swing, but designing UIs in the visual Flex Designer is like a breath of fresh air.
I'm pretty sure that there's more browser support for Flash.
Have you ever seen a Flash applet load? It has really poor usability, and makes your user click through two or three dialogs before the applet starts. Flash apps just work.
Good luck on your project!
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.