Hey Jaroslav and all others,

thx for your explanation. I think you didn’t get everything wrong, maybe more 
promotion but this is PR part 😉. There are big players out there. And why I 
love electron? Because it is fucking HTML, CSS and JS AND for the Backend too. 
This eco system was build for fullstack developers, who wants to create desktop 
applications with HTML/CSS/JS still in the background.

You know my example NbScratchFile, this is I think one of the best solution to 
promote a plugin for NetBeans, which was written in HTML, SCSS/CSS, TS/JS with 
a Framework called Knockout, a buildsystem with webpack and a communication 
with Java in the backend. Why I’ve chosen it? Because I wanted to write a 
plugin for NetBeans but w/o swing. The Mantisse editor is cool but far away 
from perfect, I created a ticket for a big problem to align checkboxes with 
labels pixel perfect, inside the Editor: 

Why I’m not writing the controls in Java? Sry but no, we have Qt, we have WPF 
(C# with XAML) and we have WYSIWYG editors to create UIs quick and fast and 
sometimes dirty. In HTML I don’t need such editor. It is my daily business, I 
have chrome with the powerful and best DevTools ever to see my progress 
immediately and I’m fast w/o having an editor.

So I decided to give DukeScript and the archetype a try, but there are some 
problems with the project type:

1. It is still not fast while bootstrapping the UI when you call your UI inside 
a component, we talked about that, that there Needs an improvement that this 
bootstrapping has to be done while IDE start or wherever. As soon as possible. 
Of course my plugin has the same problem and I have to change it and it is not 
the problem of DukeScript but there needs to be done sooner. Sometimes it seems 
that the DukeScript stuff was a prototype to say: hey look this can be done 
with HTML AND Java, but it feels unfinished.
2. The Project is so coupled with each other, I can’t use the HTML5 project 
features of NetBeans for that. It is still maven or Java with a piece of HTML 
inside. I can’t use the tasks for a HTML5 project, because it is not a HTML5 
project. I can’t install npm, I can’t use scss etc from the IDE. This is why I 
created it by my own. You can see everything here: 
https://github.com/Chris2011/NbScratchFile/tree/master/src/main. I created a 
HTML5 project and copied the dist folder (Built with webpack, the outcome) over 
to the maven project to open the project again separately to build my UI, 
indepedent from the maven stuff. This should be a possible template to creating 
a HTML UI with the backend Java to creating a NetBeans plugin. Because 
everything is decoupled. It has the build process within the plugin for the UI 
and build process for the Java backend.
3. The WebView, which renders the UI, is, AFAIK not WebKit. Why WebKit? Because 
of the DevTools of Chrome. That tools are the best I’ve ever seen and yes, I 
can say I have seen a lot in my career. I started with IE, they were good, in 
the first 2000s. I worked with FF with the beloved Firebug, I switched to 
Chrome, because the DevTools are awesome. Sure the FF tools are also great, I 
tested them too, but I missed a lot of features there. Anyway, for that 
WebView, that HTML4J uses, I  can only add firebug lite, which is pretty old, 
obsoleted, dead, etc. So for this, we need a better solution.
4. I had some trouble with the magic generated code, that HTML4J creates in the 
background for i.e. knockout (I don’t have any control about that). I split 
some classes to decouple my logic and the build breaks because of the magic 
that happens in the background. Sure I had to create tickets for that, but I 
was frustrated, that I tried to create my own UI with WebView from the JavaFX 
to call it and bind the ViewModel from JS to Java and vice versa, as you 
already know, maybe Jaroslav.
5. Again, I’m still a frontend developer, fullstack now, because I have to use 
Spring and Java, but anyway. I love JS and TS, I don’t know which limitations 
other means, but don’t compare GWT or Vaading with JS or TS. Yes, you have 
limitations with GWT (I also worked with that), but those limitations are 
coming from GWT and you can extend that, but that has nothing todo with JS. So 
my eco system is JS/TS, HTML/SCSS/CSS for the FrontEnd and JS/TS + Node in the 
BackEnd. And again I want to write as less as possible Java code for the 
plugin. Only that pieces what is needed. Your PR, which I merged into my 
plugin, has coupled JS within Java, which I don’t want but yes I know this is 
needed. Before I used your PR, you saw how I realized that, because I don’t 
wanted to coupled it.
6. I couldn’t resized the window when I was working with DukeScript, I didn’t 
have a lot of control to change the stuff to my needs. (setSize, noResizable, 
etc.) I simple couldn’t find that.

So again, I hope it is a bit clearer how an eco system for a pure frontend guy 
looks like AND should look like. I’m willing to use Java, or whatever we need 
for NetBeans in the backend for sure, to create nice plugins. But sry, I’m not 
willing todo Java coupled with js for the frontend. But as less as possible, is 

So my ecosystem:

HTML project where I can create my UI or whole application with HTML, SCSS/CSS, 
JS/TS with my own build system (Grunt, Gulp, Webpack, etc.)
Maven or Java project to create a plugin and copy/load my UI into that project 
with build process to build the UI within the project and the project itself.
A possibility to communicate with Java/js w/o having much coupled JS/Java code 
etc. pp.

So here you can see I have a working HTML Project, which I still can use in the 
browser. W/o having the Java project. And, when I want it, I can use the UI in 
the backend for the Plugin, which I wanted to use.

HTML4J should also fits my needs as a FrontEnd guy, but atm it fits it only for 
50% maybe. Or it is because of the archetype or the missing resource, to start 
with as a FrontEnd guy, not as a BackEnd Java guy.

The next step is to create a new plugin with a HTML/SCSS/Vue/TS based UI -> 
build with Webpack HTML which loads the JS file, which includes the transpiled 
JS and the transpiled CSS.

Sry for the bad english and maybe mistakes, I’m a bit in hurry. If everything 
is unclear, please let me know that. I’m really willing to work with HTML4j, 
because this is the only best solution to create scalable UIs with 
webtechnologies for NetBeans. I don’t have any other approach to work with 
HTML4J as for NetBeans. For the rest I use Electron or pure WebApp stuff. My 
famous last words.


Von: Jaroslav Tulach
Gesendet: Dienstag, 13. März 2018 09:26
An: Apache NetBeans
Betreff: Think Java, not Electron! was: Apache HTML/Java UI instead of

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 <jaroslav.tul...@gmail.com>:

> 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