Is JavaFX Dead?

[Mike London]

Bear Bibeault wrote:

Stevens Miller wrote:(don't anyone tell Bear I haven't read his book yet    ).

Bear, please don't be offended, but after being in the receiving end of many of your (excellent and helpful, but sometimes just a bit "brutal") posts, this image is exactly how I thought of you

Happy Holidays.

- mike

[Mike London]

Bear Bibeault wrote:Devil's advocate: as you are already familiar with web technologies, why bother with desktop apps at all? Any app that doesn't need to directly interface to resources on the local machine (vast majority) can be delivered as a web-faced app if that's tech that you are more comfortable with.

OK, but this begs the question....what's the quickest way I can stand up a Web app?

Node.js?  Lots of interest (hype?) with Node, lately.

------

A Servlet does have access to the file system so a "Web app" could still do desktop type tasks.

With Java web apps (not that you don't already know all this), there is a lot of other stuff you have to do: JSP and HTML/CSS/JavaScript & JavaScript frameworks/Java code itself/DAO possibly/The Database layer. Or, stir in some Java frameworks for (lots of) extra time and complexity. Spring, Hibernate, etc..

I have found that Java is a great tool but its real home from my experience is in the enterprise or with companies with serious budgets.

For smaller shops, a faster tool is needed.

Suggestions?

Thanks Bear.

ROAR!

- mike

[Dave Tolls]

Well, what sorts of apps are you intending on producing?

[Bear Bibeault]

Mike London wrote: this image is exactly how I thought of you

Mike London wrote:OK, but this begs the question....what's the quickest way I can stand up a Web app?

Stevens hit the nail on the head. If you have a good model layer, the UI is interchangeable. My approach is to have that good model layer, put a RESTful API on top of it, and voila! you have your data layer available to any client front end.

Node.js?  Lots of interest (hype?) with Node, lately.

Viable, but a large new ecosystem to learn. I still do my back-ends in Java.

A Servlet does have access to the file system so a "Web app" could still do desktop type tasks.

Only if the server is running on the local machine (which is a viable, if niche, scenario).

With Java web apps (not that you don't already know all this), there is a lot of other stuff you have to do: JSP and HTML/CSS/JavaScript & JavaScript frameworks/Java code itself/DAO possibly/The Database layer. Or, stir in some Java frameworks for (lots of) extra time and complexity. Spring, Hibernate, etc..

Well, the client-side technologies you listed are independent of the backend choices, so you have to deal with that in any case. I'd also argue that JSP is pretty much deprecated at this point if you are focused on RESTful APIs and JavaScript SPA frameworks. But yeah, my point is that you are already familiar with the Java ecosystem. Pick and choose which you need. Hint: you rarely need to use them all -- use the ones that make the job easier, not just more complex.

I have found that Java is a great tool but its real home from my experience is in the enterprise or with companies with serious budgets.

See above. Use what you need; not everything that's available needs to be used just because it's there.

For smaller shops, a faster tool is needed.

For my contract work, I'm a smaller shop (as in one). Java works for me. Again, you can make it as complicated as you want, or keep it as simple as you want. (For example, I've never used EJB, or (good grief) JSF -- to me, complexity far beyond the benefit. But don't try to take JPA away from me for DB access!)

You could look into the NodeJS ecosystem, but I'm not sure you'd find it any simpler, especially if it's brand new to you. Caveat: I've not used it extensively myself -- my JavaScript expertise has focused on the client.

[Mike London]

All sounds good. Yes, I'm really into Restful APIs if you mean a RESTful web service like something out of an O'Reiley book. I've stood up several web services like that (REST easy or whatever it's called.)

For one project where I used (eek!) FileMaker for a client (a super fast way to do a quick app), I externalized the number crunching routines to the web service since FileMaker's "Scripts" are pig-slow.

To your comment about JSF, I agree. I had tried to work through the 3rd edition of the "Core JSF" book. However, there was a JavaScript section that did not work as expected. No one on the JSF forum was ever able to answer the question and the author's website had a bug where it didn't accept questions, at least back then. Thus, it didn't seem to me at the time that JSF was that widely used though I'm sure there is a vocal group out there somewhere.

Appreciate your excellent and quality reply.

And, I didn't even get ROARed at (this time)!

Thanks again, Bear.

mike

[John Damien Smith]

> Seems Oracle isn't really committed to FX

Well, it probably isn't Oracle's number one corporate priority :-)
That said, Oracle do commit to it.  Very few of those committers don't work for Oracle.  The level of commitment is non-trivial.

> to FX given, as you said, it's a graphical environment and they're not supporting the only tool they offer to create GUIs (out of code).

Oracle don't offer SceneBuilder.  
They created it and open sourced it, which was a very large investment.
Now it is maintained as an open source project distributed by Gluon http://gluonhq.com/labs/scene-builder/ (who offer support for it).
From my use of SceneBuilder, it is pretty complete, bug-free and straight-forward to use, so there isn't much need for it to be actively developed, at least at the moment.

> I just want an "IDE" where I can drag fields to where I want and be done with it. Even the Scene Builder requires you use layout manager

SceneBuilder doesn't require you to use a layout manager.

Just put everything in a standard Pane - that doesn't do any layout at all if that is what you want.  You lose some of the advantages of automated layout panes for developing resizable UIs, but if that isn't important to you, then it doesn't matter.

I haven't used Matisse and don't program in Swing, but my guess is that the workflow will be pretty similar in SceneBuilder using a Pane versus Matisse using a JPanel as Steven outlined his use of it: "just lets me drag and drop the Swing controls I want from the toolbox onto a JPanel and they just stay where I put them".

[John Damien Smith]

> OK, but this begs the question....what's the quickest way I can stand up a Web app?

IMO (for a Java based app), use one of the newer generation micro service based Java architectures:
 * DropWizard (simpler, more opinionated, less configurable - if you are fine with their tech choices, then easy way to start).
 * Spring Boot (current industry standard, relatively mature, accessible to those familiar with Spring, reasonably complex).
 * WildFly Swarm (less used than Spring Boot, newer, less mature, accessible to those familiar with JEE, reasonably complex).
Even with the "reasonably complex frameworks" if all you need is a REST API on top of a database layer (which is really what many back-end apps are), then setting up such a thing following common tutorials should not be overly taxing.

Which such a setup, you code the backend to a network style server API and write the front-end using the GUI tech of your choice (HTML/CSS, JavaFX, native Mobile App, whatever).

An advantage of these newer style micro service based systems is that they are pre-configured with a workable library stack and reasonable configuration defaults which makes getting basic Java server applications up and running simpler than you may have experienced in the past.  The full complexity and capabilities of existing Java libraries and frameworks (such as Spring, JEE and many 3rd party extensions) is still there, but you only need to interact with the minimal part of it that you need.  It is why some newer startups choose these Java based technologies over some of the alternatives such as PHP, Ruby or Python based frameworks.

That said, my understanding of what you were trying to do Mike was to create a local file search utility for an OS.  For that you really just need only a client desktop app, and just writing it in a framework such as JavaFX or Swing or WPF or Cocoa or whatever is all you need for that, you don't need to create a restful web service unless you want to expose the search interface over the net, and if you want to do that, then feeding the data into ElasticSearch would probably be appropriate.  I guess, what I'm trying to say is just let the application requirements drive your tech choices.

> For smaller shops, a faster tool is needed.

JavaFX was originally designed to be that with a simple scripting language, little Java legacy, and a streamlined production pipeline to take input from Adobe creative tools.  But there was a backlash from the community over that, so that iteration of the concept never took off.  Instead, it morphed into a potential Swing replacement with the SceneBuilder for design, but not an end-to-end development system encompassing databases, network APIs, etc (responsibilities for that are expected to be delegated to existing libraries and frameworks, similar to the systems I outlined above).  As it isn't an integrated system (such as something like Delphi or Visual Basic used to be in bygone days), it is often more complex and less approachable for non-enterprise style developers *if you need a database or network backend*.  That is just how it went...

[Mike London]

Great information as always. I didn't know all the history about FX, but your post certainly explains that well.

Mostly I've been using the Bill Burke "REST EASY" (O'Reiley) web services. Yet, I would hardly call that a simple or quick implementation.

But, this conversation has "sparked" my interest in these micro architectures.

I just found a Java REST API actually called "Spark".

Looks super simple & quick.

Have you heard of that one?

Thanks again.

- mike

[John Damien Smith]

> I just found a Java REST API actually called "Spark".

No, I hadn't heard of Spark.  
It looks similar to it's Ruby predecessor Sinatra, which I was familiar with.  Sinatra is a proven framework so the underlying concepts are sound.  

Spark is simple and straightforward (simpler than the other solutions I mentioned such as DropWizard, SpringBoot and WildFly Swarm).  For somebody unfamiliar with the frameworks I mentioned, Spark would be simpler to adopt than those solutions.  It isn't as powerful as the other solutions, but it is plenty powerful for many web apps.  It doesn't have framework stuff for database access, so you will have to add that if you need it.

If it works well for you, then great.

[Mike London]

I've done a couple test services using both Spark and Spring Boot.

Both work.

I'm accustomed to Spring's complexity so I'll probably lean toward boot.

---

Now, how about that front end?

Are you aware of a good HTML GUI builder (more usable than DW) that supports things like JQuery UI and in any way, makes building interfaces quicker than doing it in code?

Thanks,

[John Damien Smith]

Are you aware of a good HTML GUI builder (more usable than DW) that supports things like JQuery UI and in any way, makes building interfaces quicker than doing it in code?

No, I don't follow HTML GUI builders.   I find it more interesting to develop complex UIs in JavaFX, but that is just me.  I've never enjoyed developing HTML UIs, so nowadays I just try to avoid anything to do with them whenever I can.

At the moment, for relatively complex HTML UIs, most people seem to go with Angular (plus a bunch of other flavor of the day supporting JavaFX libs) to create SPAs. I guess you can look into that if you wish.

[Mike London]

I tend to agree. I really dislike designing HTML also as I'm more coder/algorithm and less visual. To me, HTML has too many technologies you have to use to just display a decent looking page.

FX is sounding better again. ;)

Thanks,

[Dave Tolls]

AngularJS and Bootstrap are the things I've seen most in the past 3 years or so.

Bootstrap covers the layout, and Angular covers the data side of things.

If you want a decent UI then you need a UI specialist, pretty much whatever language you're in.  I point this out to clients all the time.
A dev is not a UI designer.  Well, very rarely...

[Mike London]

Dave Tolls wrote:

If you want a decent UI then you need a UI specialist, pretty much whatever language you're in.  I point this out to clients all the time.
A dev is not a UI designer.  Well, very rarely...

Thanks! That makes me feel better.

[Stevens Miller]

Dave Tolls wrote:A dev is not a UI designer.  Well, very rarely...

I'd like to second that motion. A great programmer doesn't necessarily design a great UI, even though the UI is implemented as a program.

Now, I would venture that a great programmer can create a pretty good UI, if that programmer keeps it simple, reads a book or two on UI design, and sticks to the basics. UI designs is mature enough that it has developed some reliable principles that can be stated plainly and followed easily. If your app can work within the limits of the most basic of those principles, your programmer can also design your UI (or you can).

But, the Web proves Dave is right: there are a lot of complicated pages out there that were written by competent coders who had no business cobbling up monstrous pages full of confusing gimcracks, animations, and other magic spells. Similarly, there are a lot of beautiful, elegant, easy to use pages that just obviously were not the afterthought of a programmer with some spare time. (And, also, there are quite a few good, simple, perfectly functional Web pages that any good programmer could have created.)

As we lawyers say, keep it in your own wheelhouse, and you'll be okay. When you notice you're getting anxious about whether or not you know what you're doing, it's time get some help from someone who knows what you don't.

[Dave Tolls]

Stevens Miller wrote:
Now, I would venture that a great programmer can create a pretty good UI, if that programmer keeps it simple, reads a book or two on UI design, and sticks to the basics. UI designs is mature enough that it has developed some reliable principles that can be stated plainly and followed easily. If your app can work within the limits of the most basic of those principles, your programmer can also design your UI (or you can).

A couple of years ago me and another contractor had to cobble together an in-house web-app for a client.
The initial concepts were simple, but as the project ran on more and more extras were asked for and, neither of us being UI designers, the result became more and more cluttered...

It was...functional...by the end.  And the colour-scheme was ... interesting.

But the backend file crunching worked marvellously!

[Stevens Miller]

Dave Tolls wrote:A couple of years ago me and another contractor had to cobble together an in-house web-app for a client.
The initial concepts were simple, but as the project ran on more and more extras were asked for and, neither of us being UI designers, the result became more and more cluttered...

There's certainly a lesson in that. I'd call it a version of "feature creep." The hard part in that scenario would have been telling the client that the UI had grown to the point that it called for specialized talent (in other words, it had become more expensive), without the client losing faith in you. In fact, that would be a reason for a wise client to acquire more faith in you, as it would have meant you knew enough to recognize the need for a specialist. But, alas, not all clients are wise...

[Dave Tolls]

I did.
I suggested that since they had a UI department (which handled their customer facing website) that maybe they might borrow one of them for a week to do a mock up.

No budget, and they were happy enough with the front end as it was.  It really was a secondary aspect to the project (which was all around file crunching), and a significant improvement on what they had...still...it wasn't pretty!
The creep was entirely front end, as in more and more data they wanted to be able to pull up from the crunching, so it wasn't much work, other than being a bit unattractive.

[christohper sarama]

Thought I'd chime in. Java is going where the money is. Right now everything is going cloud and web based. That being said desktop applications aren't going away anytime soon. Web browsers lack power and perform poorly in high demand graphical applications. Of course as time goes on and technology gets better I'm sure more powerful hardware and software will be developed for web applications. Then there is the need to do OFFLINE work. Some people forget the internet doesn't exist everywhere and isn't always up and running.

Right now desktop applications are secondary so Java put FX on the back burner. It's not abandoned and will be with the JDK for another 10 years easily.

Desktop applications are still my favorite but I'm only a hobbyist developer. If you're going for a career in application development I'd suggest you pick up JavaScript , HTML5 and PHP. Those three are in high demand.

[Campbell Ritchie]

CS: welcome to the Ranch

[William Kida]

Karthik Shiraly wrote:"... can't remember even a single java desktop or applet application that became popular with the general public, even in the heydays of Java and desktops."

Scottrade uses applets.

[kavin savvy]

Tim Moores wrote:I don't think the open source nature of it makes any difference at this point. Client-side Java is dead in general, irrespective of the framework it runs. Security concerns of the JVM have finished it off. Some companies may continue to use it internally on carefully controlled and updated machines, but not for anything that's meant for the general public.

I don't like angular 2 or React for developing front end web application or website.

Do I have any choice in Java echo system? Answer is resounding NO...JSP or JavaFX almost on last leg...

Java is now backend language.

[Pete Letkeman]

If JavaFX is dead, then what do you suppose that means for NetBeans IDE which uses JavaFX?
Than again, maybe NetBeans does not use JavaFX or Swing. I do not know for certain as I have not looked at the code.
However there are some Oracle supplied tutorials on Oracle's web site which try to teach one Java concepts and such.

[Arturo Fern]

WOW what a confusion hahaha. Alright guys this is what's happening, this thread is kind of confusing. Like me, many other students persuing bachellors in Compurer Science are probably wondering, cause imagine, we need to learn either Swing or FX, and now everyone is saying FX is dead others not, etc... other thing... the books for FX SUCK! waoh... they do..

So I stared to learn FX like 2 months back, my school mostly uses swing, what do I do...? I don't want to learn a dead languege (swing?) or a future dead language (FX?) lol you see my point? hahah

[Bear Bibeault]

Whether Swing or JavaFX are dead is kinda irrelevant to your studies. What you learn about GUI programming will be useful and applicable to other languages and GUI systems.

[Pete Letkeman]

Arturo Fern,

That is an interesting point.

Here are a few things to note:

JavaFX is newer technology then Swing.

Just because a language is dead that doesn't mean that there is no value in learning it. In fact one could become the expert in an area (not necessarily Swing or JavaFX) and once you join the workforce could be well compensated for your skill set.

r
Here are a couple of other posts in this site which talk about learning JavaFX vs learning Swing:

https://coderanch.com/t/683031/java/Swing-worth-studying

https://coderanch.com/t/683429/java/learning-Swing-applets

Recently, Joel Murach wrote a book with Java 8 and Java 9 in mind yet he still covered both JavaFX and Swing

https://coderanch.com/t/683419/java/Murach-Java-Programming-book-Java

https://coderanch.com/wiki/683057/books/Murach-Java-Programming-edition-Joel

Personally, I think that you are better off to learn JavaFX then to learn Swing.
That said, it does seem like more and more programs are using some sort of web interface to display JavaScript, CSS, HTML etc instead of a GUI framework like JavaFX or Swing.

I'm not too sure if I helped or hindered with my answer to your question, but hopefully it helped.

Edit: Grammar fixed

[Arturo Fern]

Bear Bibeault wrote:Whether Swing or JavaFX are dead is kinda irrelevant to your studies. What you learn about GUI programming will be useful and applicable to other languages and GUI systems.

So you suggest I learn swing since it has more material to help me in the studies?

[Bear Bibeault]

Do you get to choose, or is it specified by the curriculum? I don't have a suggestion for either (I'm a web guy -- haven't written desktop GUIs since before the web was around), but my point is that learning any GUI system is helpful in learning how GUI systems works.

[Arturo Fern]

Bear Bibeault wrote:Do you get to choose

Some let you

[Pete Letkeman]

I agree with Bear in that learning GUI and UI/UX is a great thing to do and it will help you learn the language of choice as well.

That said, not everyone can create an elegant and/or useful UI/UX (front-end) for the project that they are working on for a number of reasons.
Just like not everyone is able to create an efficient/useful back-end for any number of reasons.

Oracle has resources/tutorials on their web site on how to use both Swing and JavaFX.
Aside from that Oracle has supplied NetBeans IDE which supports both Swing and JavaFX and I suspect that NetBeans IDE uses either Swing and/or JavaFX internally.

[Arturo Fern]

Honestly I built a calc (my first gui) in javafx, I was looking at swing and it's like going from java to c++ for the first time or python to java lol. I'll stick to FX

[David Garratt]

Mike London wrote:Thanks...your reply is appreciated.

I guess it's still the bad taste in my mouth from Swing all those years ago, but I really dislike all the layout manager nonsense. Well, I know it's not nonsense since layout managers let you build stuff in code, but I just want an "IDE" where I can drag fields to where I want and be done with it. Even the Scene Builder requires you use layout managers.. Yuck.

(The 1200 page Learn Java FX book doesn't cover Scene Builder I don't believe except maybe to ... mention it.)

There has to be a more straightforward, less frustrating, and fast way to build user interfaces than "Layout Managers".

-- mike

Totally agree with this.

[Stevens Miller]

David Garratt wrote:

Mike London wrote:There has to be a more straightforward, less frustrating, and fast way to build user interfaces than "Layout Managers".

Totally agree with this.

Well... Over the years, I've learned to read, "there has to be..." as though it said, "I wish there were..." The fact that something is painful does not imply a painless alternative exists.
Now, as it happens, I have been working in Unity (the game engine) for the last year. This issue arises there, too, as all games have some kind of UI, and you want your game to run on as many platforms with as many screen configurations (resolutions, that is) as it can. So even Unity has layout managers. They tend to be a lot less complicated that most of the ones I have dealt with working Java, though one can pick and choose there.
Seems to me that managers arose from the fact that when people started dragging and dropping controls onto forms in large numbers for the first time (I'm think of the '90s, when Visual Basic really took off), we all noticed how great it all looked until we resized the form. Dumb VB just left everything where it was, anchored to the upper left corner. You either got a lot of blank real estate (if you form got bigger) or you lost something to clipping (if your form got smaller). Making controls move and change size became necessary to avoid those effects. No one wanted to write code to do that over and over for every application, so libraries to do it came into being and, voila, you had layout managers.
What happened next was inevitable because one size never fits all. It became clear that when a form got bigger, you might want to allocated the new space to field that could use, while leaving other controls at a fixed size. A button next to a textbox, for example. Next observation might be that a fixed size still caused problems when the form got smaller, so we replaced "fixed" with "maximum" and "minimum." What about space between controls? Did we want that to grow and shrink proportionally, or did we want it constant at all times? And, whatever it was that we wanted, one thing we did not want was to have to write code to do all this.
To me, then, the presence of a layout manager seems as necessary as anything else that is integral to the operation of an application. But working with Unity has taught me that layout managers can be more straightforward than I had previously thought, if I approach my UI like I approach coding: be modular about it.
Unity's managers tend to let you spread things out evenly either vertically or horizontally (or in a grid). You can either grow/shrink them, or let them stay fixed in size when your form changes. Turns out that, if you nest rectangular containers in a hierarchy, these options permit you to create a UI that does (as far as I have seen) pretty much what any UI could ever do with any layout manager you would want to use. Modern layout managers have a bad reputation because, I believe, they were written by people who thought they could support whatever layout policy a designer had in mind without nesting anything. As OOP programmers, though, we should naturally comprehend hierarchical systems. So, if the top part of your screen is a fixed label and the bottom is a variable sized input, deal with each of those as an opaque unit. Within each, lay out its controls and nested containers again as opaque units. Continue down the nesting hierarchy until you get to the leaf node in all cases and, by golly, you'll have a rich UI that uses lots of simple layout policies, all of which collectively achieve what some of the single-layer monstrosities do, but it will a lot easier to understand, and far easier to maintain, any monstrosity ever is.

As always, that's just my US$0.02.

[David Garratt]

I'm sure the purist's will cringe but I've done all of this using WindowBuilder Pro and the absolute Layout. I found that using Metal look and feel eliminates most of the operating system specific quirks and saves me a lot of time. I don't really have a problem with the Java Layout managers as much as I do for the tendancy these days by the newer maven command line / xml driven frameworks to do everything from command line. For me the tweak/compile/test cycle would drive me nuts. (well - more so - at least.)

This is my project and the gallery page shows a few of the screens. it's all MDI

Dave

[David Garratt]

Forgot link http://www.commander4j.com

[Campbell Ritchie]

Good to see you back, Stevens