With numerous great choices for frameworks, skills commonly available, and unparalleled flexibility in styling, it’s hard to imagine choosing anything else as long as you don’t mind your app looking like a web application.Ĭreating applications with the likes of Electron or MacGap is nothing new - there are several successful such applications in widespread use, such as Slack, VisualStudio Code and WordPress Desktop. Many organizations have substantial functionality available in the form of Java libraries that they would like to reuse and the corresponding skills, infrastructure and methods to build and maintain application logic in Java.īut building a JavaScript-only application isn’t for everyone, especially in cases where reuse of existing functionality is important. Taking an Electron-like approach to building such applications but with an emphasis on Java for the functional portion of the application could be a good choice in these cases. Java ships with a WebKit-based WebView for JavaFX. This made a bit of a splash, as previous attempts to embed a browser in Java apps were either using a sub-par Java-based browser, or had crazy dependencies and complex setup.Ĭreating a JavaScript application using a JavaFX WebView has been done before. On the surface this approach looks great - with the benefits of a state-of-the-art browser engine, standard APIs, no extra dependencies and tools to create platform-specific installers, many of the previous problems are solved. But the approach hasn’t seen wide adoption, in part due to these shortcomings: 1. Web developers rely heavily on browser-based tools to develop the look and feel of an application. Modern web browsers provide integrated tooling that provide a way to introspect and modify CSS and HTML. With a couple of clicks, developers can troubleshoot and try out styles and HTML, live in the application. This ability to change an application as it’s running is one of the cornerstones behind web developer productivity.Ī JavaFX WebView doesn’t have such tooling. The WebView is a black-box, essentially locking developers out from their most powerful development approach. One approach to overcoming this limitation is to include Firebug Lite, which enables inspection of HMTL and CSS in almost any browser, including the JavaFX WebView. I did get it working, and though it’s better than not having any tooling, not all versions of Firebug Lite worked for me and I was unable to edit CSS properties live in the application. To be fair, Firebug Lite is not intended as a replacement for Firebug or Chrome development tools. In the end I found that it was insufficient for my needs. No matter how good your JavaScript automated testing approach, there is no substitute for debugging JavaScript live in a running application. It’s the last-resort fall-back to figuring out what’s really happening in your application. With no built-in JavaScript debugger, the JavaFX WebView left me feeling like it was the early days of the web. With the UI in a WebView, calling out to your Java application (or the reverse, calling into the JavaScript web UI) is an important aspect of this approach. Unfortunately crossing the JavaScript-Java boundary is not entirely straight-forward. Though it’s possible to invoke JavaScript in the WebView from Java, and call back to Java from JavaScript, it’s not transparent.ĭata type conversion is very limited most non-trivial use cases will require Java code that introspects JSObject, a generic JavaScript type wrapper.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |