Sure it is my opinion but never ever, will a FrontEnd developer using swing to 
bring it into the browser. For me, it doesn’t make sense, if you have a 
powerful language like HTML and CSS and JS to make better UIs than you can 
expect, to communicate with a REST Backend.


Cheers

Chris


Von: toni.ep...@eppleton.de
Gesendet: Dienstag, 13. März 2018 10:09
An: dev@netbeans.incubator.apache.org; 'Emilian Bold'
Betreff: AW: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from 
Oracle JDK

> We need a way to render Swing on a web browser canvas!

 We were actually thinking about doing this using DukeScript a while ago to 
allow people to run their legacy applications. It would be doable. The JavaFX 
Team at Oracle had a working JavaFX version for the browser (without Java 
Plugin). It was using bck2brwsr and my DukeScript canvas API as the rendering 
pipeline (the demo is still in the internet somewhere). The same would be 
possible for Swing.

But then we decided that it's much better if developers use a modern concept 
for UI Development like MVVM, otherwise we'll end up in a horrible niche as the 
only ones doing archaic Swing development in a world that has much better 
concepts for UI development.

--Toni
 
-----Ursprüngliche Nachricht-----
Von: Emilian Bold <emilian.b...@protonmail.ch> 
Gesendet: Dienstag, 13. März 2018 08:59
An: dev@netbeans.incubator.apache.org
Betreff: Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from 
Oracle JDK

HTML4J goes the wrong way in providing a migration path.

We don't need new ways to embed components into Swing. We could already embed 
JavaFX stuff and now we can also embed HTML stuff (rendered by JavaFX).

We need a way to render Swing on a web browser canvas!

Then, after Swing is fully in the browser we can decide that instead of having 
a canvas there just replace that topcomponent rectangle area with a div.

So, for new apps HTML4J makes more sense.

For NetBeans HTML4J only makes sense if we start a multi-year process of slowly 
migrating to HTML4J and then, in the far future, realise we migrated so much we 
might as well switch the whole main window from a JFrame to a browser tab.
  This plan would probably make sense in a corporation like Oracle, but will no 
do well under Apache, also because we would have our own technology stack that 
no contributor would use elsewhere. Mozilla also had XULRunner and people 
didn't really flock to it. 

--emi

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

On 12 March 2018 5:59 PM, 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!
> 
> -jt



---------------------------------------------------------------------
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:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists




Reply via email to