Redesigning Jenkins (Part One)

In modernizing the Jenkins frontend, our foremost priority has been to preserve backwards compatibility, maintain platform stability, and ensure that no production pipelines are disrupted as a result of UI or framework changes. Given Jenkins' role in powering mission-critical CI/CD workflows across global enterprises, even small regressions can have far-reaching impact.

To achieve this, our approach has been pragmatic, cautious, and highly incremental. Rather than introducing disruptive overhauls, we have focused on gradually modernizing the codebase over a period of several years, ensuring each change is thoroughly tested and validated in real-world use cases.

All enhancements are subject to comprehensive automated testing, including compatibility checks against Jenkins' vast plugin ecosystem. In addition, our weekly release cycle provides early visibility into changes and allows us to gather feedback from a broad subset of users before changes are widely adopted.

Before we could take on the bigger challenges, we needed to start with the basics. A major part of this work has involved modernizing the foundations of the Jenkins frontend - removing outdated technologies, cleaning up legacy code, and laying the groundwork for a more flexible, maintainable, and future-proof platform.

The first significant milestone in the modernization of the Jenkins frontend was the removal of Prototype.js, a legacy JavaScript framework that had long been a constraint on adopting modern JavaScript syntax and practices. Prototype.js had been deeply intertwined with core components of the Jenkins UI, acting as a technical barrier to progress and modernization. Its removal, as outlined in Basil’s blog post, marked the end of a major blocker and unlocked the ability to implement long-awaited updates and improvements. This change has not only improved code readability and maintainability but also enabled the Jenkins frontend to embrace more contemporary JavaScript standards, fostering a cleaner and more robust development environment.

One of the most impactful changes was the removal of Yahoo User Interface (YUI), a legacy JavaScript library that had been deeply embedded throughout various areas of the Jenkins UI and its plugins. YUI’s presence significantly complicated the frontend architecture and asset management. Removing it was a substantial undertaking, but it drastically streamlined the asset tree and reduced technical debt across the codebase. As of Jenkins 2.492.1, YUI is now disabled by default. This effort culminated in a major cleanup of the codebase, with over 85,000 lines of code removed, significantly simplifying the platform and paving the way for more modern, maintainable development practices.

Another important step in modernizing the Jenkins frontend has been the migration from LESS to SCSS, a small but meaningful improvement in our styling architecture. SCSS offers better language features, stronger community support, and better compatibility with modern tooling. We’ve also been modularizing our legacy CSS into discrete, maintainable style modules, making it easier to enforce consistency, isolate concerns, and improve reusability.

We have also undertaken a broader initiative to standardize the use of modern JavaScript across the Jenkins codebase, embracing ES6+ syntax, modular architecture, and improved use of browser-native APIs. This shift has been pivotal in improving code readability, maintainability, and performance. Legacy inline scripts and globally scoped functions are gradually being replaced with well-structured, reusable JavaScript modules, bringing the frontend architecture in line with modern development practices.

We’ve deliberately avoided introducing new complex frameworks and heavyweight dependencies. Modern JavaScript - just plain, native JS - is more than capable these days. With modern JavaScript we can write expressive, maintainable code without any additional overhead.

That doesn’t mean we’re afraid of modern tooling - just that we’re selective. The goal is to lower the barrier to entry for contributors, not raise it. Jenkins has hundreds of people around the world contributing in all kinds of ways - we don’t want our frontend stack to be a gatekeeper.

Every one of these changes helps reduce complexity, improve maintainability, and pave the way for more ambitious UI improvements. Some of these changes might seem small from the outside, but collectively they’ve laid a new foundation for Jenkins. This is the groundwork that makes future UX improvements possible - things like cleaner plugin integration, improved accessibility, better navigation, and modern UI components.

In Part Two, we’ll dive deeper into the design decisions behind some of the new UI features, how we’re improving the developer experience, and what we’re doing to ensure compatibility across the plugin ecosystem without slowing down progress.

If you want to get involved in the UI and UX discussions of Jenkins join the User Experience SIG.

Take advantage of new components and patterns in your plugin via the Design Library.

You can watch our monthly meetings on YouTube and you can view in-progress work on GitHub.