When an application like Ready Room is brought into being, software developers do not first reinvent the computer, nor do they reinvent databases, programming languages, or protocols. In fact, to the best of their ability, programmers do not spend time on anything except implementing business requirements. Consequently, your typical application is dependent on a large number of underlying components made available by others.

When development begins, the engineering team will typically choose the most recent version of these underlying components, and will do the same as new libraries and components are added to the project. But here’s a question, if nothing’s broken, is there any reason to ever upgrade these components?

One common answer to this question is, “if it ain’t broke, don’t fix it.” That is, if there’s no compelling reason to upgrade a library like, say, the PDF generation library, then don’t. Not only does the library currently work, but you may break something in the process of upgrading. And you know what? For a while that makes sense—at least, for something as isolated as PDF generation. But some components are more fundamental than that.

Underlying any modern web application is a web application framework, a piece of software that abstracts away much of the underlying web infrastructure, allowing the development team to focus primarily on business logic. Similarly, there are client-side components that wend their way through the entire user interface. If you don’t update these on the regular, you miss out on bug fixes, performance improvements, new functionality, and, somewhat unexpectedly, the direction the community is taking the platform. Worse, as these products drift further and further away from the version you’re using, should an important security issue arise, you may find upgrading to be a herculean task. What should have taken minutes now takes months!

Here at Synclinical, buoyed by our suite of automated tests, we update these core components fairly frequently, usually no more than a few months after their release. Less integral components get updated about every six months. Great! We’re picking up fixes and performance improvements for free and mostly staying current with the component’s direction.

But sometimes the new functionality in these components take you in a direction that you’re not ready to go just yet. And sometimes other components become available that you would like to swap for an existing component, but the effort is too great. So you wait, focusing on delivering the porcelain rather than monkeying with the plumbing.

Ultimately, however, the day comes when the engineering lead prioritizes the tasks that will start the team building on the latest technology. For Ready Room, that day was Monday, May 15, 2023.

The impetus was to add sorting and filtering to Ready Room in a consistent manner. For that we opted to add the Flop library to the product. Flop has a companion library called Flop Phoenix that simplifies building the UI components. And while it’s not strictly necessary, Flop Phoenix is documented in such a way as to encourage the use of the newish technology existing in our underlying web application framework, Phoenix, to wit, function components using declarative attributes.

We’ve been ignoring declarative function components for a while, but no more! So, along with getting to the most recent version of Phoenix, we decided to rewrite significant sections of the application to leverage this new technology. It was a large undertaking, but totally worth it. Not only are we now inline with the direction Phoenix is going, but the code got a lot cleaner and smaller.

The pre-built components leverage another fundamental change the Phoenix team made; they ditched the previously default UI framework, Milligram, and replaced it with a much more radical (though popular) framework, Tailwind. Ready Room didn't use Miligram (good), but it did use Bootstrap (bad).

Completely swapping out Bootstrap for Tailwind, while desirable, would be a monumental effort, so instead we decided to let them live side-by-side for a while. Okay, but the version of Bootstrap we were using, version 4, contains a large and outdated JavaScript library called JQuery. Ready Room didn't use much JQuery, so we were keen to get rid of it, but that required upgrading to Bootstrap 5. Now, you wouldn’t expect that to be terribly difficult, at least we didn’t, but the Bootstrap 4 to 5 upgrade path is just one big breaking change. It took quite some time to chase everything down and put it back together again.

With that done, however, we were able to rewrite what little JQuery-specific code that had snuck into our JavaScript and remove JQuery from the product. And that allowed us to throw away our client-side build tool, WebPack, in favor of esbuild, the tool now sanctioned by Phoenix.

In summary, over the past few months the engineering team:

• Replaced WebPack with esbuild
• Upgraded Bootstrap from 4 to 5
• Purged JQuery from the system
• Added Tailwind
• Replaced about 50% of Bootstrap usage with Tailwind
• Went all in on Phoenix LiveView function components, rewriting many of our existing components and views.
• And finally, implemented sorting and filtering.

We’re not done, though. Over the next 12 months we will continue removing Bootstrap code in favor of Tailwind and replacing old style Phoenix views with function components. But there’s no hurry now, the hard part’s done. So for the rest of this year at least, the engineering team will be primarily focusing on delivering the many feature requests that you, our customers, have been asking for.

Oh, and if anything looks amiss, please let us know at support@readyroom.net