Hi Wade,

I agree, desktop isn't going away. At DukeScript we're using HTML4J Apis mainly 
for desktop applications. The Java Desktop Application is just using a 
HTML5-Component ("browser") to render the view instead of a native or Java 
rendering pipeline. 

Since the separation of view and view logic is very clean the view technology 
can be completely replaced. In some of our commercial projects we used 
Controls4J to render the view, in others plain HTML and CSS. I've got working 
prototypes that use native controls instead on iOS and Android. Even one that 
renders to JavaFX that I sometimes use for debugging. 

And unlike Swing or JavaFX browsers are evolving at great speed and getter 
better day by day without any investment on our side. That's a great benefit if 
you compare that to the sluggish development of Swing and JavaFX that we've 
seen in the past years.  

I think that the stuff that Sean does with the crippled JavaFX 3D API is 
amazing, but think about what he could do with a really good 3D API, like the 
many that exist for WebGL. 



-----Ursprüngliche Nachricht-----
Von: Wade Chandler <wadechand...@apache.org> 
Gesendet: Dienstag, 13. März 2018 05:54
An: dev@netbeans.incubator.apache.org
Betreff: Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from 
Oracle JDK

On Mar 12, 2018 11:59, "Jaroslav Tulach" <jaroslav.tul...@gmail.com> wrote:

> "Oracle has begun conversations with interested parties in the Java

> ecosystem on the stewardship of JavaFX, Swing and AWT beyond the above
>>>> referenced timeframes."
The official announcement is here and people are finally starting to realize 
the truth: There is no future for JavaFX, AWT and Swing. Nobody will sponsor 
development of anything new for these technologies. Even if they get transfered 
to their new owners, they will be in maintenance mode:
Bugfixes and little features. No bigger changes - no new rendering pipelines 
using new nifty features of graphics cards. Just sustaining. I've been 
explaining this would happen since 2012.

To help us out of this situation and save Java as a programming language I 
dedicated my days to smoothing out interoperability between Java and JavaScript 
with the goal to reuse the most flexible and portable rendering system of these 
days: the browser. My work has already been donated to Apache, see: 
https://github.com/apache/incubator-netbeans-html4j - let's use it to build new 
features of NetBeans and other future Java desktop applications. Get started by 
reading Javadoc at http://bits.netbeans.org/html+java/

Forget about AWT, Swing and JavaFX - the future is HTML. In case you still care 
about Java, then your future should be Apache HTML/Java API!

Personally, I feel if that is true, then why all the hodgepodge, and why not 
just Electron which is already driving window creation and interacting with the 
desktop? Then, why not wasm and a real type safe language, and not TypeScript 
nor JS? Or maybe just VS Code plugins?

Why use the browser for all that if there is a desktop need? I mean, is it just 
me, or does that all just feel wrong?

Look at how many resources the Slack and VS Code apps need just running a few 
simple things, and they exist how they are, and are successful because people 
want to use the desktop app, and not tabs in their browsers. Then there are all 
the tricks to access the file system indirectly.

I don't see the desktop app disappearing for specific types of applications, 
and IMO that includes IDEs. Who wants to do all that work in browser tabs? 
Nobody. Electron is a desktop app environment. It isn't a container or a 
browser bound environment even if a browser is a component.

So what is the benefit of doing away with better rendering pipelines and direct 
resource access just to wind up manipulating a slow and bloated DOM in its 
place? Folks should checkout things Sean Phillips is doing with Java FX inside 
NB RCP Swing.

I think IntelliJ shows that a successful Swing based product can be a winner 
just as NetBeans has, and doesn't seem to be slowing down nor changing 
directions. To me it seems more feasible to support Swing itself for our needs, 
and continue making NB and NB RCP unique if we can be involved. Otherwise, 
isn't it VS Code or Eclipse Che ideas, just far behind?


To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:

Reply via email to