Questions for Sun over JavaFX

I honestly don't understand why Sun felt the need to build JavaFX.  I don't think ease of development is what has been holding back Java from proliferating beyond the enterprise.

To Chui's point about Silverlight being markup capable of being generated by any server, I think that is the key.  OpenLaszlo could get to this point, but they too seem too focusedon the server-side.

The only way to stop web 2.0 from becoming the next leaky abstraction is to come up with an open UI markup language that is NOT tied to any one programming platform.

Thanks Geekycoder for your comments

1. There are tens of millions of web developers who have already been trained to edit text in a file and refresh the browser to see their changes. Let us not make it any harder.
2. There are millions of PHP developers. JavaFX can be used as a universal canvas (since IE doesn't support the canvas tag), so that you can, for instance, generate comments on this page in PHP
   

   content: [
    <?php foreach ($comment in $comments): ?>
      Text { content: "<?=$comment>" },
   <?php endforeach; ?>
   ]
   

3. We should not estimate the power of "view-source" because it allows the knowledge of a few to be leveraged multiple times. All I know about javascript and DOM is from doing this.
4. Inlining will permit existing web projects to be incrementally improved. Plugins that emit JavaFX script in Drupal, Wordpress, and other open source projects can be used to leverage adoption.
5. Inlined JavaFX markup will be spiderable. No community-based website can adopt JavaFX if crawlers can't crawl their content.
6. Inlined JavaFX brings the URL back into the equation. This ties in with 5, but in addition, allows links to content be embedded in emails, or other websites via hyperlinks. The browser is not perfect. For instance, look at the hacks Yahoo Maps have to implement in order to update the URL as you move around the map.
7. I have just lost this edit once due to MSIE's popup blocker blocking the "Insert Code" tool button. Inlined JavaFX enables creation of a better text-editing widget that can be embedded within a page. To take this further, it is the cross-platform "contentEditable" that the Two-Way web has been waiting for.
8. Inlined script can be more compact than compiled JavaFX. For mobile devices, compactness is a virtue. Here are the uncompressed sizes as a comparison.

1028 Perspective.fx
 221  Perspective$Intf.class
4283 Perspective.class
 754 Perspective$1.class

9. Interpreted script doesn't have to be slow. It is the effects which consume time. There are a few javascript coverflow effects on the web. Why not try them, and then as an exercise, implement them in JavaFX? You'd be disappointed to see that JavaScript achieves a better frame rate.

Incidentally, while I'm ranting, it'd have been better to create a class called transitions rather than animations. Effective transitions have different characteristics to timeline animations.

• During transitions, event handlers are deactivated. For instance, as a window is minimized to the dock, clicking on the moving target doesn't actually talk to the actual program window.
• Transitions are special effects. They are not "pure". Transitions is like "texture mapping", rather than "ray tracing". The scenegraph API is more like "ray tracing".
• To implement transitions with good frame rates in JavaFX requires "faux" effects. Drop shadows, transitions, etc should be approximated. This really requires working outside the scenegraph API. For example, I'd take a bitmap snapshot, precalculate a few key frames, hide the original node , whizz the precalculated bitmaps through the canvas, and then display the node in its final position. I'd suggest the JavaFX engineering team have a look at how Flex does this declaratively.

3. Is the JavaFX interpreter going to be shipped with 1.6u10? Most web hosters support PHP and not java compilers, and that means if the applets can consume JavaFX script, PHP could be used to generate UI. This can help adoption. For example, silverlight supports XAML inlined with HTML.

and Joshua Marinacci has this to say

The old interpreted version of JavaFX is deprecated. The only way to build JavaFX applications now is to use the compiler. However, it shouldn't matter what your hosting company has.  You will compile the JavaFX application on your development desktop computer and only upload the binary jars and html to the website. From the webserver's point of view they are just binary files which are served to the user, the same as images or media files.

To be honest, a language specification shouldn't have to change regardless of whether it is interpreted or not. There may be some differences in compile-time vs. run-time type checks and exceptions, but that's about it. I believe that the assumption Sun made that compilation is always better than interpretation is errorneous, and will impede broader adoption of a fine technology.

Chui,

Excellent writeup, you don't even need to go beyond #1 in your list, #1 is *exactly* why JavaFX will never become dominate.

Developers, especially smart ones, underestimate how powerful stupid-simple can be sometimes. Only time will tell, and I'm willing to bet my house and cats that JavaScript will stay dominate unless something else can come along that works in a edit/save/refresh cycle as quickly.

If you keep the compile/deploy cycle, you've immediately cut your viable user-base down to developers that are used to an IDE environment, post here at JavaLobby, and probably read Slashdot... the rest of the world will be using JavaScript while we sit here in 5 years and argue JavaFX or Air... or Silverlight... or Swing... or SWT... while everyone else continues to not care, and actually gets work done with something else we aren't discussing.

Five years ago, when developing some apps for PDAs, I'd never consider HTML + javascript. This is because there are enough form factor issues as well as browser incompatibilities to keep one awake all night. Lately, with webkit taking hold, and mobile devices becoming more powerful, it seems closer to reality.

Mobile device manufacturers do not particularly care whether you build applications in Java or HTML+javascript. All they really care about is selling more devices. Any device that can make use of existing applications (i.e. the web) is going to be important.

Just as Microsoft was careful not to break backwards compatibility from DOS to Win 3.1 to Win NT, mobile device manufacturers have a business reason to support HTML. I read this to mean browser support is only going to improve. Against this backdrop, Sun has to work very hard to woo the web development crowd, and not count on winning by default as it has in the past.