Hello!
I’m a content marketer for Deviniti, an app vendor from Poland. After the fruitful collaboration that our team had had at App Week Key Largo this year, I realised I should write an article about how Atlaskit and AUI are developed in Atlassian and used in app development. @jcheung suggested posting my questions in this topic, so I encourage everyone willing to take part in the discussion
My questions to Atlaskit and AUI teams are:
What’s the main difference between AUI and Atlaskit? Or, more specifically, is there any difference except that one is used in Server instances and the other is for Cloud?
How and when did the idea emerge for building these libraries?
Why did you choose React to develop them? I assume that having React Native to use it in Jira mobile apps is the key. Am I right and are there any other reasons for having done so?
How did AtlasKit and AUI change over time? What are the further plans?
How often do Atlassians use these components themselves?
If you are an app developer, you could share both the things you like about Atlaskit and/or AUI and your pain points in using them. Also, you can share examples of implementation, if you’re comfortable with doing so. It will help me understand a lot more on this topic.
Moreover, we’ve recently started an open repo for the custom React components we develop and use quite often. There are not many at the moment, but we’ve got plans on uploading more there. You can take a look at the repo by this link: Log in with Atlassian account
Thank you for posting the question here. Here is the answer from @daz, @tshugart and I.
As of TODAY, both libraries aim to implement Atlassian’s Design Guidelines. And their main differences are:
Atlaskit is built using React, whereas AUI is built using HTML and CSS.
AUI and Atlaskit do not implement 100% of the same components, nor using the same APIs.
Atlaskit is relatively new which started 2 years ago, whereas AUI has 10 years of history.
Atlaskit
Atlaskit started 2 years ago as an effort to implement the new ADG designs for all Atlassian Cloud products which are built on top of React. It started as a repository of leaf UI components and un-opinionated about how components are used.
Over the last 2 years, almost all single-page applications built in the Atlassian Cloud use React and Atlaskit. And as Atlaskit matures and Atlassian products and ecosystem vendors lean in more heavily into Atlaskit and React, Atlaskit need to improve on how our consumer product and ecosystem teams can consistently implement these components and patterns in order to provide consistent and performant user experiences across our Atlassian products and ecosystem. Atlaskit components need to walk the fine line balancing between being opinionated about implementation best practices and providing the right level of extensibility. From here on, Atlaskit Core components will work on:
better logical groupings of components and design primitives as exports in the components.
provide extensibility by
consistent API with default props, ability to setup controlled props to override default behaviors as needed.
compose-ability of components through ability to set render props and more examples
a flexible theming API
more common use cases and patterns
AUI
AUI started 10 years ago as an effort to share common UI solutions across our products. At the time, the best mechanism we had to share UI in Atlassian was Atlassian Plugins, also known as P2…
AUI has had a large number of contributions over time, each with disparate coding philosophies. The results have been mixed. AUI’s pain points have been:
its monolithic nature – take all or none of it;
its low-level API of HTML and CSS, and
its distribution model on P2.
The AUI team will be addressing these pain points in upcoming major releases, moving it in a direction that’s more sympathetic to the needs of front-end development in 2018.
In 2017, every Atlassian product UI has a minimum of 40% utilisation of AUI.
Every one of them ships AUI’s CSS reset and basic styles.
Most use dropdowns and inline dialogs from AUI.
Modal dialogs are used in several places.
The remaining components are used occasionally.
Their usage is based on a number of factors.
Did the component exist in AUI before a product design team decided to implement a design pattern? If it didn’t exist beforehand, a product team likely built their own.
Does the component meet the intended use-cases of a given product? Some components’ behaviours were built before an understanding of the team’s expectations was established, which led to them not being used widely or at all. AUI’s async dropdowns is a good example of this: the feature was built expressly for Jira, but Jira do not use the behaviour as it caches the response forever, whereas Jira need the contents to change each time the dropdown is opened.
Did the team know the component existed? Sometimes the teams don’t check whether their problem has been solved already, and start down the path of building their own before they realise.
Does that mean that if I don’t want to use React, I can safely continue using AUI in my app and it will continue being updated to the latest Atlassian Design Guidelines?
Hey @dmitry, I’m the current maintainer of AUI. Yep, that’s what it means. We’ve just released AUI 7.9 which re-skins dropdowns. Other reskins will be coming over time. Are there any components or patterns that you’d want to see updated in AUI sooner rather than later?
Hi, I am currently migrating my Confluence/Jira Server Apps to Atlaskit. Before I was using AUI.
I have a specific question regarding the Atlaskit CSS Reset ComponentAtlaskit by Atlassian
When using Atlaskit in a Server Product, should we include Atlaskit CSS Reset?
It changes body margins, textsizes, font stylings a.s.o
I am assuming not to include it since the AUI Css also has some CSS reset code.
As you noted, since most products are providing AUI’s CSS reset, it doesn’t mate a lot of sense to include Atlaskit’s. With that said, each CSS reset may have slightly different scope, thus slight differences in assumption when building with the Atlaskit components.
Have you noticed anything strange or problematic when using Atlaskit components without its CSS reset? If so, let us know!
Yeah I removed it and now let the Server Product and its AUI CSS reset handle things.
I discovered only little things like table headings being centered instead of aligned-left. Or in Confluence for example the DroplistItems are blue instead of normal color => Atlaskit by Atlassian
But basically the only things I discovered so far were some force a-href coloring and some table th/td related things that can be easily fixed with some scoped css. Maybe your the AtlasKit components could do such things on their own.
Also are there some strange console warnings for some components. Like popper.js warnings for e.g. Droplist. Also Droplist when the trigger is clicked, does scroll to top of page in IE11 … but that is CSS unrelated stuff.
