On Tue, Mar 13, 2018 at 9:26 AM, Jaroslav Tulach <jaroslav.tul...@gmail.com>

> > 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]?

Well, you must admit that that is pretty well hidden.

You're saying the HTML/Java (or is it not HTML4J) sample is hidden inside
the JavaFX category and is named "Java HTML5 Application".

I think this is the key problem -- how well hidden this technology is.

To be honest, it took me many years to understand what the NetBeans Lookup
API was for. Eventually I understood it as a generic mechanism for
decoupling, which can be used in several different ways -- e.g., to provide
a global context and for pub/sub communication.

The problem/challenge with HTML4J is very similar -- it is a generic
mechanism and its usages take a while to understand. To help with this, you
can make really crystal clear what it is -- and the info in the README here
https://github.com/apache/incubator-netbeans-html4j is good, but probably
best would be a library of very basic samples, i.e., the repo needs a
samples folder.

Also, what would a transition from NetBeans IDE to HTML/Java API look like
-- OK, sure, we can make TopComponents that contains HTML files, via the
HTML/Java API. But how far can we go with that, can you do a POC of the
complete NetBeans IDE redone via HTML/Java API? You or Toni are the only
ones who are able to do that and you should do that or stop talking about
it as a way forward.



> > 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
> https://github.com/electron/simple-samples/tree/master/activity-monitor
> should be a piece of cake.
> I consider it patriotic to try NetBeans own solution first. Am I completely
> off?
> > 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!
> Thanks.
> -js
> 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