Simon’s Blog

I take it you’ve read the Steve Jobs essay discussing Flash yesterday.  It’s a well-written piece, despite some smoke and mirrors in the discussions about “open vs closed” systems that most people will see right through. The bottom line, however, was crystal clear, and we already knew it: he has no intention whatsoever of allowing Flash (or any third-party technology) to run on on the iPhone, the iPod Touch, or the iPad. No surprises. There was a part of the essay, however, that was quite revealing.

In one section, Steve wrote about “developers grow(ing) dependent on third party development libraries and tools.” He clearly feels, then, that third-party technologies can be rather better and more attractive to developers than the technologies provided by platform owners.  Apple’s response to this challenge is apparently not to compete to provide more attractive developer technologies, but simply to ban the third-party technologies.

Who is the most likely loser with this approach? I suspect it’s Apple. When a company gives up competing, there’s  usually only one result – a rapid, drastic decline in the quality of its offering relative to the competition.  That’s because, without competition, companies tend not to invest in improving technologies; which opens up a window for other players who aren’t afraid of using the pressure of competition to drive up the quality of their offerings…

Today, there’s no doubt that iPhone/iPod touch/iPad is, by some margin, the most exciting mobile platform.  Apple has done a truly incredible job, and made the established competition – companies like Nokia and RIM – look pretty dumb. However, there’s a raft of new competitors seeking to take Apple’s crown. It’ll be fascinating to see whether Apple’s new competitors in this segment – that is, the other modern mobile platform owners such as Microsoft, Google, and now HP (Palm) – approach what looks like to be an opportunity to wipe out some of the advantage that Apple created for itself when it completely revolutionized the mobile phone market a few years ago with iPhone.

Today, Apple acquired a start-up company called Siri.  Siri is a company focused on what you might call “next-generation, voice-activated search”.   The ideas behind of Siri are as follows:

• To begin your search, speak into your phone telling Siri what you want. For example, “Book me dinner for two at the best local Thai restaurant.”
• This is clearly rather different from simple key word based searches that you’re used to, such as, “Thai restaurant London UK reviews”. Siri uses not only speech recognition to figure out the words that have been spoken, but it uses what’s called “natural language understanding” to extract the meaning from the words.
• Having extracted meaning, it’s possible – in principle, to do much more interesting things than can be done with simple key-word based search.  In Siri’s case, that means it can connect to various on-line services and begin to carry out tasks on behalf of the user. In the case of my example, Siri could look at on-line restaurant reviews, then book a high-rated restaurant that’s close to the users geographic location (available, of course via GPS).

It’s a compelling value proposition.  We developed a similar system (not in the consumer domain, but in the life sciences domain) over ten years ago (see an article I wrote about it in 2001, for more details – it’s an easy read, designed for a non-specialist audience). I found that it’s really easy for people to understand that it’s not a trivial problem to have solved; so people were always blown away when I showed it to them, and showed that it really worked. So, in many ways, this kind of thing is  really an easy sell.

On occasion, I’ve considered re-configuring this technology for use in consumer applications. However, I ‘ve always resisted because I think there’s an issue with this kind of technology when applied to voice-activated natural language understanding applications in the consumer domain; an issue that greatly limits genuine utility in the real world.  The limitation is this: when you’re out and about, wanting to use your phone for a voice-activated search, you’re typically in a noisy environment.  That makes it difficult to get a high-quality recording of the user’s voice. Microphones love recording background noise – in fact, when you listen to the recordings, you’d sometimes be forgiven for thinking the microphones are better at recording noise than the signal you’re interested in. If you’ve ever spoken to someone on a mobile when they’re in the car or on walking on a crowded street, then you’ll know what I’m talking about. It’s often hard to understand  every word that the person is saying; and computers are much worse at recognizing speech than people are.  The low-quality recording makes it difficult for speech recognition software to determine accurately all the words that have been spoken; which in turn makes it impossible for the natural language understanding software to “do its thing”.

Now, I’ve just outlined what I think is one significant problem with this kind of technology. However, that’s a technical problem; and technical problems can often be over come with smart people and R&D dollars. So, I’m intrigued to see what Apple does with Siri.  If Apple’s engineers can do something clever with microphone technology and/or sound processing,  to make it possible to obtain high-quality voice recordings in noisy environments, the company might be on to a winner…

I’m sure you’ve seen the Gizmodo scoop – the full details of what seems to be the next Apple iPhone.  I haven’t included a photograph here (you can see lots at the previous link), because there seems to be some uncertainty over whether this phone was obtained legally or not.  Nevertheless, the details of the next iPhone are now clearly in the public domain. Herewith then, my initial thoughts…

• In essence, notwithstanding a few tweaks, Apple has kept pretty much the same design as the iPhone 3GS, which was the same as the iPhone 3G, which in turn was the same as the original iPhone.  It’s undeniably starting to get old; and devices from the competition have physically larger screens, in similarly sized cases.  If anything, the screen on the next iPhone is reportedly smaller than the screen on the 3GS.
• The new design aesthetic doesn’t blow me away. It looks a little uninspired to me. In fact, it reminds me a little of some  rather old Sony Ericsson phones – the K750i and the M600 (see the pics below).

• The new features on the next iPhone seem to be: front-facing camera; improved rear camera with LED flash; higher-resolution screen.

The bottom line of all this is that I’m a little surprised Apple would produce a design like this.  I was expecting the next iPhone to be a really major update.  Taking everything into account – the new design and the new features – I can’t see how this can be seen as anything other than a rather small incremental step forward for iPhone (and in some ways, the design may actually be a step backwards compared to the 3GS). Certainly,  I don’t think it’s enough to drive iPhone sales forward in a big way at current price levels.

The only way this design makes sense, in my opinion, is if Apple can sell it at a price point significantly below the current one.  As of now, Apple has left a lot of smart phone market share on the table because of the pricing of iPhone. It’s one of the reasons why Blackberry sales are continuing to thrive: people look at iPhone, see how expensive it is, and then realize they can own a new Blackberry design for much less cash.  Of course, it’s always possible that this isn’t the final design; and that the next iPhone to come to market will address the various short-comings (the substandard Sony Ericsson “DNA”; the small screen, the poorly conceived volume buttons etc.). It’s also possible this is a deliberate leak by Apple of a “not that great” design, to lull the competition into a false sense of security…

Google is currently locked in a battle with Apple. Both companies are fighting to produce the most compelling smart phone platform for consumers, businesses, developers and advertisers.  Apple has iPhone; Google has Android. Currently, Apple has the more compelling offering in almost all areas.  The Android team is working hard to catch up, and overtake Apple. Maybe they’ll succeed, and maybe they won’t; but there’s no doubt that Android has been making great progress in terms of sales of handsets and garnering  mind share among consumers and developers.  Yet, there’s a problem.  Leaving aside issues with the software, Android hardware seems to have some significant design weaknesses in areas where there’s no excuse for weakness.

Take a look at what is probably the best Android handset on the market to date: the Google Nexus One (see the picture above).  It doesn’t take a genius to see that the designers of the Nexus One were “inspired” by the iPhone.  Here, though, is my question.  Just how bad a hardware designer to you have to be to: 1) have seen the iPhone; 2) decide that the iPhone form factor is what you want for your phone; and then 3) completely misunderstand one of the most compelling value propositions of iPhone?  What is the value proposition I’m talking about?  Simply this: the iPhone minimizes user interactions with the device by anything other than the touch screen.

Now, have a look at the Nexus One.  It’s very much like an iPhone, except the Nexus One has a navigation trackball and four hardware buttons on the bottom of the front face of the phone.  Not only is the trackball a horrible, cheap component, but it’s also completely pointless. The Nexus One has a touch screen; you don’t need a trackball to navigate around the UI.   Similarly, the four hardware buttons at the bottom add unnecessary clutter to the design, and are also completely pointless.

Until Android steps up a gear on hardware designs, Google will not get close to competing with Apple on overall quality of offering. The real problem here, however, is this: the things I pointed out about the hardware design are not difficult to grasp. The fact the Google team didn’t/don’t get this leads me to believe there is a lack of understanding and good judgment inherent to critical parts of the organization.  I can’t see how that bodes well for the future prospects of Android overtaking Apple in terms of quality of offering. Will the Android camp ever come up with really compelling, original hardware design ideas? Or is Android forever destined to play catch-up with Apple, attempting to copy what Apple does, but always slightly missing the point?

You know, I admire Steve Jobs as an entrepreneur. Sometimes, though, his comments really do errr… to use a gentle, old-fashioned British phrase… “take the biscuit!” Recently, in one of Steve’s e-mails to a customer who had queried what the customer thought was a bad decision by Apple, Steve responded,

We’ve been there before, and intermediate layers between the platform and the developer ultimately produces sub-standard apps and hinders the progress of the platform.

What Steve was saying was that, Apple’s tools, Objective-C and Cocoa Touch produce great apps, whereas anything else produces substandard apps. Now, I’m willing to accept that this is a widely held view (by non-developers); and as such I can accept that Steve Jobs (who isn’t a developer ) might believe this himself.  That doesn’t make it right, though. In fact, it’s flat-out, plain-old wrong.  Ultimately, it’s developers that control the quality (good and bad) of apps. Period. Don’t believe me?  In that case, I invite you to take a look at this collection of screen shots of Apple-approved iPhone apps written in the Apple-approved technologies, Objective-C and Cocoa Touch.

Now, tell me again, what is it that produces substandard apps?  If anyone’s going to insist it’s the tools, they’ll have to accept that using the tools Objective-C and Cocoa Touch ultimately leads to substandard apps…

You may, or may not, have followed recent developments in terms of new rules that Apple is imposing on developers for creating apps for the iPhone.  If you haven’t, I recommend getting up to speed by reading John Gruber’s post on the topic.  Steve Jobs called that post “insightful”; so it’s safe to say it’s a good reflection of the reasons why Apple has done what it’s done. Please see John’s post, and then come back.  In short, what Apple has done is to ban development of native apps for iPhone using anything other than the Apple-supplied technology – a programming language called Objective C.  It’s a really fascinating move by Apple – they’ve just bet their future on developers wanting to program in Objective C.

Almost exactly two years ago, I asked the question on this blog – “Did Apple Make A Mistake Choosing Objective-C For The iPhone SDK?” It was a controversial post in the Apple community, but my suggestion at that time was that Apple consider releasing iPhone SDKs in other programming languages, because Objective-C was not a popular programming language.  A little over a year go, while Apple had not done anything to address this issue, third parties had stepped in to meet this need, with solutions available to enable developers to build native iPhone apps using the more popular languages C# and JavaScript.

As of today, Apple has made it crystal clear – if you want to develop native iPhone apps, you will write your code using Objective-C.  Apps built using other languages, including upcoming technologies that would let people build apps using Flash authoring tools, are now banned. Such apps will no longer be accepted into Apple’s App Store.  As I said at the top of this post, John Gruber has posted an excellent analysis of Apple’s “reasons why”.   However, I think this move represents a significant risk for Apple in the medium term. In the rest of this post I’ll try to explain why.

First, a bit of background about my programming experience, so you get a feel of where I’m coming from (last time I posted an opinion on this topic, some people asked – “What do you know about programming?” – so, this gives a flavor).  I started programming as a kid, and over time I’ve built software using quite a few programming languages. In chronological order of learning these languages – from memory, off the top of my head, the list is: Sinclair BASIC, BBC BASIC, FORTRAN, C, Perl, C++, Visual Basic, SQL, Java, JavaScript, Python, PHP, C#.NET, Objective-C, and JavaFX Script.  My software has run on everything from high-precision robots and mobile phones; through home computers and Windows and Mac corporate desktops in trans-national corporations in the US, Europe and Asia; high-performance 3-D graphics workstations in almost all the world’s most important research organizations, including e.g.  Oxford, Cambridge, Harvard, Stanford, MIT and NASA; to high-end UNIX servers, mini computers and high-performance parallel super computers. Today, in my companies we have technical focus areas in: Java (client and server); SQL (server); C# (client), C (embedded),  JavaScript (client), Objective-C (mobile client) and JavaFX Script (client).

Now, each of the above languages has its merits; but each also has its downsides.  However, there’s no doubt that it’s possible to create great software in many languages.  It’s equally true, however, that particular languages (both syntax and language features), their associated APIs and tool chains massively affect developer productivity for particular types of project. Developer productivity really matters. The higher the productivity of the developer, the faster a product reaches the market, the less time is spent on fixing bugs, and the more time is ultimately spent on making the product fantastic.

Let’s focus on just one type of project: creating a great app for a powerful smart phone (the kind of phone where users install and use large numbers of apps – not just the odd game which they never play).  Which is the best language for this kind of job?  There’s a difference of opinion in the market.  Microsoft has chosen C# for its all-new mobile OS (Windows Phone 7); Google has chosen Java for Android; and Apple has chosen Objective-C for iPhone.

Here then is the risk that Apple is taking by banning everything on iPhone but Obj-C.  What if, in the future, Java and/or C# turn out to be significantly “better” for creating mobile apps than Obj-C?  That could ultimately lead to a situation where platforms other than iPhone have the coolest, best quality apps.  That’s not just a hypothetical question about some far-off time: there’s a case to be made that this is already the situation. Compared to both Java and C#, for example, Obj-C: a) has had much less investment put into it; b) has been adopted by far fewer developers; and c) is significantly older than both Java and C#, and in truth, it feels it.  Obj-C still has some nasty hangovers from its origins in C – for example pointers, header files, manual (as opposed to automatic) memory management (on iPhone).  These are all drains on developer productivity; and the need for these features was largely taken away with the more modern C-derived languages, Java and C#.

Today, however, Apple has a strong lead over its competition in mobile. It has: the best, most highly-polished mobile OS; the best app market place; the most elegant, best-designed hardware; what looks to be the most interesting upcoming mobile ad platform (iAd); really great programming APIs; and simply staggering mind-share among consumers.  All these things more than compensate for any deficiencies there might be with available choices of programming language.  For now.  But the competition won’t stand still.  In the medium term, Apple will surely need every competitive advantage it can get, including have the best programming language(s).  With this in mind, there’s really no need for Apple to restrict programming languages for iPhone like it just has. If Apple doesn’t like the quality of the language and tool offerings from third-parties, they can always take control and offer other, more modern/productive, languages itself (just as they do with Java on the Mac, for example).  Apple is a $50B annual revenue company now. It can afford to up its game in terms of having the best ways to program its phones, and to hedge the risk of backing the wrong horse; and I suspect it might need to if it wants to keep ahead of the competition.

PS

By the way, just in case anyone at Apple agrees with me about bringing other languages to iPhone, I’d vote for Java and/or JavaFX Script (an Apple controlled implementation is fine).   JavaFX Script is hands down the most fun and productive language ever created for building visually compelling apps. From a technical point of view, it would be possible for Apple and Oracle to collaborate to make an amazing implementation of Java and JavaFX on top of the iPhone OS.  Apple could differentiate its Java / JavaFX offerings with an amazing custom tool-chain and deep API and OS integration.  Those choice of languages makes strategic sense too, in the sense that Apple already has an implementation of Java that integrates really nicely with Mac OS X on the Desktop, so it could build on an existing OS X investment. Is it gonna happen? Of course not!! Not a cat in hell’s chance! Pity

I’m sure it hasn’t escaped your notice that, this weekend, Apple released the iPad to stores in the United States.  As usual, there’s been a huge amount of coverage in the press; and Apple itself released the first day sales results so we can all see how well the launch went.  There were 300,000 iPads sold on the first day of release, apparently making the iPad launch more successful that the original iPhone launch.  Hold on though, does that make sense? Is there really more excitement among consumers for the iPad compared to the iPhone?  What do the early sales of the iPad tell us about the future success of this new platform?

The first thing to say is that, as I followed the iPad launch, and recalled the launch of the first iPhone, it  didn’t seem to me that people were more excited about the iPad than they had been about the iPhone.  However, some highly credible folks believe the iPad is going to be an unprecedented success. For example, check out the guest post on Techcrunch from some VCs at top-tier venture capital group, Kleiner Perkins. I’m not quite sure all aspects of their analysis are entirely accurate: at one point in their article, they compare the pre- and post- iPad worlds, saying that pre-iPad, people used a mouse to interact with their computers… but that post-iPad, people will instead use “magic”!  Still, whichever way you slice it, there’s no doubt that iPad sold really well on its launch weekend.

For me, though, when Steve Jobs first announced the iPad, there was a billion dollar question hanging over the product.  It’s this: will the iPad appeal to Windows users in the same way that the iPhone does?  You see, there’s no doubt that Netbooks have been a huge success in terms of numbers of devices sold, and the OS of choice on Netbooks has been Windows.  If the iPad is perceived as being “better” or “more desirable” than a Netbook amongst this group of people, then a huge market awaits the product (just as there’s a huge market for iPhone).  If, however, the iPad simply becomes Apple’s “Netbook equivalent” for Mac OS X computer users, it’s destined to become only a moderate success for Apple.  Which is it?  It’s too early to tell. At launch, I suspect many (perhaps most) buyers were probably MacBook or iMac users, looking for their “Apple Netbook”.  In the coming months, it’ll be interesting, and revealing, to see how many Windows users purchase iPads…

I’ve been very remiss about blogging recently. No excuse other than I’ve been exceptionally busy as we get ready for some exciting announcements in 2010.

I hereby resolve to blog more next year! Hopefully, the new blogging app I’m using on my phone (testing it right now) will make it easier to fit blogging into spare moments.

Anyway – let me wish you a very happy holiday season! My holiday is Christmas, so it seems a good idea to test this app’s photo posting function with a festive tree…

Update: problem solved (see the comments) – thanks Sean!

OK – this post is just for the JavaFX developer crowd.  It shouldn’t be taken as a benchmark of JavaFX current or future performance…

Last night, I tweeted about the results of a quick test I did as preparation for building what I hope will be an interesting JavaFX demo application.  The reason I tweeted the results was because I found them a little surprising; and I thought people would be interested.

Now, a couple of people found the numbers hard to believe… So, here’s the code…  It’s very simple: it just inserts a number of dynamically created Line nodes (with random co-ordinates) into the scene graph:

/*

 * A minimal JavaFX program to test on-the-fly creation of

 * new Line nodes, and their insertion into the scene graph.

 *

 * You can play with different values of "n" in the run function.

 * The program will print out to the console the time in seconds

 * that it takes to create the nodes.

 */

package minimalinsert;

import javafx.stage.Stage;

import javafx.scene.Scene;

import javafx.scene.paint.Color;

import javafx.scene.shape.Line;

import javafx.util.Math;

package def stage: Stage = Stage {

 title: "Minimal Dynamic Line Node Creation"

 width: 640

 height: 480

 scene: Scene {}

}

function run(args:String[]) {

 var i = 0;

 /*

 * Set n to be the number of new Line nodes you want to add to the

 * scene graph dynamically.  Warning - when n gets more than a

 * a few hundred, this code takes a *LONG* time to run

 *

 */

 var n = 100;

 var t1: Double;

 var t2: Double;

 var time: Double;

 t1 = java.lang.System.currentTimeMillis();

 while (i < n) {

 addNewLineDynamically();

 i++;

 }

 t2 = java.lang.System.currentTimeMillis();

 time = (t2 - t1)/1000.0;

 println(time);

}

function addNewLineDynamically(): Void {

 var x1: Number;

 var x2: Number;

 var y1: Number;

 var y2: Number;

 x1 = rand(0,640);

 x2 = rand(0,640);

 y1 = rand(0,480);

 y2 = rand(0,480);

 insert Line {

 startX: x1, startY: y1

 endX: x2, endY: y2

 strokeWidth: 2

 stroke: Color.BLACK

 } into Main.stage.scene.content;

}

function rand(min:Number, max:Number): Number {

 return min + ( Math.random() * (max - min) );

}

I see the following performance with different values of n:

• n=10 , 0.02 seconds
• n=50, 0.11 seconds
• n=100, 0.36 seconds
• n=200, 1.8 seconds
• n=300, 5.3 seconds
• n=400, 11.8 seconds
• n=500 22.5 seconds
• n=600 37.7 seconds

I assume other will get similar performance when they run the code…. All of which begs the question: what am I doing wrong? As I say – this is one for JavaFX developers…

JavaFX is a new (less than one year since release) software platform for building Rich Internet Applications. Having undergone three major releases so far within its first year, it’s rapidly approaching the point where people could reasonably expect it to be a viable choice for building real applications. That might be the expectation, but what is the true situation? I wanted to understand where JavaFX really is in terms of browser-based applets. So, I set up a small test on this blog to look at the critical issue of app deployment. I asked people to leave their findings in the comments. Thanks so much to everyone who took part – I certainly found the results illuminating. In this blog entry, I’ll report back the findings of the test and what these could mean for future development of JavaFX technology. I’ll also discuss what I think the potential sweet spots for JavaFX applets could be in terms of types of browser-based apps.

Why Applets Are Important – Augmenting Browser Functionality

Before considering JavaFX applets in detail, it’s worth a moment to step back and ask the question: why are applets important? Clearly, their reason for existing is to augment the functionality of a web browser. For example: to play audio or video; or to allow sophisticated graphics for video games or other apps with complex graphics needs.

Now, many people will argue that the JavaScript/HTML/CSS is on a trajectory such there will soon be nothing the browser won’t be able to do natively, and thus the reason for Flash, Silverlight and JavaFX applets will disappear. They may be right: not having to rely on browser plugins is an highly attractive idea.

However, life is rarely that simple, and the future might not be black and white. The truth is: future JavaScript/HTML/CSS represents strong competition for Flash, Silverlight and JavaFX. What the future ends up looking like, though, will depend on how the various technologies compete. There are battles to be had in: developer productivity for creating compelling applications; and application deployment etc.

Results Of The Test

Start-up Time – Observations

First the good news – if you’re lucky with your hardware/OS platform, and you have an up-to-date install of JavaFX, JavaFX applets can start in around one second.  That’s a great result, and a huge improvement on where the Java platform has been historically.

However, what the test results really show is that the above case of super-fast start-up is very much about the future potential of the technology.  It’s clearly not where the technology stands today. In fact, the frequently observed start-up times in the test ranged from 1 second to c. 45 seconds, with start-up taking even longer than this for some people.

The applet used in the test is a small applet, about 30KB in total. Thus download of the applet itself should not be a significant contribution to observed start-up times. So, what is the wide range of start-up times due to?

It turns out that there are two major determinants of the start-up time of a JavaFX applet: 1) The hardware/OS platform of the user – which determines which version of Java and the Java Plugin they can use; and 2) whether or not up-to-date jars for the JavaFX run-time are installed, or whether they have to be updated on-the-fly during applet start-up.

For users running MacOS X, the start-up time for the Java Plug-in is slow (perhaps 8 to 10 seconds), even on new hardware. On Windows hardware, the corresponding start-up times are between 1 and 5 seconds.

For users that don’t have the latest JavaFX jars installed, depending on broadband speed e.g. 2Mbps, 5Mbps, it will typically take between 15 and 30 seconds for the 14MB or so of data to be downloaded.

Clearly, those end-users of apps that are worst off are people using Mac OS X and that don’t have the latest JavaFX jars.

Rendering  & Other Bugs

Certainly on both Windows and Mac OS X, there can be terrible rendering bugs in JavaFX applets when the web page in which the applet is embedded is scrolled. On Windows, sometimes the web-page stops rendering immediately after the embedded applet, so all content below the applet is lost. JavaFX applets don’t work at all in the Opera browser or in Safari 4 on Windows.

What Role Can JavaFX Applets Play Today?

The rendering bugs in JavaFX applets are sufficiently bad as to make applets embedded in web pages that are likely to be scrolled an unacceptable choice for developers. That rules out applications like fancy embedded graphs and charts or embedded video players.

The variation in likely start-up time for a JavaFX applet – anywhere from 1 second to 45 seconds – without a good way of communicating what’s going on to the user – mean that only categories of app where the user is prepared to wait 30 seconds or more for their application to start are going to be possible choices.

The above suggests that the sweet-spot for JavaFX applets today is for building creative, browser-based video games. The elegant  JavaFX programming model should make it productive to develop interesting  games on short timescales.   As an example, here’s a preview of a neat JavaFX game called Pastello which is heavily inspired by the popular indie game, Crayon Physics (I really recommend clicking through to Pastello, by the way – it’s an impressive piece of work).

Driving next stage of JavaFX adoption

Casual games are, of course, an interesting and substantial category.  However, if that’s all that JavaFX applets can achieve, I think we have to say they’ve been a failure.  That’s because it will mean JavaFX applets wouldn’t have moved the Java platform forward – the truth is, regular Java applets have always been pretty widely used for browser-based video games.

How then, to drive the next stage of adoption for JavaFX applets?

Rendering bugs on scroll must be fixed in order for JavaFX applets to take off for visualization applications. The variation in start-up time means that users expectations must be managed. As a first step, it will be important to let the user know it might take up to 45 seconds for the app to start up if they’re on a Broadband connection, and even longer if they’re on dial-up. However, that’s very much a workaround.  What are really needed are progress bars that can be shown embedded in the web-page (and styled by the developer) to indicate download progress.  Indeterminate progress indicators – like the spinning animated gifs developers can use now – are useful; but they are a really poor second choice to determinate progress indicators for long JavaFX start-up times that will have to be accommodated for some time yet.

Conclusion

Hopefully, the JavaFX and Java SE teams have been aware of all the issues brought to the forefront by this test for some time; and they already have solutions in the works. If not, I hope they take on board the clear findings from this test, and the likely consequences for JavaFX adoption: that is, rendering bugs and long start-up times with no effective progress-indicator-style feedback will put a massive brake on developer adoption for JavaFX applets until these issues are addressed.