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.
--Toni
-----Ursprüngliche Nachricht-----
Von: Wade Chandler <[email protected]>
Gesendet: Dienstag, 13. März 2018 05:54
An: [email protected]
Betreff: Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from
Oracle JDK
On Mar 12, 2018 11:59, "Jaroslav Tulach" <[email protected]> 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?
Wade
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
