Return to jQuery

I’ve been at UDig for just shy of a year now, and in that time, I’ve primarily worked on a single client project. By the time I joined the project, the UI technologies were already established. In the name of simplicity, the team decided to go with a JQuery-based UI backed by Spring’s Thymeleaf templating system. While I would have probably made different choices, we’ve made a functional, solid UI from these pieces. I’d like to take a few minutes to explore some of the good, the bad and the ugly parts of this particular stack in a modern web-application context.

The Good, i.e. Things I Like

Even in 2018, there are still some benefits to using jQuery. Setup is quick and easy, and at this point, almost everyone knows jQuery. Following from that, jQuery has been around for so long that for anything you want to do, there’s 5 different plugins for it, each with their own level of customizability and an online community. It should be noted that this is a benefit only as long as you don’t overload the application with external libraries. While SPA’s are all the rage right now, a multi page structure with a few shared utility files can be used to create a simple and easily understandable separation of concerns driven directly by the structure of your UI.

Thymeleaf is also not without its strengths. It’s basically a more reliable iteration on the concept of JSP’s. The reliability comes in the application of default values, where you can render a Thymeleaf template even if your server response has a problem. Though it is less of a concern these days, it’s worth mentioning that server-side rendering allows for a lighter client-side load in your app, which can be handy if your users are on older or cheaper hardware.

The Bad, i.e. Things I Don’t Like

I had forgotten how error prone and painful direct DOM manipulation could be. Before this, I spent a few years working in Angular and I grew comfortable having a layer of abstraction between my JavaScript and the DOM. Along the same lines, I also miss the componentization and “auto-magic” behavior that comes with newer frameworks like Angular or React (e.g. 2-way data binding). A lot of these things are quality of life improvements for us that make us lose less hair hunting down an incorrectly typed CSS selector and the like. It follows that the more state you introduce into your application, the worse this disconnect becomes.

The Ugly, i.e. Things No One Would Ever Like

Without enforced structure, it becomes extremely easy to write “spaghetti code”. This has been a concern with JavaScript through it’s lifetime, and one that newer frameworks seek to curb to good effect. At different points in the development of our app, we’ve had to go back through and rework more than a few modules because they were tending towards unmaintainable. The silver lining here is that it’s easier to pull jQuery apart and put it back together in a new structure than something more rigid.

The other real pain point is this: The only way to load up a javascript version of your Thymeleaf objects without a separate ajax call is couched in a global variable. This is less than ideal. Placing these into a “Data” or “Globals” namespace object helps with this a little (as far as readability is concerned, anyways). But if you have more than one programmer working in the UI, it’s liable to get hairy pretty fast.

As newer web technologies move forward and mature, more and more frequently we encounter situations where jQuery is not the right or best choice for any given situation, but there still exists a scope of problems where simple, quick and flexible solutions may be preferable over something more structured or complex. In those situations, jQuery is still a viable option.