Hi Wade, one of the ideas behind DukeScript was to not create our own rendering technology and set of widgets. That has huge benefits:
- We don't have to write and maintain a Rendering Pipeline. JavaFX proofs how hard it is. They have huge performance problems, partially caused by basically only using egl commands, after more than 10 years. - Our API has about 60 classes, of which you probably touch 30 at most unless you want to port it to a new platform. JavaFX has about 700 due to the many widgets. - We can use all the Widgets supported by HTML/CSS and any HTML/CSS/JavaScript framework without any additional work. All the guys writing new JS libraries and tools are working for us. As a result, we can focus on porting to new platforms, making the API better, improving testability, etc. instead of having to maintain a huge codebase. That doesn't prevent you from providing a different rendering pipeline. We'd be more than happy to see such development. Regarding the architecture: In a plain DukeScript application we're starting a normal Java process. This process starts a HTML5Renderer using a "Presenter", e.g embedded chromium. The task of the Presenter is to take care of the communication and make it transparent to the developer. As the Java process is running on your local machine, you can use java.io or nio to open files. Regarding Web APIs, I agree with Sean that not every browser out there can handle it, but if you control the browser, you're way better off than with JavaFX 3D, because modern browser are using fast and well maintained rendering pipelines. Chrome, for example uses ANGLE to map commands to DirectX and OpenGL. I think tere were discussions about using ANGLE for javaFX as well to improve performance, but I haven't heard what came out of this. --Toni -----Ursprüngliche Nachricht----- Von: Wade Chandler <wadechand...@apache.org> Gesendet: Dienstag, 13. März 2018 15:19 An: dev@netbeans.incubator.apache.org Betreff: Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from Oracle JDK > On Mar 13, 2018, at 3:04 AM, <toni.ep...@eppleton.de> > <toni.ep...@eppleton.de> wrote: > > 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. How are events handled then? If you want to open a file as an example? Are you running the JVM as a separate service backend and using web services? > > 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. That sounds pretty cool. > > 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. > Perhaps, but I think one has to bind a product to a specific and embeddable browser for something like NB and NB RCP, or perhaps some custom Webkit. Relying on just anything seems like a lot to support at that level. I figure if views themselves can be replaced, then technically we could have our own native views instead. We could do some things based on OpenGL or Vulkan https://www.khronos.org/vulkan/ <https://www.khronos.org/vulkan/> or stay low-level yet remain in Java with LWJGL https://www.lwjgl.org <https://www.lwjgl.org/>, and not have any browser limitations. Here’s an example of an OpenGL based UI library https://github.com/wjakob/nanogui <https://github.com/wjakob/nanogui> > 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. > I’ll let him speak more to this, but per his talks he tried different browser based 3D APIs, and the performance wasn’t there yet. Personally, I have seen a lot of WebGL components get the sad face uh oh in Chrome, and not be that stable; this on good hardware. Wade --------------------------------------------------------------------- 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