Why JavaFX should be inlineable with HTML

I was disappointed when I found out JavaFX interpreter is not shipping in the final Java runtime. Shipping the interpreter is key to inlining script with HTML, and will accelerate adoption of this shiny cross-browser platform.

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
   view plaincopy to clipboardprint?

   1. content: [   
   2.  <?php foreach ($comment in $comments): ?>   
   3.    Text { content: "<?=$comment>" },   
   4. <?php endforeach; ?>   
   5. ]  

   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.