JavaFx is the future?

like me JavaFx with Scene Builder and NetBeans.
but i am preocupated if is a real way to develop.
i want change from Delphi(pascal) to java, but i am not sure.
wichis your advice?
if possible list tutorials: desktop app, web app, mobile app, thanks
Thanks

IMO, JavaFX is not the future. Java on the desktop had its chance, but it's been dead for most practical purposes for a long time. Sure, there are some apps that thrive (tools, mostly), but extremely few consumer apps. It's going to remain a tiny niche market. Frankly, I find the JavaFX effort baffling - a rather pointless project, IMO, that distracts Oracle from more useful things.

Ulf Dittmer wrote:IMO, JavaFX is not the future. Java on the desktop had its chance, but it's been dead for most practical purposes for a long time. Sure, there are some apps that thrive (tools, mostly), but extremely few consumer apps. It's going to remain a tiny niche market. Frankly, I find the JavaFX effort baffling - a rather pointless project, IMO, that distracts Oracle from more useful things.

I don't fully agree. I do agree that JavaFX as a technology is and will remain a niche product, but I think that its true purpose is something else - namely, replacing Java3D and providing an option for anyone wanting to implement 3D graphic applications in the browser. I think they are counting their cows (ahem) and trying to leave nothing to chance. If this takes off in some years, you don't want to be caught off guard trying to play catch-up without any experience. The current use cases are slim, but the possible future use cases are numerous. Just think of educational applications. How do you teach kids? JavaFX might well be the answer.

That having been said, do I think that this should be on the foreground now and that they should abandon half the java SE effort to fix some bugs on JavaFX? No, I don't. They're pushing it. But I definitely see why they feel gaining expertise in that field is important.

If 3D on the web takes off, I think it will be JavaScript/WebGL based. I doubt that the Java sandbox will regain the trust it has lost over the long string of security problems.

Ulf Dittmer wrote:If 3D on the web takes off, I think it will be JavaScript/WebGL based. I doubt that the Java sandbox will regain the trust it has lost over the long string of security problems.

100% agree. Java on the client is dead, and there is nothing that can bring it back. It's like trying to give CPR to a zombie.

IMHO I don't think that Java on desktop is really dead. We're currently developing and selling a swing-based ERP client application (ok, it call services to a remote
appserver, but I don't think that's the point) and I can only say that customers' users and customers' IT staff appreciate this approach.

Of course, I'm talking about a full ERP which covers a lot of business areas, and with at least an hundred forms with a plethora of information
an user can manipulate (fields, tables, multi-panel views and so on).

In our case, It would be really hard to adopt a pure web interface and maybe literally impossible to port it to smart devices (I mean tablet and smartphones) where user's limited in input capabilities.
And, most important, none of the programmers working on this project regret about this choice, even between those having a good skill in web development.

I wonder how many complete ERP have been developed with pure web based technology.... maybe ERP is part of the niches you were talking about ?
Or- and I hope not - in a few year I and my colleagues will become zombies

I'd really hear your opinion about.

i believe that unless you've got some stellar requirements, Swing is fine for erp. Don't see the benefit of Java fx for that.

Thanks Dieter for your reply. To be honest, since oracle claims that java fx will be the future gramework for graphical interfaces, I think tha one should give it a try.. just to avoid to have no alternatives in front of a dismission of swing.

Wow, a company heralding their own product as the future of the business?

I mean to say, the future for Java runtime

I have to say, as someone who really enjoys working on desktop applications (having just made myself familiar with NetBeans Platform), I am really curious to see what JavaFX is going to do. I like Swing, but some parts of it are just a big mess.

I'm afraid Ulf and Bear are correct though.

Stephan van Hulst wrote: I'm afraid Ulf and Bear are correct though.

Honestly: I'm afraid, too

My personal problem with Web programming is that I really can't help seeing it as a moving target..
To be a good web programmer, you need to study Html, Css and javascript.
Then you need to choose and study a framework like jQuery to avoid facing all those subtle differences in javascript implementation.
Once you have done, since you need Gui widgets, you have to choose and study a Gui framework.

And that's the real big mess: which to choose ? There are tons of frameworks out of there. You cannot know how long
they're going to survive.

I'm mostly still waiting for a server-side UI framework that allows you to do the UI in java, that doesn't force you to rewrite your web layer. Vaadin is great, but there are two things that disturb me with it:

1) complex layout&styling is next to impossible.
2) you have to change your approach to MVP or MVVM to fit vaadin specifically.

I myself am neither really a web nor a client programmer. I prefer the server-side stuff. Java FX seemed really nice because it doesn't limit you, though the sandbox thing is and will always be a hassle. I thought it was a great move (even though I liked their original DSL) to make it full Java, because framework support is everything. I kinda don't understand why there isn't a high-level framework for it yet. It could be fantastically simple to work with.

Claude Moore wrote:There are tons of frameworks out of there. You cannot know how long
they're going to survive.

Because Java doesn't have the same issue.... oh wait...

Hi Bear,
Of course i'm not saying that java is somehow eternal .. i just wanted to point out that the world of web frameworks is really a jungle (at least for a not experienced web programmer like me), and that's all but simple to find your way among various, appealing frameworks. When you choose to adopt and use a language ( like java, .net, or delphi for example ) you have a standard library for developing GUIs (not always of course, I remeber that at the time i used c++, there wasn't a graphical standard library). So, for desktop application, choosing a language often implies you have choosen a Gui fx as well. In the field of web programming isn't so easy, the search for a "definitive" way of coding web pages while using a technology (java, .net and so on), is like the quest for the holy grail.Swing may be ugly, java fx may be ugly, but at least they're "endorsed" by a language vendor. For the web, as far as i know, no one endorses anything, so one may be legitimate to feel lost..

Claude Moore wrote:i just wanted to point out that the world of web frameworks is really a jungle (at least for a not experienced web programmer like me), and that's all but simple to find your way among various, appealing frameworks.

And since when is having multiple, appealing choices a problem?

But yes, the field of web frameworks -- and here I'm focusing on client-side frameworks, and dismissing the server-sods dinosaurs -- is one of the most dynamic I've witnessed in my almost 4 decades in the field. What to use? AngularJS? Ember? Backbone? Without or without RequireJS? Underscore or Handlebar templates? The choices do seem endless.

When you choose to adopt and use a language ( like java, .net, or delphi for example ) you have a standard library for developing GUIs

It's even easier on the web -- you have no choice. You'll be using HTML, CSS and JavaScript (or some crap-ware that generates it for you). SO I'm not sure I see the point.

In the field of web programming isn't so easy, the search for a "definitive" way of coding web pages

See above. The fact that there are multiple frameworks you could use for building a web app is no different than the Java eco-system. They're just frameworks that you can choose to use, or not. Again, I'm not seeing your point.

but at least they're "endorsed" by a language vendor.

And HTML/CSS/JavaScript is endorsed by everybody. (Perhaps "endorsed" is the wrong word, but you don;t have much choice.)

so one may be legitimate to feel lost..

Again, I don't see it any different than choosing frameworks in Java. Hibernate? Ibatis? JPA? Spring?

Bear Bibeault wrote:
And since when is having multiple, appealing choices a problem?

Touche' !

Bear Bibeault wrote:
But yes, the field of web frameworks -- and here I'm focusing on client-side frameworks, and dismissing the server-sods dinosaurs -- is one of the most dynamic I've witnessed in my almost 4 decades in the field. What to use? AngularJS? Ember? Backbone? Without or without RequireJS? Underscore or Handlebar templates? The choices do seem endless.

It's just that which is confusing... It would a good thing if even for web frameworks a "convergence" to a standard de facto happened... I mean, just think about jQuery. It's not a standard. But it's something
that anyone should use and /or advice to use as "layer" to avoid all hideous details of browser-specific implementation.
Every time I search for "web widgets frameworks" on the net, I learn that some new fx has just arisen, and it seems the most beautiful, the most complete and so on... maybe is still a too free field,
and no one has the force to impose a standard... I just remember my very first approach with JQuery UI. I was searching for a good GridTable plugin: I literally found dozens of alternative
plugins...
I agree with you about the fact that even for Java we have different ways to do the very same thing (JPA, Hibernate, Spring). But Spring, Hibernate and so on are "alternatives" to
an "official way to do things" which is Java EE, an "umbrella" one may always take shelter under.

By the way: thank you really for your answer and sharing your opinion on this matter.

Bear Bibeault wrote:and here I'm focusing on client-side frameworks, and dismissing the server-sods dinosaurs

I think this attitude is rather too dismissive of server-side web frameworks. While Bear has stated variously that he sees development moving towards client-side JS -which is certainly happening to some degree- I don't see it happening to the point where server-side frameworks are becoming obsolete any time soon (and actually not for a very long time, if ever, IMO).

Claude Moore wrote:
I agree with you about the fact that even for Java we have different ways to do the very same thing (JPA, Hibernate, Spring). But Spring, Hibernate and so on are "alternatives" to
an "official way to do things" which is Java EE, an "umbrella" one may always take shelter under.

By the way: thank you really for your answer and sharing your opinion on this matter.

We have that. It's called JSF and these days, it's a mature framework that is easy to use, versatile, well documented and has a high level of abstraction. Coupled with its myriad component libraries, it's able to let you develop enterprise-level application at great speed, with a big backing community and a shallow learning curve. Since the introduction of pass-through JSF in Java EE 7, there is no reason why you should not develop an HTML5 prototype and use JSF only where you need it.

I'd have said that JSF was about to die ....

JSF stinks of the tar pits. It's never made any great inroads and is unlikely to in the future. Even if server-side development was still considered "where it's at", JSF is generally viewed as an over-complicated, Rube Goldberg contraption. Two of my recent jobs have been to replace JSF-laden monsters with more reasonable implementations.

And while I agree with Ulf that server-side frameworks will be around for a while, they're no longer consider cutting-edge, and up-and-coming companies (you know, the ones that are hiring the best talent and paying for it) are looking elsewhere.

Bear Bibeault wrote:JSF stinks of the tar pits. It's never made any great inroads and is unlikely to in the future. Even if server-side development was still considered "where it's at", JSF is generally viewed as an over-complicated, Rube Goldberg contraption. Two of my recent jobs have been to replace JSF-laden monsters with more reasonable implementations.

And while I agree with Ulf that server-side frameworks will be around for a while, they're no longer consider cutting-edge, and up-and-coming companies (you know, the ones that are hiring the best talent and paying for it) are looking elsewhere.

I remember reading this book a long time ago (title escapes me) where the writer said that there's always been a pendulum-type relationship between server-side and client side. Especially seeing the latest JS frameworks come up, I think it is time for the tick client to come back... Or let's call it "thin server architecture" since bosses still tend to shudder when they hear the term. But calling a cow a cow, we can go on about what is better, server or client... You're probably right that we are probably balancing more to the client again... But I've no doubt that in some years the server will come back.

I'm using JSF at the moment and looking at the old stuff that's been done here I have to say I also sometimes hide under my desk. Yet I like the things that Seam does, even though it's far too config-heavy. This is JSF 1.2. The things I've seen and done with JSF2.x using SFSB as backing beans, for a boatload of internal, transactional, N-tier applications, being able to model your stateful business process without much boiler plate, using pre-existing templates and building drop-in custom components... I can't really see why anyone who has really looked at it recently would hate it so much.

We don't need low memory footprint and million-user performance. We need high output and complex business functionality. For our purposes, I can't really think of a better framework.

Dieter Quickfend wrote:You're probably right that we are probably balancing more to the client again... But I've no doubt that in some years the server will come back.

On this we'll have to disagree; I don't think there is any such pendulum as far as web work is considered. The only reason that server-side rendering engines such as JHTML, which begat JSP, ASP and PHP came about is because there was no reasonable way to render client-side stuff dynamically on the client. So faking it on the server was the best that could be done.

With the advancement of browsers with HTML5, and the absolutely killer JavaScript engines that the browsers now have, it's no longer the case that the client is incapable of handling its own affairs.

Sure, the server-side engines aren't going away soon, but I think that's mostly just inertia -- look at how many people are still writing JSP as if it were 1999.

I fervently believe that rendering client-side presentation on the server is a mastodon, stuck in the tar, while the more nimble mammals look on from afar.

As with anything, YMMV.

By the way, I gave you a cow for reasoned and interesting discussion. I think we need more of that on the Ranch.

Bear Bibeault wrote:I think we need more of that on the Ranch.

100% agree.

Bear Bibeault wrote:By the way, I gave you a cow for reasoned and interesting discussion. I think we need more of that on the Ranch.

Thanks a lot!