Trephine vs JavaFX

[subscribe] Recent blog entries

• Simple prototypal inheritance new!
• Adventures in Rhino - setters and getters
• Site improvements - fighting with Disqus
• JavaScript task chaining
• JavaScript string building benchmarks
• Efficient JavaScript string building
• Alternative JavaScript worker thread API
• Implementing JavaScript worker threads
• Thread safe DOM manipulation
• Site improvements - CSS sprites
• Trephine worker threads made easy
• Pitfalls of multithreaded browser development
• Site improvements - reducing dependencies
• The unsplittability of XML

Live Demos

• Executing arbitrary script
• Shell commands
• File browser
• Excel data extractor new!
• Persistent client side database
• Groovy demo
• JavaFX demo
• Ruby demo

Trephine vs JavaFX

Maybe it's because they're both based loosely on Java and delivered through applets - I can't say for sure - but for one reason or another, a number of people think of JavaFX when first learning about trephine.

This article discusses trephine and JavaFX in terms of features and project goals, ultimately to determine whether the two technologies directly compete.

Note: I am not a JavaFX expert, so if any facts in this article are incomplete or just plain wrong, please comment!

Visual effects

Probably the most striking difference between the technologies (at least at first glance) is that JavaFX has a strong focus on creating visual effects (UI, video), while trephine is completely non-visual.

The goal of trephine is to expose the power of desktop Java to the web developer through a simple JavaScript api, and nothing more. For this reason, the applet portion is merely a delivery mechanism and is intentionally made invisible to the end user.

This is in stark contrast to JavaFX whose core competency is generating graphical interfaces and effects.

Target Audience

In his recent blog post, JavaFX living the applet dream, Josh Fruhlinger considers the duality of Java's pervasiveness: the Java plugin is widely available, but there is a good deal of variety across all those clients (vendors and versions). To this end he says, "As near as I can tell, JavaFX is meant to paper over that diversity."

From my experience with the JavaFX samples, in order to run a JavaFX app, the user must download and install a separate JavaFX runtime. I'm not sure what exactly this consists of, so if you have more details, please comment!

It seems that Sun's approach to handling the diversity of Java environments is to require users to install something new in order to use the platform's features. In contrast, trephine seeks to "just work" on the widest variety of platforms possible without requiring the user to upgrade or install anything.

Development and Deployment

To use trephine, all you have to do is add a <script> tag and follow the api. The Jar and core JavaScript files are centrally hosted, so there's nothing to deploy aside from your business logic in the form of JavaScript or other files (for example if you wanted to use ruby). You can even use the arbitrary script demo to develop your code, without ever firing up a web server.

By contrast, to develop a JavaFX applet, you must:

1. Download and install the JavaFX SDK
2. Learn the JavaFX language and develop an app
3. For each iteration: code, compile, run, test, debug
4. Package and sign the Jar, test
5. Deploy

Signing the Jar is optional, of course, and I don't know exactly why or when it is necessary. Several of the JavaFX samples I tried were signed, so I included the step in the list above. If you have more info on the reason for signing a JavaFX Jar, please comment!

Wrap up

Based on the goals of the projects, their intended uses, and the process by which the applications are developed and deployed, I feel that they don't compete for developer attention or for end-user adoption.

Both trephine and JavaFX supplement HTML/CSS/JavaScript in different ways, and there's certainly room enough for both.