What to use if github doesn’t use jq?

Recently, we completely removed jQuery from the front-end code of GitHub.com, which marks the end of our gradual process of gradually removing jQuery over several years. This is a milestone for us. event. This article will describe how we relied on jQuery in the past, and over time we realized that we no longer needed it, but in the end we did not replace it with another library or framework, but used a standard browser The API implements everything we need.

In the early days, jQuery meant a lot to us

GitHub.com started using jQuery 1.2.1 at the end of 2007. That was a year before Google released its Chrome browser. There was no standard way to query DOM elements via CSS selectors, nor to dynamically render an element's style, and Internet Explorer's XMLHttpRequest interface, like many other APIs, suffered from inconsistencies between browsers.

jQuery makes it easy to manipulate DOM, create animations and "AJAX" requests, basically, it allows web developers to create more modern and dynamic web experiences. Best of all, code developed with jQuery for one browser will also work in other browsers. In GitHub's early days, jQuery enabled small development teams to quickly prototype and develop new features without having to tailor code specifically to each web browser.

The extension library built based on jQuery’s simple interface has also become the basic building block of the GitHub.com front-end: pjax (https://github.com/defunkt/jquery-pjax) and facebox (https:// github.com/defunkt/facebox).

We will never forget John Resig and the jQuery contributors for creating and maintaining such a useful and essential library.

Later Web Standards

Over the years, GitHub grew into a company with hundreds of engineers, and gradually established a dedicated team responsible for the development of JavaScript code Scale and quality. We've been excluding technical debt, and sometimes technical debt grows with dependencies that give us some value in the beginning, but that value also decreases over time.

We can compare jQuery to the rapid evolution of web standards supported by modern browsers:

$(selector) pattern can be replaced using querySelectorAll();

Element.classList can now be used to implement CSS class name switching;

CSS now supports visual animations defined in style sheets instead of JavaScript;

can now be used Fetch Standard executes $.ajax requests;

addEventListener() interface is stable enough and can be used across platforms;

We can use lightweight libraries to encapsulate event delegation patterns;

With the development of the JavaScript language, some of the syntax sugar provided by jQuery has become redundant.

In addition, chain syntax cannot meet the way we want to write code.

Finally, we started using Flow to annotate types to perform static type checking at build time, and we found that chain syntax is not suitable for static analysis because almost all jQuery methods return the same result. type. We chose Flow at the time because features like the @flow weak mode allowed us to gradually apply types to our untyped code base.

All in all, removing jQuery means we can rely more on web standards, make the MDN web documentation the de facto default documentation for front-end developers, maintain more resilient code in the future, and reduce the 30KB dependencies are removed from our bundles, speeding up page loading and JavaScript execution.

Custom Elements

A new technology that has been hyped in recent years is custom elements - a component library native to the browser, which means users do not need to download , parsing and compiling the extra bytes.

Starting in 2014, we have created some custom elements based on the v0 specification. However, since standards are still changing, we haven't put much effort into it. It wasn’t until 2017, when the Web Components v1 specification was released and Chrome and Safari implemented it, that we began to adopt custom elements more broadly.

While jQuery is being removed, we are also looking at patterns for extracting custom elements. For example, we convert the facebox used to display a modal dialog into a element (https://github.com/github/details-dialog-element).

Our philosophy of progressive enhancement also extends to custom elements. This means we will preserve as much of the markup content as possible before adding behavior to the markup. For example, displays the original timestamp by default, which is upgraded to convert the time to the local time zone, while for , when embedded in a

element, it can Interactive without using JavaScript, it has been upgraded with accessibility enhancements.

The above is the detailed content of What to use if github doesn’t use jq?. For more information, please follow other related articles on the PHP Chinese website!