A heap of links – enjoy! 🙂
- CheerpJ 1.0 has been released, a “Java-to-JavaScript solution to automatically convert any Java application to an HTML5 web app.” CheerpJ is a commercial library with free licenses for non-commercial use. I tried the Swing Demo page but found it to be quite slow and I ran into errors (e.g the text field demo recorded two key inputs for every key press I actually did, and there were a number of odd visual glitches / lagginess).
- Slightly related, JPro have also announced their JavaFX-in-the-browser release. Unlike CheerpJ, I believe JPro works by having the application run on the server, and sends across SVG details to be rendered on the client. This places more burden on the server-side, and also results in some important restrictions (no FX event thread blocking for dialogs, etc, no statics in your app (because they will be shared among all users and clobbered or read in by different users), no additional stages can be created, etc). JPro host an array of demos running on their server if you’re interested.
- Johan Vos has blogged about creating a shell for prototyping scientific Java applications.
- Dirk Lemmermann has worked with a student team to create PreferencesFX. PreferencesFX “enables the developer to create preference dialogs with ease and creates well-designed and user-friendly preference dialogs by default.”
- Christoph Nahr has two posts this week. Firstly, a post about JavaFX being decoupled from Java SE 11. Secondly, a post on 3DViewer – viewing 3D objects in JavaFX.
- Mike Hearn has posted about building the React TicTacToe tutorial app in Kotlin/JavaFX.
- Jeff Martin has updated SnapKit Builder recently.
- GOXR3PLUS STUDIO have emailed me to say that they have “created a Chromium Browser in JavaFX and added it to XR3Player“. I was also informed about FX-BorderlessScene, an “undecorated JavaFX Scene with implemented move, resize, minimise, maximise, close and Windows Aero Snap controls.”
- Speaking of undecorated stages, Oshan Mendis has also created a library for doing this.
YES !!!
Let’s add to the teetering heap of technologies, frameworks, libraries and formats that javascript is supposed to integrate with and act as the front end for ! Let’s turn JavaFX into javascript because… why again.?. oh never mind, it’s the web everybody! There’s gold in them thar hills!
I’m actually starting to feel sorry for javascript at this point, the poor little guy It’s like that little dog in How The Grinch Stole Christmas whom the Grinch slapped a pair of antlers on before forcing it to drag the huge sled, stuffed to overflowing with stolen Whoville Christmas presents, back to the Grinch’s mountain encampment It was never really meant for any of this.
Well whatever the future is, it’s good to know that it will be written in javascript, the 23 year old, 10 day project of the (no snark here) brilliant developer, Brendan Eich.
This is truly a standard that perpetuates itself merely because it perpetuates itself. That and no one involved has any incentive (or suffcient vision) to jump off the javascript train.
Our job is to defend and extend robust, fully capable GUI toolkits like JavaFX so the future of client development looks and functions more like, you know, the future, and less like a dog that’s been taught to walk on its hind quarters, where the amazing thing about it is not that it’s been done well, but then it’s been done at all.