The Case for JavaFX & Emulated L&Fs (across iOS, Android etc.)

[Scott Palmer]

As long as SceneBuilder is maintained I'm all for FXML. It is entirely useless without SceneBuilder though, and doing complex UI layouts without SceneBuilder is a pain in the butt.
I have no issues with CSS either. There's no need to keep inventing new ways of doing what CSS does. It's much easier to use it to customize the look of an app than to go the Swing route and have to do all the ugly details in Java code.
Good IDE support for editing CSS can mitigate the issues caused by not having the static type checking. CSS isn't perfect, but coding LnFs the Swing way just means it's never going to happen for most apps because it isn't worth the time.

Scott

> On Jul 29, 2015, at 5:07 PM, Tomas Mikula <tomas.mikula at gmail.com> wrote:
> 
> I share your view of FXML and CSS. I will not shed a single tear if the
> support for them is dropped tomorrow. My main problem with CSS is that it
> lacks any sort of static "type" checking.
> 
> Tomas
> 
> On Wed, Jul 29, 2015 at 7:36 AM, cogmission (David Ray) <
> cognitionmission at gmail.com> wrote:
> 
>> The argument against emulated L&Fs hinges on one point: That they will
>> "always" be one step behind.
>> 
>> This (Greg Brown et al.) is a fallacy!
>> 
>> The reason being is that companies like Apple and Google count on
>> "affinity", acculturation, and familiarization with a given method of
>> presentation in order to increase patronage!
>> 
>> It is *not* like these companies change their L&Fs with every new release.
>> You are confusing language/application features with presentation formats -
>> which *do not* change at the same rate. Apple has changed its iOS widget
>> set twice in the last ~10 years! (while features do in fact change) ...and
>> let's not talk about the speed of Android feature uptake; let alone actual
>> GUI widget-set changes?
>> 
>> Yes, Oracle can indeed keep up with L&F changes - *easily*; and they do not
>> have to worry about "features" so much because much of that is passed to
>> implementation developers.
>> 
>> Another point.
>> 
>> HTML 5 usage idioms suck. (Sorry, I feel strongly about this). The whole
>> idea of spreading L&F configuration across 2 or 3 different formats is
>> ill-conceived and painfully over-verbose! (Yes I'm talking about FXML,
>> BXML; CSS etc...) The fact that it allows designers  to function
>> autonomously is also a fallacy. I have never seen this play out in actual
>> practice - as time-to-market doesn't allow the creation of "perfect code"
>> (in terms of separation of concerns) - because developers cost too much
>> money; and while companies want expressively rich UIs - they are
>> concordantly not willing to pay for it. (unfortunately - I have seen this
>> over and over and over again).
>> 
>> Back to the point...
>> 
>> Spreading the UI definition across language formats means the developer has
>> to learn more than one format to get the job done - thus invoking the
>> eventuality; "Jack of all trades; Master of none." This also makes
>> maintainability dependent on local convention (which is absurd and not
>> dependable across implementation entities).
>> 
>> The only thing it (FXML, BXML) is good for is automatic GUI builder
>> implementations; and it should be left at that.
>> 
>> CSS is not intuitive (as is a GUI widget toolset API; in the language of
>> implementation). Mastery depends on memorization (which is a losing
>> proposition for uptake); instead of intuitive insight across consistent
>> methods of accomplishing tasks.
>> 
>> I think in our field, if something is said often enough - it starts to be
>> accepted as truth. I for one would like to stand up against some of these
>> misnomers.
>> 
>> I apologize for my emphatic expression of these points - I have been
>> holding this in for a long time :-P
>> 
>> --
>> *With kind regards,*
>> 
>> David Ray
>> Java Solutions Architect
>> 
>> *Cortical.io <http://cortical.io/>*
>> Sponsor of:  HTM.java <https://github.com/numenta/htm.java>
>> 
>> d.ray at cortical.io
>> http://cortical.io
>>