Save time maintaining and testing your JSP code by keeping things organized in small, manageable components. A component-based architecture makes it easy to write automated tests for your UI code, opening the door to TDD. This could mean 40-90% fewer bugs by the end of your project.
Normally, unit testing JSP code would be impossible. This is because your average JSP file is doing two jobs at once:
- fetching and manipulating data from the server
- visual presentation of that data in the browser
This tool lets you treat these two intertwined parts of your JSP code as separate units. (This works through dependency injection and the façade pattern.) With better separation of concerns, it becomes possible to do unit tests where previously only slow, complex integration tests would have worked.
Basically, this all boils down to keeping things in separate files, where you would normally have them all mixed together in one. The server-oriented half and the browser-oriented half remain separate up until your final build step:
$ npm run jsxquery-build
The end result is an ordinary JSP file like you're used to.
Since the end result is the same as writing raw JSTL, all the debugging skills your team has acquired during their past experience with JSPs are still applicable. But with all back-end logic cleanly separated out from the view logic, a new possibility opens up for you. Just take a file with your back-end logic and swap it out for some test data, and you can see what your page would look like with that data, without even running a server or a database. You can create as much test data as you like, so you can see what your page would look like under all sorts of different conditions. No more clicking around, filling out forms, and waiting for them to process over and over--just write some test data once, plug it in, and re-render your page as needed.
You can test your changes right in the browser by creating an HTML file, or you can set up automated tests like in this demo. In any case, as a front-end developer, you can stop being blocked by unrelated back-end issues, as long as you know the page and the page state relevant to whatever feature/bug you're working on.
As a front-end developer, all you need to learn in order to start using jsxQuery is the API for creating Components. The back-end parts (and your test data) are simply JavaScript/JSON objects, and the front-end parts are made of JavaScript and JSX. Technically speaking, JSX is an extension to the syntax of JavaScript, but in practice, it's hardly any different from HTML/JSTL.
Even back-end developers with no experience with JavaScript will encounter little that's new to them in jsxQuery. The jsxQuery Component API only uses features of JavaScript with direct analogs in Java, like class and method definitions, which have nearly identical syntax in both languages. (If there is one exception, it's the map() method on JavaScript arrays, which you can just think of as a replacement for forEach loops.
You don't have to overhaul your entire UI architecture to start using jsxQuery components. jsxquery-build lets you stay in control of exactly which parts of your project depend on jsxQuery components. And since you end up with human-readable JSP files, you can safely remove jsxQuery from your project at any time.
The jsxQuery component API mirrors a small subset of Facebook's React. React is at the forefront of a large movement in the JavaScript community centered on component-based UIs. That means learning how to write a jsxQuery component will leave you with skills that are also applicable in Angular 2, Polymer, vue.js, and even iOS/Android development with React Native.
jsxQuery started as an experiment in automating the process of keeping markup and jQuery code in sync. You can see those features at work (at least the o nes that have been completed) at index.html in this repo.
If you want to learn more details, checkout this walkthrough and the accompanying repo complete with example unit tests.