In recent years, GitHub has been focusing on moving away from the old way of building applications using jQuery, and to the future with web components.
GitHub has announced on their blog that they have migrated over to using components. Due to the many advantages that they provide, this has been adopted throughout their entire platform using both open and closed source technology and tools.
Why would GitHub use components?
As explained in an article, GitHub was previously using jQuery on the majority of its front end. What made the use of the components more relevant, was that they were already using a component like structure and behaviours. This allowed for an easy transition. The front end needed to be updated to be more isolated as the codebase was growing and more developers were expanding and working on the software. Not to mention their codebase was over 10 years old and using code that old will require constant updates to maintain as languages and frameworks evolve.
Web components allow for the encapsulation of code. This design makes it easier for developers to add new features into the ecosystem without breaking other parts. But that’s not the only advantage when it comes to using components. When it comes to building complex systems and re-using features across different areas of your application or if you are working on lots of projects that need the same functionality, then using components is essential. With this approach, you can build and maintain your components without having to rewrite code or update code manually. You can globally update your code and maintain it across many different platforms.
As GitHub is building out the different components, they will be offering some of them to the public. They will be called GitHub Elements. These components have a wide range of functionality, from general use to very specific use cases.
How components are being built
GitHub analyzes their codebase to try and find similarities or the same functions replicated throughout their software. Once they find there’s a feature that is repeated throughout the system, they lift the code to its own repository. GitHub mentions using Catalyst for writing new components as they say it can help with best practices for writing components. Although Catalyst helps, GitHub strips out any Catalyst-specific functionality before pushing the code. They mention that this will eliminate any dependencies that are needed for Catalyst. When they build such components, they also use the same naming conventions for all components.
Much like Skhemata components, GitHub may use a component for several different tasks, and doing so, there could be some hardcoded attributes by default, but these attributes can be modified for alternative use cases. In Skhemata’s components, you can modify the component’s UI by simply adding different attributes. This is similar to what you can do with the GitHub components.
The goal for the GitHub Elements is to make them as universally accessible as possible. The idea is to have zero dependencies, be lightweight, have no styling and can be added to any framework or project.
Check out GitHub’s components here: https://github.com/github/github-elements