What are the benefits of ScalaFX besides adding syntactic sugar for bindings?

Question

I am trying to implement a simple note organizer with some mind mapping functionality using JavaFX and Scala.

I am trying to decide whether I should call JavaFX code directly from Scala or via ScalaFX ? I don't know if it is worth to learn ScalaFX and would it not be just simpler to directly call JavaFX from Scala code?

The official ScalaFX site mentions 4 benefits of ScalaFX:

1) Natural Language Bind Expressions

-It's nice but I don't really plan using bindings that much (I intend to use EventBus for inter--gui-component events and a few bindings for intra-gui-component events).

2) Tailored Animation Syntax

-I don't plan to use animations in my project.

3) Full Type-Safe APIs

This may seem like an insignificant point… Type safety is something that Java developers have always had (and often take for granted), and developers in other scripting languages live without (and unknowingly suffer with runtime errors as a result). However, it is a critical feature if you are developing applications that cannot have unexpected runtime errors and bugs after deployment.

A good compiler will be able to pick up many common coding mistakes through comparison of expected and actual types, and a great compiler (like Scala) will automatically infer types for you so you don’t have to tediouisly repeat them throughout your code.

ScalaFX gets the best of both worlds with a scripting-like DSL syntax where you can rarely have to explicitly type objects, with the strong type-safety of the Scala compiler that will infer and check the types of every expression and API call. This means less time spent debugging weird code bugs and misspellings, and higher quality code right out of the gate!

-This seems interesting ! But my question is: I suspect that calling JavaFX directly from Scala gives me the same type safety guarantees as calling JavaFX via ScalaFX, or not ? I don't know.

4) Seamless JavaFX/ScalaFX interoperability:

-If I call JavaFX directly from Scala then I don't have to worry more about interoperability issues than when calling JavaFX via ScalaFX.

In summary:

It seems that point 3 is the only one that might give me some benefit that I care about in my simple project but I just don't know what kind of type safety they are really talking about ?

Why is it better to call JavaFX via ScalaFX than directly from Scala with respect to type safety ? What kind of additional type safety benefits do we get if we use ScalaFX instead of direct access from Scala ? I am asking this because I cannot really imagine what kind of additional type safety ScalaFX could give ?

So, in other words, I understand that ScalaFX is a nice syntactic sugar for bindings but does it offer more than that ? Should I really use it if I can live without the (very nice) syntac sugar it gives?

Is there something else than the sugar that would make it worth using this wrapper layer (ScalaFX) which introduces extra complexity (and source of bugs) ?

Please note that I really appreciate the work of ScalaFX's creators ! I am only asking these questions to be able to make a better informed decision.

Answer 1

ScalaFX is a DSL for working with JavaFX. Offering, what you call "syntactic sugar" is the main purpose of a DSL.

(A DSL traditionally also limits the scope of the host language to the target domain, but that is usually not desired of Scala DSLs.)

Now, how and when that is useful, is a debate in its own right, but that is essentailly all that it is offering. Personally ,I would always prefer an API that lets me communicate my intent more clearly to my peers and my future self, but that is something, that every team and project has to decide for itself. The binding syntax of ScalaFX is wonderful because Properties and Bindings are finding their way into more and more backends (even without a JavaFX GUI).

The reason why ScalaFX is advertising type-safety, I think, is not because it is a special feature of ScalaFX itself, but because it is noteworthy that using such a consice, script-like language such as ScalaFX and leveraging the power of the platform that is Scala, will still give you type-safety (which might be counter-intuitive to newcomers and people unfamiliar with Scala).

I would recommend using ScalaFX in your case ,as it sounds you are working on a small project , which mainly is focused on the user experience delivered through a JavaFx GUI ( I assume given your description). ScalaFX will allow you to iterate quickly on the GUI.

Don't worry about overhead in the beginning, your use case will hardly be a performance-demanding app. If you do need to worry about performance, why are you using Scala ;)?

The biggest downside to ScalaFX is that every JavaFX type needs to be wrapped with a SFXDelegate, which is cumbersome if some type you need is not wrapped or in the future something gets added to JavaFX and you need to wait for ScalaFX to wrap it before you can use it ( both of those are no real blockers though as firstly, it is trivial to wrap a JavaFX type (see the ScalaFX Wiki), and secondly the release cycle of JavaFX is much slower than ScalaFX's.

Answer 2

Speaking from a purely practical point of view, it's much more concise and easy to read.

I would suggest you see this for yourself, by comparing code in Java and Scla. Ther are two great examples of this:

1. The code excerpts from the book Pro JavaFX, which are available both in native Java and in scalaFX on github (There is a link to javafx code on that page).

2. Also, you can compare the code for JavaFX-ensemble with that of ScalaFX-ensemble. Again, you'll see it's less cluttered and easier to read.

As @OJKrylow pointed out, not all of JavaFX has been ported, so it does have some weak areas. This is evident in the scalafx-ensemble, where not everything has been ported into scala. If you're planning on building your own controls, then you are better off writing them in Java and then creating a wrapper object for ScalaFX.

But if you are writing a small program, as in your case, this should lower the complexity in theory. However, the lack of a standard introductory text means you basically end up resorting to the two above JavaFX resources, and looking at how they translate to ScalaFX (i.e. you can't really learn it on it's own, unfortunately). I hope this will change in the future.