GitHub ditched jQuery

On the heels of this earlier discussion about JavaScript and progressive enhancement

Should browsers still allow users to disable JavaScript?

Ben Halpern ・ Aug 30 '18 ・ 1 min read

#healthydebate #webdev #javascript #browsers

I found it refreshing to read about the migration away from jQuery that GitHub successfully completed recently: Removing jQuery from GitHub.com frontend.

They did it incrementally for obvious reasons, leveraging modern browsers and (lots) of polyfills. It seems they haven't used Babel at all.

Two paragraphs of the article stuck with me the most:

As part of our refined approach to building frontend features on GitHub.com, we focused on getting away with regular HTML foundation as much as we could, and only adding JavaScript behaviors as progressive enhancement. As a result, even those web forms and other UI elements that were enhanced using JS would usually also work with JavaScript disabled in the browser. In some cases, we were able to delete certain legacy behaviors altogether instead of having to rewrite them in vanilla JS.

Our general philosophy of striving for progressive enhancement extends to custom elements as well. This means that we keep as much of the content in markup as possible and only add behaviors on top of that. For example, shows the raw timestamp by default and gets upgraded to translate the time to the local timezone, while , when nested in the element, is interactive even without JavaScript, but gets upgraded with accessibility enhancements.

Progressive enhancement is a concept at least ten years old and I'm glad more and more people are keeping it in mind.

On a side note I just noticed the feed on GitHub's homepage doesn't appear at all with JavaScript disabled :D

Comments

[Ben Halpern]

It wasn’t too long ago that jQuery was a pretty hard dependency on Rails itself.

Basic form helper functionality was entirely dependent on not only JavaScript, but jQuery.

[Sung M. Kim]

Seems like Rails area is moving faster than .NET world.

ASP.NET templates in Visual Studio still depends on jQuery & Bootstrap 3 😞.

[rhymes]

That's one of the issues of having big frameworks depend on something they don't control

[Nomm]

This is the course I'm taking as well. Vanilla JavaScript is no longer at a state it was back when browsers ran stupidly different versions of ECMAScript, rendered CSS wildly differently and so on. Things are much, much better now.

[Miff]

I'm surprised to see people going back to the basics of progressive enhancement, minimal JavaScript, and content in the markup. It's a welcome sigh of relief from ten million JavaScript libraries and layers upon layers of abstraction.

[Nate]

jQuery changed the web for the better, but it's time to put it out to pasture! I hear the next big framework is Vanilla JS!

[Lewis Cowles]

Lets be clear not everything needs to work without JS for a project to be a progressive enhancement success.

The feed on GitHub might have been deemed non-essential.

There should be better ways to handle than turning off features, but how do you get a dynamic feed without JS? You don't. Technically you could iframe it, or queue it for generation, use a refresh header, but then you risk interrupting other user behaviours.

I have a number of systems that use progressive enhancement for everything from infinite loading (prev, next, pushstate) which requires JS (fallback is standard pagination) to a SaaS GUI.

Browsers need to give people mechanisms beyond iframes if you want dynamic content without JS.

We know from the horror that is current gen single-page (garbage pile) apps that server side is a problem, but full SPA's cannot be progressive as they require JS to coordinate.

What else is missing? Does serviceworker exist without JS (it shouldn't as they are written in JS), what about the JS browsers use. If it's not off then addons & extensions could be draining battery anyhow. If it's not off, how do we ensure that malicious actors don't work out how to escalate scripts?

We need better browser-tools, native hypertext placeholder that are replaced if a URL is available are one. You can sort-of get that using headers and iframes. As my understanding goes that harms accessibility.

What about auto-complete? Firefox can search a site if you have OSD markup using search box or address bar. Could a non-JS input[type="search"] use that same data too? How do we format the results to be less than title, url?

In the case of autocomplete, what about linked fields? Some software I've written has custom markup for autocomplete content, uses linked fields, has required exists (similar to ) functionality. The only way I could get that without wasting lots of time & energy was with jQuery (although the code is nearly half-a-decade old now it works).

What about rich editing UI's like TinyMCE? It'd for-sure be nice to have some form of alternative for that which can be sent without JS. Again, a piece of software like that has no non-JS alternative I'm aware of.

Nor do any image editors with CanvasJS AFAIK

I don't have answers. I don't work for major browsers. I'm glad that large orgs are looking to avoid unnecessary JS, but it'll be a while before it can deliver native application experience, or sadly dated application experience without scripting.

[ZaneHannanAU]

For the feed thing, you can use something similar to EventSource infinite pipe. Eg:

.list {
  display: flex;
  flex-flow: column-reverse nowrap;
}
.list > .item:nth-last-of-type(n+16) {
  display: none;
}

let l, o = new MutationObserver(_=>{
  while (l.childElementCount > 64) 
    l.firstChild.remove();
});
requestAnimationFrame(function m(){
  l = document.querySelector(".list")
  if (l) o.observe(l, {
    childList: true,
    subtree: false,
    attributes: false
  });
  else requestAnimationFrame(m);
});

This is about the simplest one I can come up with btw. It's pretty dumb.

[rhymes]

Lets be clear not everything needs to work without JS for a project to be a progressive enhancement success.

The feed on GitHub might have been deemed non-essential.

Sure, I was totally teasing :-)

There should be better ways to handle than turning off features, but how do you get a dynamic feed without JS? You don't. Technically you could iframe it, or queue it for generation, use a refresh header, but then you risk interrupting other user behaviours.

You can probably simply render the last 10 items of activity in HTML and that's it.

This is how the page looks without JS:

I don't have answers. I don't work for major browsers. I'm glad that large orgs are looking to avoid unnecessary JS, but it'll be a while before it can deliver native application experience, or sadly dated application experience without scripting.

I feel like we're on different points on this. The purpose of progressive enhancement is not to give users the same exact experience, is to give users a functional experience. I can use GitHub without JS but I know I lose comment previews and stuff like that. The website goal is still 100% reached.

To use a search bar you don't need autocomplete and so on. Also why would you need service workers in a HTML + CSS web app?

I applaud your effort but I don't share the same goal.

The failure is when with JS turned off you get no website or a broken one.

I was reading an article (only images and text) on Vice Italy a few minutes ago, just for curiosity I tried to reload the article link with JS disabled and I got a blank page, with nothing on it. I have no idea what CMS they use but there's no reason in the world to have a magazine website to be completely broken without JS.

The point of progressive enhancement is to let me read the content and see the images even if I don't have flashy animations or preloading :D

[Mihail Malo]

Interesting that GitHub, of all places, cares about progressive enhancement.
I wonder why?

[rhymes]

Why are you surprised?

Its UI is used by millions of developers in all countries of the world with all sorts of networks and browsers. Its Global Alexa rank is 60, according to Moz is at 38 (!): moz.com/top500

It's basically a public service website, hence they need to cater to most clients

[Mihail Malo]

I am not aware of any countries with an embargo on running JS.
It's the user's choice to disable JS.
An application shell that acts more like an installable app than a website, using Service Worker and caching data can perform a lot better on worse networks than a classic website.
Yes, that can be combined with server-rendered first load, but that's a ton of added complexity for developers.
Seems strange they go to such an extreme in the exact opposite direction.
What is described here and what I spotted myself seems like something that would benefit Wikipedia and allrecipes.com, but not GitHub of all things.

(And yes, the dark web should use modern web development practices as well, it's essential considering the bandwidth and latency impact)

[rhymes]

Ok probably there's some miscommunication here. GitHub has always been a progressive website (not progressive web app, just a website with progressive enhancement), it just was a mish mosh of JS with jQuery, they documented over the years the evolution of the web app and now they decided to remove jQuery. That's it.

[Mihail Malo]

Yeah, doesn't seem like the right choice to me.
Obviously, I am wrong and they are right, so I was curious about the rationale.

[rhymes]

As described in the article: they had a website that worked made with jQuery, the goal was to send less JS so they replaced jQuery with native JavaScript and a few polyfills. I think that's all the rationale :-)

[Harry Dennen]

It's nice to see that graceful degradation is no longer considered the only option.

[Nazim Boudeffa]

Does somone knows what is the replacement of JQuery ?

[Vernon Joyce]

As rhymes said it depends on your use case. In my view JQuery is great for projects with a lot of interactivity, animation etc. and I wouldn’t go through the effort of replacing it in these cases.

[Matteo Rigon]

Just plain javascript in most cases. If all you do with jquery is basic DOM manipulation (target elements with a css selector, add/remove classes, read/edit attributes) then jquery is completely superfluous as long as you don't support IE9 and below

[rhymes]

It depends on what you want to accomplish. jQuery is not bad per se, it's just that JavaScript (in the form of ES6+) is getting better and getting wider support, so you might not jQuery in its entirety: youmightnotneedjquery.com/