DukeScript is a relatively new Technology. As such it suffers from some misconceptions. I recently found a thread on Reddit discussing wether DukeScript could “take off in popularity”. Well, we definitely think it should and are prepared to deal with it, but some of the people on this Thread didn’t think so. I’d like to answer the questions and misconceptions here, because it might also help readers of this Blog to avoid these mistakes:
"As far as I can see it's just a GWT clone."
DukeScript’s is pure client technology: You write your application and it’s business logic in Java which is compiled to Java bytecode. The bytecode is running in a normal JVM. If you deploy the application to the Desktop, the JVM is HotSpot, and you deploy an executable, e.g. an exe on Windows.
If you deploy to Android, it’s an Android application package (APK) and the JVM it uses is Dalvik, and if you deploy to iOS the deployment format is an .IPA and the JVM it uses is RoboVM.
One of the reasons for the misconception is that we also make use of HTML. We use it to define the View. We then use a Java component that is capable to render HTML to display the view.
We rather compete with Swing, GWT, and JavaFX, allowing Java Developers to deploy their client application to iOS, Android, and with some restrictions also to the browser.
"How is it not like GWT? It compiles Java to JS."
The whole Thread focuses on the bck2brwsr part. It’s probably our own fault that bck2brwsr and DukeScript are commonly mixed up. Admittedly we also find it very interesting to run Java applications in a browser, although it’s not our main focus. So again, bck2brwsr is only a minor, experimental part of the DukeScript story.
But even if we take it as a statement about bck2brwsr it’s wrong. One guy on this thread, a GWT developer, answers this question really well:
“The Bck2Brwsr project which DukeScript relies on takes compiled Byte Code and either pre-converts it to JS or does a JIT conversion to JS with a JVM implemented in JS. GWT instead takes Java Source and compiles it to JS. Its a different model.”
As a result bck2brwsr can take an unaltered JAR, for example a Java library like jbox2d and use it directly as a dependency.
"You seem to not have access to the JS ecosystem"
Two more complex example are the (Canvas API)[https://github.com/eppleton/canvas] and the Leaflet API. They provide a complete Java API for HTML 5 Canvas and the Leaflet Map component.
"I'd suspect a lot of the Java ecosystem is closed off also"
That’s also wrong. Restrictions depend on the deployment platform. If you deploy to desktop you’ve got access to every Java API available. If you deploy to iOS and Android You can use the subset of Java APIs available for Android. Only if you wouldlike to use our experimental support for running in the Browser via bck2brwsr, you are limited to a small subset of all available Java APIs.
"It also looks like it has no RPC framework"
The application and it’s logic is mainly running on the client, but if we need to talk to the server we try to make it as easy as possible by using annotations. With the @OnReceive Annotation you can define a JSON communication endpoint in your view model. Here’s a simple example of how to get a Person object from the server:
DukeScript ViewModel classes natively support JSON and like GWT-RPC we can serialize and deserialize any view model Object to and from JSON. The NetBeans support for DukeScript ships with a sample application that contains a server and a client. You’ll be surprised how simple it is to setup the communication, and if your backend is written in Java, you can even reuse the model classes on client and server.
In summary, it seems that most misconceptions are due to our support for deployment to the browser. And though our support for bck2brwsrs is only a small -and the most experimental- part, it’s commonly mistaken to be the core of DukeScript. I hope i managed to clarify this and help interested developers to get a clear picture of the core idea behind DukeScript: