AUI 8.0 is released!

Wow, what a journey. 6 months ago, we started work on a major overhaul of AUI.

On November 28, we finally released AUI version 8.0.0!

In this version, we aimed to:

  • Re-evaluate what you get “by default” when importing AUI.
  • Remove dead and deprecated code.
  • Upgrade external library dependencies.
  • Make it easier to consume only the pieces of AUI that you need.

It’s been a long time in the making, but we’re pretty happy with the end-result.

Highlights

It’s smaller

In AUI 7.9.9, the combined weight of its JavaScript and CSS bundles was 185 KiB (min+gz).

In AUI 8.0.0, that drops to 164 KiB (min+gz).

Those savings are primarily from removing old, long-deprecated code patterns.

That’s pretty good already, and that’s with “all the things” in it. What about just the defaults?

It’s sensible by default

We know that UI performance is important, and page weight affects performance. One way to reduce that weight is to only pull in what you need. To make that possible, we’ve overhauled what you get by default in AUI 8.

In AUI 7.9.9, loading the ajs web-resource would cost you around 555 KiB (min).

In AUI 8.0.0, that ajs web-resource costs around 262 KiB (min).

That’s a whopping 50% less code by default !

It’s faster

In addition to being smaller, AUI 8 runs faster!

Comparing test pages for AUI’s dropdown2 component with Chrome’s Lighthouse audit:

  • AUI 7.9.9 scores 63 / 100 , with first meaningful paint at ~ 4.5 seconds .
  • AUI 8.0.0 scores 85 / 100 , with first meaningful paint at ~ 3.3 seconds .

There’s obviously a whole lot more room for improvement here. However, these perf improvements come with a minimum of performance tuning or production code changes. Going forward we’ll do what we can to improve on those numbers.

It’s more modern

We updated the versions of Backbone, Underscore, and jQuery-UI in AUI 8 to their latest versions. In addition, we added support for jQuery 3.

AUI 8 was tested against jQuery 1.7.2, 1.9.1, 2.2.4, and 3.3.1. We dropped official support for jQuery 1.x, but it still works.

It’s not “experimental” any more

The “experimental” concept was introduced to allow AUI’s developers to ship not-quite-finished features to consumers. In practice, though, “experimental” features quickly landed in production, causing a whole lot of frustration when those “experimental” components changed. This saga has been analogous to browser vendors and vendor-prefixed features. Like the browser vendors, we’ve come to realise that shipping experiments in a production distribution isn’t the right way to do things.

Finally, in AUI 8, the “experimental” concept is gone.

Going forward, if the AUI team build new components or features, they will be built in completely separate packages. This both helps keep the production library size small, as well as set the right expectations around those experimental things.

It’s re-open-sourced!

Thanks to changes in how we build the AUI artifacts, we’ve been able to make the core AUI library open source again!

Some Atlassian-specific assets still exist, though, and are still shipped with either the Atlassian Developer Terms or ADG license. However, these parts are contained within their own discrete packages.

The changes in AUI 8

For an overview of all the changes, consult the AUI 8 changelog.

The AUI documentation has been updated with a comprehensive upgrade guide that lists all consumer-facing changes and how to handle them.

When to expect AUI 8 in products

Atlassian’s Server product teams are planning when they will upgrade the base products to AUI 8.

As at December 6th, Jira 8.0 will be bundling AUI 8.0. Other products will follow in time. I do not have specific product versions or timeframes to share right now.

Going forward

We’re keen to hear from you to find out what you need from AUI or for your UI going forward. If you find bugs in or have suggestions for the AUI library, you can raise an issue in our public issue tracker. Also feel free to discuss below, or around this developer community – we do our best to read and respond to everything tagged with aui. Feedback, suggestions, technical direction or architectural discussions are welcomed.

:heart:,
The AUI team

7 Likes

Hi @daz,

I am wondering if it is normal that I only have deprecation warnings when updating to AUI 8. The upgrade guide’s last section “Common runtime errors” seems to indicate that crashes should occur.

I am using Jira Core/Software 8.0.0-m0032 and our plugin’s code is using the global underscore variable.

Great job with the work on AUI by the way, it seems you guys want to go in the right direction.

Thanks!

Hi @linklefebvre, cheers for the kind words :slight_smile:

Jira 8 imports a large amount of AUI 8’s code in to run its feature code. Since everything loads in to the global execution context, it’s possible that you aren’t seeing hard runtime errors because your plugin code is running on a page that happened to already load the dependencies your code needed.

To test whether your plugin has declared all of its runtime dependencies correctly, you would need to load your plugin code on an essentially empty page. In Jira, that’s a little challenging to do – between its ever-present superbatch and most pages loading the atl.general context, most pages will have a good amount of AUI’s resources on it.

I’m not personally aware of a readily available test page or mode that would be devoid of all resources other than what your plugin requests.

One trick you could try: you can attempt loading a page with a GET parameter of ?decorator=popup, which will tell Jira to use a different page template that won’t load the atl.general context. You will still get a good amount of resources, but fewer than before.

Hope that helps,
Daz

1 Like