Announcing Visage – The DSL for Writing UIs
steveonjava | September 27, 2010I am pleased to announce the Visage Language, a domain specific language (DSL) for writing user interfaces.
User interface developers have long been neglected and forced to deal with languages and tooling that are a poor fit for their craft. At times they are asked to write user interfaces in languages originally meant for server-side applications such as C and Java. In other instances they are required to use a markup language originally meant for representing documents or structured data such as HTML and XML. These are fine technologies for the applications in which they were originally intended, but a weak substitute for declaring and representing user interfaces.
The goal of Visage is to provide a common language for user interface developers that provides the following benefits:
- Model the UI – The code should look like the user interface with a similar structure to how the resulting application will appear.
- Data Binding – All user interfaces have a backend model, so it should be easy and painless to hook this up to the UI with bidirectional integration.
- Resilient Behavior – The last thing you want to see during a customer demo of your new application is a NullPointerException. Language constructs should have deterministic, but fault tolerant behavior in all cases.
- Rapid Development – Application development should allow rapid, iterative cycles with early feedback starting right at the compilation phase.
The way in which Visage satisfies these requirements is summarized in the following table:
| Model the UI | Data Binding | Resilient Behavior | Rapid Development | |
| Object Literals | X | X | ||
| Closures | X | X | X | |
| Data Binding | X | X | X | |
| Bijective Binding | X | X | X | |
| Null-Safe Semantics | X | X | ||
| Strong Type Checking | X | |||
| Compiled Language | X |
So what does a Visage application look like? Here is Hello World in the Visage language:
Stage {
title: "Hello World"
Scene {
Text {
"Hello World"
}
}
}
This code should look familiar to readers of my blog. It is based on the JavaFX Script language with a few (proposed) syntactic additions.
For those of you who don’t know the history of JavaFX Script, it was originally designed by Christopher Oliver and called F3 for Form Follows Function. With the acquisition of SeeBeyond by Sun, this technology became the cornerstone of JavaFX and was open sourced in 2007 at JavaOne. Oracle purchased Sun and just this past week at JavaOne 2010 announced that they are going to continue with the JavaFX Platform, but replace the JavaFX Script language with Java APIs. We are adopting the JavaFX Compiler for use in the Visage project, and plan to continue evolving it.
Here are some of the goals of the Visage project:
- Provide a JavaFX Java API Binding – One of the most innovative parts of the JavaFX platform was the language, and it is what all JavaFX applications are written in today. Our number 1 project goal is to make sure that developers can continue to write declarative code and easily port over their existing applications.
- Enhance the Visage Language – The language syntax remains largely unchanged since the 1.0 release of JavaFX. We plan on making numerous improvements that will be beneficial to UI programmers and make common patterns easier to code.
- Support for Other Platforms – For the Visage language to thrive, it has to be a general purpose UI programming language. Some other platforms that are in great need of a UI DSL include HTML5, Flex, and Android.
- Language Standardization – We would like to see the Visage language be made an official standard with possibly multiple implementations.
If you are interested in following the project or helping out, please join the Google Groups:
http://groups.google.com/group/visage-users
http://groups.google.com/group/visage-dev
We would like to see the Visage language be made an official standard with possibly multiple implementations
Sounds terrific. F3/JavaFX Script is indeed an exceptional language for developing UIs, and should be continued as a JVM language for the JVM/JavaFX 2.0. Being able to compile Visage into HTML/javascript at some point in the future would also be an extremely valuable tool.
Good luck!
One suggestion: remove that null handling. It has cost me several hours fixing bugs because null was ignored. You cannot divide by zero, you cannot continue on a null.
I agree that this can be a problem, but the problem would be worse if nulls were no longer transparent. I think we’d all be surprised to see just how many null pointer exceptions are suppressed from bind statements in our UI. Removing null checks completely would likely break every UI. However I have also seen areas where suppressed null checks makes your code does nothing instead of throwing an exception which leads you right to the problem. I’m not sure of the best way to deal with both problems at the same time. Perhaps if the null checks are primarily useful for bindings and expression language statements, then Visage could suppress nulls there, but throw null pointer exceptions when found in standard Visage code – such as in event handlers and run/init/postinit sections and functions.
I like the default behavior of hiding NPEs. For UI development this is the right choice most of the time, and it dovetails nicely with the bind capabilities (where a value often starts null and updates later).
That said, I have also run across some tricky situations where having an explicit way to force a null check would have saved a lot of debugging time.
How about introducing a new operator (I propose “.!” since exclamation mark is unused) where null checks are enforced.
This would return null if content was null:
content.value
While this would throw an NPE if content was null:
content.!value
I submitted an enhancement here:
http://code.google.com/p/visage/issues/detail?id=1
This is quite relieving. I was pretty worried after hearing “JavaFX script is dead.” I though I’d have to do a major port of all my JavaFX code into Java.
Interesting. I appreciate you leverage existing code (JavaFX compiler) while changing the name because you extend the scope (and maybe because of legal issues…). I like the name too (fade to gray…).
I like the less verbose syntax (no ‘content’ variable) which is also more readable.
I disagree with Tbee, the transparency over null values is useful, but they must not be hidden, ie. a check for null should still be available (there is a Sun forums thread on the issue).
PS.: You might want to fix your title…
Not quite sure how I missed the obvious type in the title… thanks for pointing this out! (fixed)
On the NPE subject (I hate NPE, I really do) could it not be a run-time option on how to handle them?
Either, throw a NPE as in Java, log a warning or silently suppress them?
Anyways, best of luck.
Having an option to send NPEs to stdout may not be a bad idea.
JavaFx/Visage syntax always reminds me of IDL and Pov-Ray http://www.povray.org/documentation/view/3.6.1/44/.
From my perspective, I think lack of null support is problematic. Admittedly, null has no inherent semantic meaning. But there are many use cases where it is _almost_ semantic. Take river flow or temperature measurements. A null will mean that no measurement was taken, although the reason will have to be logged elsewhere. If it is a String you are storing, you will always have to have a special class that wraps the measurement and provides a facility to store a ‘no value.’ How about JDBC bindings? Null is inherently present in every (relational at least) database in the world and again, null is generally regarded as something altogether different than an empty space.
If JavaFX is to be used as was communicated to me in first order as a business UI language and not a (direct?) Flash competitor, then give us the nulls back at least for Strings or something equivalent to NaN, and that for every ‘primitive’ JavaFX class.