
Removing jQuery from GitHub.com frontend - andyonthewings
https://twitter.com/mislav/status/1022058279000842240
======
interlocutor
Removing jQuery is not always a good idea. The best advertisement for jQuery,
ironically, is this site:
[http://youmightnotneedjquery.com/](http://youmightnotneedjquery.com/) Look at
how simple things are in the left column, and how much more code is needed in
the right column.

jQuery has many convenience features such as chaining, for example:
item.addClass('selected').siblings().removeClass('selected'); and you don't
have to check for nulls after each selection.

Many functions such as closest() and remove() have no equivalents in IE11, and
other things such as replaceWith() and before() are not available even in
Edge.

For simple sites it is easy enough to remove jQuery, but for more complex
javascript applications, especially apps that have a lot of interactivity,
removing jQuery will result in more code, or you will end up writing a lot of
utility functions thereby creating your own little clone of jQuery.

~~~
zackbloom
I was one of the developers who made
[http://youmightnotneedjquery.com](http://youmightnotneedjquery.com). To be
fair, we made it in... 2014? There is a lot you can do now which you couldn't
do then, just with a browser. A lot of the challenging examples, like
animation, you're better off doing with straight CSS.

Ultimately, I haven't actually used jQuery for anything serious in half a
decade, and somehow I manage.

~~~
sbjs
I kind of imagine we will one day have a basic poly fill for all the cross
platform issues jQuery actually excels at, and then we truly won’t need jQuery
since that’s all it’s really good at these days. Things like chaining are an
anti pattern and lead to brittle code!

~~~
Piskvorrr
Oh, but we already do have that, over there:
[https://jquery.com/](https://jquery.com/)

What's with the trend "jQ is old, old is bad! We need something that does the
same thing, and most importantly _is not named jQuery_ "?

~~~
AmericanChopper
Most DOM manipulation in jQuery goes through jQuery.globalEval, which uses
eval(). Meaning if you want to have a CSP, you have to allow unsafe-eval if
you need to support jQuery.

CSP is an incredibly useful tool, and it’s close to impossible to use it
properly with jQuery.

~~~
lmm
First concrete, legitimate reason I've seen all thread. Is there something
fundamental about jQuery's design that forces it to use eval(), or is it
possible a new version could avoids that?

~~~
AmericanChopper
Performing evals is a core part of the design. Take a look at the additional
notes section on this documentation of the .html method.

[http://api.jquery.com/html/](http://api.jquery.com/html/)

>By design, any jQuery constructor or method that accepts an HTML string —
jQuery(), .append(), .after(), etc. — can potentially execute code

This makes jQuery less safe in general, but I think the CSP restrictions this
puts in place are probably a greater issue for most people. I’ve been involved
in retro-fitting strict CSPs into a few projects, and more than once I’ve been
thwarted by very minor use of jQuery in a couple of places.

~~~
sbjs
It's part of the design _of the creation of new elements_. But that's just one
part of jQuery, and a part I would be completely okay with jQuery getting rid
of.

------
jotato
I'm impressed. I don't think the web would be where it is today without
JQuery, and being able to completely pull it out is pretty awesome. Not
because of JQ-hate, but web standards have improved that much.

~~~
munchbunny
I think it's a testament to jQuery's influence that, even though many of us
don't use it today, we still often think in a jQuery way. The most useful
common bits of jQuery's approach got baked into standards.

I think it's impressive that even when I'm not using jQuery (haven't in many
years), I find myself writing code using features/capabilities where jQuery
was an obvious inspiration.

~~~
Macha
I mean, when you think about how many people were using jQuery for

(a) cross-browser compatibility, which mostly works now (except for cutting
edge stuff, which is pretty optional) (b) $.ajax (uses that could be replaced
by window.fetch) (c) Sizzle (Replaced by document.querySelector[All])

~~~
Piskvorrr
Yeah. And IIRC, all of this came about as "let's take these awesome pieces of
jQuery (which were written because browsers sucked) and reimplement them
natively." Now the roles are apparently reversed, with jQuery being the Big
Bad?

------
thrownaway954
i offer wonder where the state of the web would be if John Resig never would
have created jquery. i think everyone who is into web development today owes a
thank you to him. jquery single-handedly made programming on the browser
easier.

~~~
mtmail
> jquery single-handedly made programming on the browser easier.

Besides jQuery there were several competing libraries abstracting the browser
inconsistencies: YUI (Y=Yahoo), prototypejs, mootools, dojo. So I'd say multi-
handedly.

~~~
jordigh
I also remember Scriptaculous which at some point got somehow merged with
Prototype and became Protaculous.

~~~
duiker101
That's like, the hardest name I've ever had to read.

~~~
sushid
Reminds of the old days when Karma was named Testacular.

------
patorjk
Around 8 years ago I was on a project where my boss told me the web app I'd be
working on was really slow, and they needed me to help them speed it up. When
I took a look at it, I discovered the app was using a multitude of libraries
with overlapping functionality - jQuery, ExtJS, Mochikit, YUI, and I think a
few others. Every previous developer had simply included their library of
choice when working on the app, and it had made the app overly bloated (and
complicated). Definitely a good sign that browser APIs and their polyfills
have become good enough for standard web app development.

------
mattbierner
How much of the reaction to this is: "isn't it neat that web standards have
advanced enough that we don't need jquery anymore," vs a pile on of: "jquery
teh sucks cause it's old and stuff."

~~~
brink
The web has modernized. Browsers are kept up to date now more than ever.
jQuery helped support antiquated browsers, but that niche is no longer nearly
as prevalent as it once was.

~~~
h1d
Really? jQuery is not just about jQuery itself but its host of plugins make it
very powerful. I still use some date picker even though input fields have
supported date type but they look inconsistent across browsers and don't look
as good as some of the jQuery plugins and it's just 1 example.

~~~
cogman10
Certainly there is a lot of old infrastructure around jQuery. There is also a
lot of infrastructure around Java's Swing.

But, the point isn't that those things exist or that there are a lot of them.
The point is that jQuery's biggest value add, at the time, was it had a very
consistent and fairly fast development across several browsers. In the bad old
days, IE, firefox, and Safari all had vastly different and divergent sets of
features. Heck, half of the stuff jQuery did was stuff you should be able to
do with CSS but couldn't because of how differently CSS behaved across
browser. This was one of the biggest value adds of jQuery. (I went through the
bad old days.. they were hell)

------
franciscop
I have created one of the decently popular jQuery light (3kb) alternatives:
[https://umbrellajs.com/](https://umbrellajs.com/)

And I do not always recommend it, indeed for smaller projects you might be
better off with plain Javascript:
[https://umbrellajs.com/documentation#native-
methods](https://umbrellajs.com/documentation#native-methods)

But native Javascript, as explained there, is more error-prone while jQuery
(and Umbrella) are more permissive. Both have their pros and cons, but if you
try to make native Javascript as permissive as jQuery you'll end up with a big
mess. Unless you create some internal methods, which then you bundle, test,
release, and... end up with another jQuery clone!

------
Daycrawler2
Modern front-end dev is all about over-engineering things with MVC libraries
and whatnots, but for the love of God one shall not use jQuery.

------
softwarefounder
It's all fun and games, until you have to access parent elements.

You'll likely start wrapping these methods, and before you know it, you have
jQuery-micro.

~~~
scottharveyco
That's what I have, a very small helper library that contains 5 or 6 functions
that I use frequently like .closest(), .hideAll(), .showAll() etc.

My application doesn't use much JS so this seems reasonable to me instead of
including a framework for a few functions.

~~~
bzbarsky
For what it's worth, [https://caniuse.com/#feat=element-
closest](https://caniuse.com/#feat=element-closest) is supported by everyone
except IE (and Opera Mini, I guess).

~~~
Piskvorrr
That's exactly the point! "Oh, you can code [a polyfill] yourself, and it will
work. Mostly. Sort of. jQuery bad, reinventing the wheel good! Never mind that
you originally went there to implement some business logic, let's get tangled
in the myriad almost-almost-working combinations."

~~~
minitech
> Oh, you can code [a polyfill] yourself, and it will work.

Use a polyfill that already exists. Take it out when browser support is there.

------
infinity0
jQuery is actually one of the nicer javascript libraries.

\- knows what it is, i.e. a web javascript module, it doesn't try to
inappropriately wrap itself in CommonJS/AMDJS wrappers

\- doesn't need node/npm to run

\- doesn't need node/npm to build

~~~
maaaats
However, it would be nice if I could include the parts I wanna use. Similar to
lodash/underscore. Now it's either full jQuery or nothing.

~~~
ino
You can do that by building it with only the modules you want:
[https://github.com/jquery/jquery/blob/master/README.md](https://github.com/jquery/jquery/blob/master/README.md)

There's also an official slim build without ajax and effect modules.

------
TamDenholm
Just curious, does there exist a library that uses jquery syntax but with
modern vanilla JS as the guts? i'm sure someone must have done this but i dont
know about it. I'm interested to know if you could just replace the jquery cdn
link for this and have your old jquery code still work?

~~~
driverdan
What do you mean by jQuery syntax? jQuery has a lot of features. If you mean
the query selector you can do

    
    
        let $ = document.querySelectorAll;
    

If you mean chaining commands you can use the latest version of jQuery. It
uses querySelectorAll under the hood.

~~~
mattlondon
FYI I believe it is generally considered better to prefer const over let if
the value is never going to change. Prevents accidentally reassigning $ here.

~~~
driverdan
True. I quickly threw that out as an example.

------
geuis
Nothing but respect for jQuery. It has had such a wide range of influence on
both javascript and the browser ecosystem. The good thing about a great tool
is that when the problems it solves no longer exist and can be retired
gracefully.

------
rkuykendall-com
> What did we replace it with? No framework whatsoever

They bragged, about the single worst web UI I have to use on a daily basis.
Github.com combines the worst elements of static and dynamic web-pages:

\- If something gets updated on the backend, it will update on the frontend

    
    
      - Except all the times it doesn't
    

\- If you change something on the frontend, it will update on the page

    
    
      - Unless you interact with the page in any way after that, like changing tabs???
    

What you end up with is a frontend that uses a lot of AJAX, but still requires
constant hard refreshes to see accurate information. It's an absolute
disaster.

------
ape4
I assume jQuery itself will use this modern browser functionality. Making it
smaller.

~~~
floatboth
Well, they threw away the Sizzle selector engine once querySelector became
available everywhere, but other than that… eh. I don't think they use fetch or
Web Animations or anything like that.

------
EugeneOZ
Without comparison of performance "before" and "after" (in numbers, not
words), this news doesn't have any sense.

------
k__
I started my JavaScript career in 2011 with the two books "JavaScript - The
Good Parts" by Crockford and "Professional JavaScript Techniques" by Resig.

Somehow all the time I'm doing JS, people were talking about how jQuery was
"an old library" and "the old way to do things" even in 2011.

2 years ago I was on a JavaScript meetup and some guy, who did interfaces for
stock trading, said: "We had to write our own framework, because jQuery just
didn't cut it anymore!"

I just thought, no shit, it's 2016 and NOW you talk about replacing jQuery?
Since its inception I used 4 different frameworks and even when I started in
2011 it was already "old news". Where have you been living if you had the
impression there is only jQuery and "your own framework"

~~~
juice13
IMO, jQuery is still very usable for all the "almost static" web sites out
there. Sure there are smaller and arguably better options out there, but
there's no harm in using it if you're used to it.

I don't see why it being old is an inherent problem.

------
ergothus
As noted by others, jQuery was essential in carving a path between the past of
browser incompatibilities and the modern form of mostly reliable and evolving
standards. It was hardly alone - other libraries did their part, evergreen
browsers are essential, and the list of people doing a lot of thankless work
is long and unassembled - but it was nonetheless an essential piece.

I want to clarify a bit about "JA Hate" though: Most of it stemmed not from
JQ's limitations or age, but rather as a matter of architecture. While it's
cool these days to smugly enjoy the options of vanilla JS, JQ hate was around
before those standards were reliably implemented.

JQ really stepped in when dynamic web pages (i.e. pages that modify their own
HTML without page refreshes) were becoming a thing. AJAX calls were new (to
most) and exciting. form validations that didn't require 2-3 seconds to load,
etc. All made far, far easier by the APIs JQ had.

BUT there were complications: JQ plugins meant that having multiple copies of
JQ on the page tended to not work well - and that happened if you were
mingling content sources. JQ didn't require it, but many coders would use the
DOM to store data (JQ made it so EASY), which worked well short term but
caused troubles. Example: If you have a list of items, with every other item
shaded, and every item had some metadata in the HTML, and then you wanted to
remove some items, what did you do? More importantly, when you wanted to
restore them, where did it come from? If you were tracking everything in a JS
variables and building the DOM, no problem, but if you were using the DOM to
hold your data, you had issues. Even if you WEREN'T using the DOM to track
your state, repainting all the DOM got expensive - a table of 10 items worked
great, but a table of 1000 could bog down terribly.

Ultimately someone would inherit (or create) a convoluted mess of JQ and blame
JQ rather than the creator.

Much of the JQ hate came not from JQ flaws, but the flaws of coding done in
the face of JQ success (as has happened with so many
languages/libraries/frameworks before and since). We've learned from those
flaws AND successes though - querySelector() basically uses the sizzle syntax;
modern virtual dom libraries deal with the DOM pains; be it React's
Unidirectional flow or Angular's two-way binding, the goal is not to use the
DOM to hold state; and every AJAX library out there tried for a better
interface (arguably fetch() beat them all). We're still hashing out how to
handle reusable pieces of non-static HTML, but there are many options.

So congrats to anyone that doesn't need JQ, and no hate to those that use it
if they strive to use it well. I can only hope to write something hated for
the results of success that nonetheless leaves the world better off.

------
captain_perl
As a vanilla-JS guy for 2 decades, I can say that you can go far without any
frameworks, especially now.

The one feature I miss that jquery has is dialog boxes that can be customized
with HTML.

Does anybody know of any cross-browser javascript dialog functions?

~~~
artificial
Right on! You may want to look into Sweet Alert, it's super easy to integrate!
[https://sweetalert2.github.io](https://sweetalert2.github.io)

------
rident
I recently replaced jQuery on a project with a small custom DOM library. It
cut more than 20% from the footprint of the application and helped to push
load times on 3G under 3 seconds.

If you use some of the weirder stuff in jQuery or use plugins you might end up
doing some targeted refactoring or just porting that code but I found it a
relatively painless transition to make.

Tip: write unit/integration tests for the code you're about to convert as it
makes the process much easier and faster.

------
some1else
The thing that I found surprising is their foray into web components:
[https://github.com/github?utf8=%E2%9C%93&q=-element&type=&la...](https://github.com/github?utf8=%E2%9C%93&q=-element&type=&language=).

Custom elements are probably a great fit for .erb templates.

------
Lurkars
A bit OT: In my personal projects, it's easy to use plain JS instead of
jquery. But as soon as I start dealing with object- and array-data (formally
json), I cannot miss the underscrore.js library. At least without it, I start
writing my own helpers for some actions on obj/arrays.

------
ngrilly
Don't you miss jQuery set-oriented operations, like $('.widget-
item').removeClass('.selected')?

With querySelectorAll, you have to iterate over all the matching elements. Do
you use some shortcut?

~~~
awy
querySelector() will get you one element, otherwise you can use something like

Array.from(querySelectorAll('*')).forEach()

It is a little more cumbersome.

~~~
ngrilly
Yes, this is what I do, and I agree it's a little more cumbersome. That's why
I asked ;-)

------
lousken
but is the page smaller/faster now? that's what matters

~~~
jcl
Apparently, yes. The author tweets later in the thread that the benefits they
have seen include:

"Fewer kb sent to visitors, more explicit syntax when performing DOM
manipulations, ability to use Flowjs for static type checking"

~~~
mikewhy
Surprised they are using flow, the new version of their Git GUI is written in
TypeScript

------
Twisol
The `$.extend` example seems a little overdone -- isn't `Object.assign({},
objA, objB)` a sufficient replacement for most uses?

~~~
h1d
The simplicity of the grammar is what counts here.

~~~
Twisol
I actually meant to reply to
[https://news.ycombinator.com/item?id=17612990](https://news.ycombinator.com/item?id=17612990)
, which mentions
[http://youmightnotneedjquery.com/](http://youmightnotneedjquery.com/) as a
point of comparison between jQuery and vanilla JS. For some reason I thought
that was the top-level article, not the linked tweet.

------
jhabdas
Great. How about removing the actual performance bottlenecks now? And the
single point of failure.

------
drawkbox
jQuery really pushed forward the base plane for standards in the browser. It
was a common well tested library that allowed developers more time in
developing their app/game/etc rather than testing in browsers fixing standards
holes.

Browsers are more standardized today because of it, but what will come in the
future when there isn't a library as widespread to help that effort, probably
more fragmentation and eventually more jQuery like libraries whether that is
polyfills, vdom kits, wasm, based and more.

jQuery also created a rare simplification in the front end fast moving
javascript eco-system that standardized a well tested across all browsers
library that made front end development easier rather than more complex. There
aren't lots of libraries like it today that look to make things more standard
and simple rather than adding monstrous monolithic abstractions that are
brittle to change, yet change every few months causing brittle/flaky
development.

As a webdev that developed javascript before jQuery and all the others
(mootools, prototype, scriptalicious even dhtml etc) it was a very welcome
library and may not be understood how impactful it was to development speeds
and a market standard that really helped ship products.

I feel like jQuery gets lots of underserved hate just like javascript itself
does, meanwhile they are very useful, helpful and needed tools. Tools that
simplify over adding more complexity are needed, some engineers just like to
add complexity which makes them seem smarter, when the job of an engineer is
taking complexity and simplifying it. jQuery simplified over adding
complexity. jQuery always made team developments more robust especially with
juniors on the squad, you could at least know jQuery was tested and focus on
the implementation and app over internals/support/browsers. jQuery is a
perfect simplified abstraction of common javascript needs that standardized
development from signatures to usage and eventually browsers. Just like
javascript itself which has simplified web apps and development, jQuery's
simplicity and usefulness went well beyond the call of duty. Believe it or
not, jQuery is still a good library and that is mainly because its mission is
to simplify complexity. I feel like some of the hate against jQuery is because
it simplified too much and people that like to add complexity felt it made
them seem less than, comments like "it didn't even need jQuery but the samples
were in that anyways" were because jQuery was a simplification and market
standard most of the time, and that is ok, platforms are built from good
cornerstones and libs you can trust just like native/browser standards
themselves.

I do lots of projects, some with jQuery and some without, the ones with jQuery
still seem to get less in the weeds of browser standards/capabilities than the
ones without. Native js is much better by far but even jQuery uses most of
that now. The other areas of jQuery like animation are not as useful anymore
(CSS animations). However it is still nice to have jQuery at times because
without jQuery, even with most of the useful tools available natively in
javascript, it is a common signature/library that when not present still leads
to other people making their own helpers and re-creating jQuery at least the
useful parts i.e. selectors, event handling, ajax, dom etc.

Thanks jQuery and John Resig, we'll need more libraries like you in the future
to bring front end dev back to sanity and see though standards fragmentation
again one day, for now that is numerous polyfills and vdom kits. Let the best
of the warring new jQuery's win. "The reports of my death are greatly
exaggerated" \- jQuery

------
Caipenghui
No.

------
G4BB3R
I hate when I see a javascript question in stack overflow and all answers use
jQuery without needing it.

