The talk “STJS: Managing JavaScript application complexity” by Alexandru Craciun (LinkedIn) and Nicolas Piguet (LinkedIn) focused on one of the major pains with JavaScript: It’s easy to get started, you have can quickly build a useful app which then just as rapidly turns into a maintenance nightmare (slides).
They used ST-JS as a tool to reign the dragon.
In a nutshell, ST-JS is a tool that parses Java code and converts it into JavaScript.
What ST-JS isn’t: It’s not GWT (see the FAQ). The code can be edited in your IDE, it compiles but it doesn’t run directly. The Java code is just used to allow you to write type-safe code using all the amenities of a modern Java IDE to write JavaScript. But if you want, you can implement so parts – think about sharing POJOs between your Java code and the script in the browser.
This works by writing thin wrappers (usually just a bunch of Java interfaces) to simulate the API layer of a JavaScript framework like jQuery. This code is called a bridge, here is a list of already available ones. You can then write code using code-completion, JavaDoc popups and type safety. You can apply tools like PMD, FindBugs, SonarQube (formerly Sonar), dead code analysis, …
The tool will then convert this code into JavaScript. A standard JUnit runner can now execute it by opening a browser window or simulating one using env-js and Rhino.
The output of the tool is plain JavaScript. To run it, you just need to include stjs.js which you can serve statically from your server.
As I see it, this project has the following benefits over anything else I’ve seen so far:
- Full support from your Java IDE – Code completion, refactoring, type/JavaDoc popups, jump-to-definition, …
- You can split the JavaScript mess easily into classes and packages
- Not intrusive, low complexity
- Easy to build bridges to other JavaScript frameworks
- Allows to share POJOs between Java and JavaScript
Dark Views 