Shulou(Shulou.com)06/02 Report--

This article mainly introduces "analyzing why jQuery is abandoned". In daily operation, I believe many people have doubts about why they abandoned jQuery. The editor consulted all kinds of data and sorted out simple and easy-to-use methods of operation. I hope it will be helpful to answer the doubts of "analyzing why you abandon jQuery"! Next, please follow the editor to study!

In the early days, jQuery meant a lot to us.

GitHub.com started using jQuery 1.2.1 at the end of 2007, a year before Google released its Chrome browser. At that time, there was no standard way to query DOM elements through the CSS selector, and there was no standard way to dynamically render the style of elements, and Internet Explorer's XMLHttpRequest interface, like many other API, had inconsistencies between browsers.

JQuery makes it fairly easy to manipulate DOM, create animations, and "AJAX" requests, basically allowing Web developers to create a more modern dynamic Web experience. Most importantly, code developed for one browser using jQuery applies to other browsers as well. In the early stages of GitHub, jQuery enabled small development teams to quickly prototype and develop new features without having to adjust the code specifically for each Web browser.

Extension libraries based on jQuery's simple interfaces also become the basic building blocks of the GitHub.com front end: pjax (https://github.com/defunkt/jquery-pjax) and facebox (https://github.com/defunkt/facebox).

We will never forget such a useful basic library created and maintained by John Resig and jQuery contributors.

Later Web standard

Over the years, GitHub has grown into a company with hundreds of engineers and gradually set up a dedicated team responsible for the size and quality of JavaScript code. We have been eliminating technical debt, which sometimes increases with the increase of dependencies, which bring us some value at first, but these values also decline over time.

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

The [] $(selector) mode can be replaced with querySelectorAll ()

[] you can now use Element.classList to switch CSS class names

[] CSS now supports defining visual animation in stylesheets rather than in JavaScript

[] you can now use Fetch Standard to execute a $. Ajax request

[] the addEventListener () interface is stable enough to be used across platforms

[] We can use lightweight libraries to encapsulate the event delegation pattern

[] with the development of the JavaScript language, some of the syntax sweets provided by jQuery have become redundant.

In addition, chained syntax does not satisfy the way we want to write code. For example:

$('.js-widget') .addClass (' is-loading') .show ()

This grammar is simple to write, but by our standards, it doesn't convey our intentions very well. Does the author expect one or more js-widget elements on the current page? In addition, if we update the page tag and accidentally leave out the js-widget class name, will the browser throw an exception to tell us what's wrong? By default, jQuery skips the entire expression when nothing matches the selector, but for us, this is a bug.

Finally, we started annotating types using Flow to perform static type checking at build time, and we found that chained syntax is not suitable for static parsing, because almost all jQuery methods return the same type. We chose Flow because features such as the @ flow weak pattern allow us to gradually apply types to untyped code bases.

All in all, removing jQuery means that we can rely more on Web standards, make MDN Web documents the de facto default document for front-end developers, maintain more flexible code in the future, and remove 30KB dependencies from our bundles, speeding up page loading and JavaScript execution.

Gradual decoupling

Although the ultimate goal has been set, we also know that it is not feasible to allocate all resources to remove jQuery at once. This hasty approach may lead to a return to website functionality. Instead, we have adopted the following strategies:

Set metrics, track the rate of calls to jQuery for an entire line of code, and monitor how the metrics change over time to make sure it stays the same or goes down, not up.

We do not encourage importing jQuery into any new code. To facilitate automation, we created eslint-plugin-jquery (https://github.com/dgraham/eslint-plugin-jquery), and if someone tries to use a jQuery feature, such as $.ajax, the CI check will fail.

There are a lot of violations of eslint rules in the old code, and we annotated them with specific eslint-disable rules in the code comments. Readers who see this code should know that it is not in line with our current coding practice.

We have created a pull request robot that will leave comments on the pull request when someone tries to add a new eslint-disable rule. In this way, we can participate in the code review as soon as possible and come up with alternatives.

A lot of old code uses pjax and facebox plug-ins, so we use JS internally to reimplement their logic while keeping their interfaces almost unchanged. Static type checking helps to boost our confidence in refactoring.

A lot of old code interacts with rails-behavior, and our Ruby on Rails adapters are almost "inconspicuous" JS, which attach AJAX lifecycle processors to some forms:

/ / Old method $_ (document) .on ('ajaxSuccess',' form.js-widget', function (event, xhr, settings, data) {/ / insert response data into DOM})

Instead of rewriting all calls immediately, we chose to trigger fake ajax* lifecycle events and keep these forms submitting content asynchronously as before, but internally using fetch ().

We maintain a version of jQuery ourselves, and whenever we find that we no longer need a module of jQuery, we remove it from the custom version and release a lighter version. For example, after removing jQuery's CSS pseudo selector (such as visible or: checkbox), we can remove the Sizzle module, and when all $. Ajax calls are replaced by fetch (), we can remove the AJAX module.

This serves two purposes: to speed up the execution of JavaScript while ensuring that no new code tries to use the removed functionality.

We give up support for the old version of Internet Explorer as soon as possible based on the results of the analysis on the website. Whenever the usage of an IE version falls below a certain threshold, we stop providing JavaScript support to it and focus on supporting more modern browsers. Giving up support for IE 8 and IE 9 as soon as possible means that we can use a lot of native browser features, otherwise some of them will be difficult to achieve through polyfill.

As part of a new approach to the development of GitHub.com front-end capabilities, we focus on using regular HTML as much as possible and gradually adding JavaScript behavior as incremental enhancements. As a result, Web forms and other UI elements that use JS enhancements usually work on browsers that disable JavaScript. In some cases, we can completely delete some legacy code without having to rewrite them using JS.

After years of hard work, we gradually reduced our dependence on jQuery until not a single line of code referenced it.

Custom element

In recent years, there has been hype about a new technology, the custom element-the browser's native component library, which means that users do not have to download, parse, and compile extra bytes.

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

During the removal of jQuery, we are also looking for patterns to extract custom elements. For example, we convert the facebox used to display the modal dialog box to an element (https://github.com/github/details-dialog-element).

Our concept of progressive enhancement also extends to custom elements. This means that we will retain as much of the tag content as possible, and then add behavior to the tag. For example, the original timestamp is displayed by default, which is upgraded to convert time to a local time zone, while when it is embedded in an element, it can be interactive without using JavaScript, and it is upgraded to have auxiliary enhancements.

The following is an example of implementing a custom element:

/ / local-time displays the time based on the user's current time zone. / for example: / / Sep 6, 2018//class LocalTimeElement extends HTMLElement {static get observedAttributes () {return ['datetime']} attributeChangedCallback (attrName, oldValue, newValue) {if (attrName =' datetime') {const date = new Date (newValue) this.textContent = date.toLocaleString ()}} if (! window.customElements.get ('local-time')) {window.LocalTimeElement = LocalTimeElement window.customElements.define (' local-time', LocalTimeElement)

We are looking forward to the Shadow DOM of the Web component. The power of Shadow DOM brings a lot of possibilities to Web, but it also makes polyfill more difficult. Because using polyfill results in performance loss, it is not feasible to use them in a production environment.

At this point, the study of "analyzing why you abandoned jQuery" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.