Thanks a lot for your opinions! I am going to react to one recurring theme
in this email...

2018-03-12 16:59 GMT+01:00 Jaroslav Tulach <>:

> 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!
First of all I have to admit it drives me mad, how incapable I am in
communicating these ideas. How could I be the initial architect of
NetBeans, when I am not able to explain what HTML/Java API is beneficial
for? Or was I just the architect and there had to be others to handle the
public relations? Or was the success of NetBeans (Platform) just an
unrepeatable luck?

Anyway, there have been few references to Electron framework in your
reactions to my email:

> There is nothing better than creating UIs with HTML and use them
everywhere, like in the Electron Framework.
> ... look into electron apps ... like VS Code and I think this is a big
Player and you can see, that it performs very well and it is performant as

OK, I can see people are looking (or at least googling) for alternatives to
current UIs. Yes, I agree HTML is one of (the best) options there -
especially if you want real WORA - e.g. also target plain browser. However
I have to say the following sentence is just increasing my internal

> heavyweight, ...(but)... the open source nature ... of Electron make it
potentially an attractive option for mixed Java/HTML applications

We - the NetBeans (incubating) project - have such technology, it is
HTML/Java API. It has been intentionally designed to support mixed
Java/HTML applications. We are the community of the project! But instead of
improving what we have and making it work for our NetBeans IDE purposes
(which is certainly simpler than trying to use Electron designed for
something different; more on that later), we are looking at other project
and admiring their "open source nature"!

Am I really doing so poor job that people aren't willing to dedicate 10
minutes of their personal time to try HTML/Java API in action? Rather they
are looking...

> I was looking at an example project using Vaadin running inside Electron
recently.  Have you tried this approach with HTML/Java?

...and trying Electron samples! C'mon do you have recent version of
NetBeans 9.0? Then just select "New Project", "JavaFX", "Java HTML5
Application" click through the wizard and choose Run/Debug on the generated
project! How much did it take? 30s of activity[1]?

> I keep trying to find some time to experiment with Apache HTML/Java and
wondered at the feasibility of reworking that Electron example with it?

If you give the NetBeans 9.0 support for HTML/Java UI a try, you see (when
using for example the Visual archetype) that rewriting visually rich
Electron application like
should be a piece of cake.

I consider it patriotic to try NetBeans own solution first. Am I completely

> Demo app showing all kind of features a given system allows me to use.
Like a toolbox, which I run and say - hey that's the component I need. Is
there something like this for the HTML+JAVA api?

The visual archetype offers canvas sample, line charts and pie charts
sample and interactive GeoBase application. Isn't that enough? Then there
is another CRUD like archetype, as well as simple MVVM sample. All of them
are just few clicks from your reach ("New Project", "JavaFX", "Java HTML5
Application"), is that enough to get started?

I hope it is. Guys, please, instead of drinking your morning coffee, click
though the wizard and see Apache HTML/Java API in action yourself. I'll be
thankful for comments. As confessed, I am depressed by my inability to
communicate what our HTML/Java project can do for you. It may not be 100%
perfect fit, but it is so close to what you guys need.... Shame on me for
not being able to explain that!


PS: Now let's look at what Electron isn't and why HTML/Java shall be a
better choice:

> I am sure electron is good, but my personal preference is to not use a
web ide.

I share your feelings. However we are not talking about Web IDE. We are
talking about reusing rendering pipeline that is behind HTML. Sure, this
pipeline is used in browsers, but that doesn't mean browser == the
rendering pipeline. Browser is much more and we don't need all of that.

> Think about ... what Electron actually *is* ...

Electron is the rendering pipeline, plus a bunch of libraries for dealing
with the surrounding operating system, plus JavaScript specific build
system. But, when writing Java application, why would you need those
libraries? Java has pretty rich operating system API (think of java.nio,
missing in JavaScript) and there are plenty of libraries to deal with other
aspects of OS integration. Why would you need npm build system? Java has
other, well established build systems as well. Conclusion? The only thing
you'd want from Electron is the rendering pipeline.

But then: What is the HTML/Java project goal? To be a portable abstraction
over such pipeline! I would conclude that you don't want to look at
Electron to begin with! Again, I am ashamed of not being able to get my
message thru...

> Funfact: Without JavaFX you don't have a HTML5 renderer

The truth is that we already have our existing Swing/JavaFX applications
and if we want to move towards HTML, we need an incremental way to migrate,
rather than big bang rewrite of everything. That is not at all what
Electron can give you! On the other hand that is something HTML/Java API
shines at. Because of using the JavaFX renderer (behind the scene), we can
easily mix the Swing and HTML UI in NetBeans IDE[2].

In any case having the Swing/HTML UI interop is real benefit for us. We can
mix both types of the UI right now. By having the renderer as an
implementation detail, we can replace it with better one in the future.

PPS: Have any of the above (or below) convinced you to give HTML/Java API a
try or did I failed again to explain its benefits?

[1] Plus few minutes of Maven plugins initial download time...
[2] Have you noticed that the wizard ("New Project", "JavaFX", "Java HTML5
Application") is written in HTML UI? I hope the transition from the Swing
to the HTML UI was smooth enough to not be really noticeable.

Reply via email to