The Next Great Thing: An Application Framework

[Richard Bair]

A couple days ago I would have said "Oh ya, we're absolutely doing an app framework". But I tend to agree with your reasoning here. Except for one thing, which is that experienced developers definitely love having many different frameworks and choices, whereas less experienced (or maybe just those who aren't so bothered and just want to get on with it) definitely prefer something being available out of the box.

However I think you make a very persuasive point that at this time there are app frameworks either released (yours) or in development (Jeff Martin's) and undoubtedly there will be more, and that perhaps we ought to spend our energy at Oracle in solving the part of the problem that only we can solve -- deployment and basic app lifecycle (such as is required to wire it all up to the native OS app lifecycle stuff).

Richard

On Feb 9, 2012, at 5:30 PM, Daniel Zwolenski wrote:

> On Fri, Feb 10, 2012 at 10:15 AM, Richard Bair <richard.bair at oracle.com> 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 simple. 
>   
> 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 <http://www.zenjava.com/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 effort. 
> 
> Just my thoughts anyway. 
>