The Next Great Thing: An Application Framework

Daniel Zwolenski zonski at
Thu Feb 9 17:30:31 PST 2012

On Fri, Feb 10, 2012 at 10:15 AM, Richard Bair <richard.bair at>wrote:

> On the other hand, the more structured the application framework, the
> better tool support you can get. For example, if SceneBuilder had enough
> structure, it could show all the different pages in your application,
> indicate which actions move from one page to the next, what CSS files apply
> to which pages, what methods are available on the controller, what
> localization files exist for different pages, switch between locales to see
> what things look like, show the layout for iPad vs. Desktop vs. whatever,
> etc.
> I don't to tie scene builder to a specific app framework, unless that app
> framework is part of the platform. Other things, like validation, I think
> really wants to be part of the controls API as opposed to be completely
> standalone.

Tool support would be improved with a well defined application framework,
absolutely. But tool support doesn't require the app framework to be part
of the core library. There are some awesome tools out there (IntelliJ and
Eclipse without looking too far) that do amazing tool support around
frameworks such as Struts, Spring, GWT, Maven, JUnit, Hibernate, Guice,
Groovy, etc. These have all gained tooling support because they are
popular, not because they are part of a JDK or the like.

SceneBuilder is a bit of an enigma for most us still on this side of the
fence. Various forum topics have eluded to what it might or might not be
but I for one am not really sure. If it is just a tool for constructing
scene graphs then it should be applicable for any application framework but
won't have any of the cool features you mentioned.

If it is intended to be a full RAD tool, which can give the features you
outlined, then it is going to have to pick a particular architecture (and
possibly a remoting framework, data store framework, transaction framework,
logging framework, testing framework, depending on what we consider an
'application', which comes back to point #1). Products like Spring Roo,
Ruby on Rails, Grails, etc, are examples of some RAD tools out there
(though they tend to work off code files and not use 'Scene' drawing tools,
which might be a clue to their success), as well as examples such as .NET's
VisualStudio and I'm sure many others that do use scene builders. All of
these force an architecture and at least constrain, if not dictate, the
technologies and the features that you can use.

I'd be leaning quite strongly towards SceneBuilder not being part of JFX
directly but instead being a tool offering on the side of it. I'd also see
merit in SceneBuilder being an API that tool builders (e.g. IntelliJ,
Eclipse) could use to add scene construction stuff to their existing tool
suite, rather than a full RAD tool. IntelliJ for example would do a fine
job of plugging in a SceneBuilder that was able to map back to class files,
property files, etc - it has done all the hard work already, it just needs
a WYSIWYG editor for FXML.

On a related front, two other areas that in my mind probably would have
been better off external to JFX are:

- FXML: it is built on-top of JFX and so does not need to be part of the
core. It also implies a certain MVC architecture, and as we've seen that's
not ubiquitous (nor is the architecture style chosen particularly in-line
with at least a sub-section of the community which is an example of the
sorts of complications an Application framework creates)

- Charts: seems like an add-on that will become something of a hassle for
the JFX team to maintain, grow, support at the rate it will need, as well
as adding complexity for mobile platforms (should a pie chart look the same
on a mobile app with touch screen, no mouse over, etc).

Just my opinion, but they are the sorts of things I'm thinking of when I'm
talking about keeping the core as a core.

> But you make really good arguments for being conservative in what goes
> into the core. I think one of the things that made Swing so hard to learn,
> was that it didn't provide any structure at all.

My personal take on this is that no one bothered building a nice
application framework on top of Swing because there wasn't enough momentum
behind the platform in the early days. Swing became an unloved technology
because it was nasty (for the end user) to install/launch, and because the
default look and feel was hideously ugly. Web apps, despite being a
horrific programming model and much less powerful, took center stage
because they looked good out of the box and ran instantly. Victory was that

If Swing had gained enough popularity for the Google guys to build the
Google Swing Toolkit or for there to be a SpringSwingMVC framework, we'd be
laughing write now - churning out amazing, rich, maintainable apps every
day and life would be full of sunshine and rainbows.

For me that's what I'd like to see happen with JFX, the core libraries
focus on getting the core things really good (such as looking good, which
it most certainly has achieved, and deployment, which it most certainly
hasn't), This core then facilitates the construction of feature rich
application frameworks to solve specific domain cases for it.

What I'd really love to see instead of SceneBuilder is something more like
Spring ROO that can rapidly knock up an initial UI, database, remoting
layer, etc for me with 80% of the grunt work done magically, but allows me
to write the remaining code in code. I love the idea that SceneBuilder will
fill a need for a bunch of developers out there, but it is really for a
sub-set only, much as Spring ROO FX would be for a different sub-set.

> > The things I feel are needed for an application framework are the
> features
> > I am putting into JFX Flow <>, but this
> is
> > targeted towards web-style, online, form-based business apps.
> >
> > My feeling is that we are better off if JFX just provides a core library
> > with fundamental building blocks, rather than trying to provide a full
> > application framework that forces a specific architecture. People build
> all
> > sorts of applications, with all sorts of wonderful architectures, and no
> > App framework can cater to all. For example, the application framework
> > needed for an online, form-based business style app vs a desktop, offline
> > app (e.g. an IDE or graphics drawing program) are significantly
> different.
> I think you make a solid argument that there are different classes of
> applications. The SceneBuilder itself, for example, wouldn't make any use
> of a page-based application framework, neither would an IDE. Yet most apps
> I've written would work very comfortably with a page-based framework -- and
> those were all traditional desktop apps! A CAD program or 3D game would
> again be some other application arch-type.
> But does that mean we shouldn't provide an API for the most common
> application arch-type in the platform?

Let's say we did manage to get a consensus that the application style to
support is the page based one (probably upsetting the game programmers,
animators, desktop tool builders, little flash-like applet builders, and
creatives who just like to do things differently). I have some doubts that
we'll then get any kind of consensus on what the best application *architecture
*is to actually support this style. If you did a show of hands for support
of just the various flavours of MVP (such as those outlined in my post), I
reckon you'll get some vehement, devout, angry arguments both passionately
for and passionately against each of the options. That's before you start
looking at MVC, MVPC, etc, etc. Which one do we choose to support?

Suppose we did so, but it was in a separate module, meaning you didn't have
> to use it if you didn't want to?

That'd help, but you still have the same challenges as above, especially
the ones regarding choosing an architecture to support and not being able
to use third party.

The big question really is what are the advantages of putting into the core
library?  There are tangible drawbacks, what are the gains (apart from
SceneBuilder support)? If it is just credibility and standardisation, we
should be able to achieve that through a community consensus and group

Just my thoughts anyway.

More information about the openjfx-dev mailing list