GitHub has been working for the last few years to move away from jQuery and run its interface entirely on Web standards, specifically Web Components. InfoQ has talked with GitHub application engineer Kristján Oddsson to learn more.
We chose to use Web Components because our codebase was already structured into component-like behaviors. Still, as the GitHub monolith grew in size, we saw the need to implement better encapsulations before the front-end became unmanageable – and Web Components fit the bill.
As Oddsson recounts in a recent article, GitHub's effort did not only lead to building a large library of open-source, both generic and single-purpose components, but also to the creation of a number of tools to help engineers create Web Components more easily along with best practices to follow.
The starting point to write a new Web Component at GitHub is Catalyst, a framework relying on TypeScript and decorators to reduce boilerplate and adopting an observe, listen, query approach to handle state change and user interaction. GitHub also created a Web Components linter which is used along its generic JavaScript linter.
All in all, GitHub engineers are happy with the results brought by this change, says Oddsson:
Developers enjoy the encapsulation of ViewComponent, making it easier to test UI and increasing developer confidence. Developers feel Catalyst is a welcome change from “old-style” JavaScript without the massive leap to a different framework or paradigm.
InfoQ has talked with Oddsson, who has worked on making the GitHub frontend more performant, accessible and easy to work with.
InfoQ: Almost three years after you started a transition to Web Components, do you think it was a worthwhile decision? What advantages have Web Components brought?
Kristján Oddsson: Yes. Investing in the Web platform has been very worthwhile for teams at GitHub, and Web Components have been a pivotal part of that investment. We can build re-usable standard components that we open-source and very application-specific components that we see no use in open-sourcing. All of the components that we open source are white-label components in that they provide minimal or no styling at all. By not enforcing styles in the components, we can style them in the consuming application based on their context.
Web Components are also included in every major modern browser as part of the Web platform, which allows us to ship less JavaScript to users resulting in better performance than if we were to include a framework with our bundle. We’ve written before about removing the jQuery framework from our frontend, and the same concept applies here. We’d like to ship as little code to browsers as possible and practical so that the user experience doesn’t suffer.
InfoQ: When you started this transition, Web Components were a fairly new technology. Today, they are fully supported on most browsers, with the notable exception of Safari. What were the biggest stumbling blocks you had to overcome?
Oddsson: Since Web Components refers to a collection of technologies, it’s not always clear what “supporting Web Components” entails for browsers but for all intents and purposes, Safari supports Web Components. We ship Web Components to Safari users today and have for some time.
I don’t think we’ve had many stumbling blocks with Web Components. We tend to move at a steady pace and take our time to experiment with technologies. For the minor issues that have come up with Web Components, we’ve assembled an ESLint plugin to help engineers avoid common pitfalls. Additionally, we’ve encoded some patterns and techniques into a library that we call Catalyst. We intend for Catalyst to abstract away some boilerplate and provide some preferred interactions in Web Components.
InfoQ: How would you compare Web Components and React? What reasons led you to choose Web Components over React?
Oddsson: I wouldn’t compare them necessarily. Both are great technologies that might be ideal for solving various engineering problems that you may have, and you should evaluate both based on the criteria you have.
Both blog posts about how we removed jQuery from the GitHub frontend and the more recent one on Web Components allude to us wanting to rely on the Web platform rather than “buying into” a framework that we might move away from in 10 years.
GitHub engineers are especially keen about two new proposales, Template Parts and Declarative Shadow DOM, which aim to make it easier to ship Web Components.
