44 ms·
Removing jQuery from GitHub.com frontend
- thrownaway954 8y agoi 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.
- becauseiam 8y agoI agree - jQuery has done a lot to help inspire what querySelector and fetch are today (among many other things). The only cause for concern I have is what might frameworks in current vogue might do to influence standard APIs of the future.
- fruzz 8y agoI agree, you can't talk about web development history without bringing up jQuery. That said, the moment was right for something like it to come up. The amount of boiler plate code needed to enable rich web experiences of the time went up with the popularization of AJAX, and it was inevitable that something would solve that pain point.
- irrational 8y agoThat's how I feel about the current state of web development. It really feels like the right time for something to come up and replace React/Vue/Angular with all of their myriad associated libraries for data, routing, etc. Something that is incredibly simpler.
- unaaaa 8y agoVue is already ridiculously simple; how much easier can it get? You don't even need to mess around with a complicated build pipeline, just reference the vue lib in a script tag and get going.
- irrational 8y agoWhat I really want is it to be built into the browser so I don't have to use a library at all for the things React/Vue/Angular do.
- xellisx 8y agoMoo tools...
- mtmail 8y ago> 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 8y agoI also remember Scriptaculous which at some point got somehow merged with Prototype and became Protaculous.
- hitekker 8y agoEh, they have their place in history but jQuery was at least 10x more popular than all of the others combined. Strong leadership without the bickering and bikeshedding that ruined its competitors.
- pmlnr 8y agoI started with prototypejs. I never understood why jquery was the one that really took off.
- thrownaway954 8y agoI should also mention that Dean Edward's cssquery was the inspiration behind jquery. https://en.wikipedia.org/wiki/JQuery#History https://en.wikipedia.org/wiki/JQuery#History
- mosdl 8y agoadd gave us lots of devs who don't know how to use the DOM directly without jquery.
- Piskvorrr 8y agoAnd don't get me started on people who have strictly zero idea about TCP/IP. Or silicon wafer design, for that matter.
- brailsafe 8y agoYa ya thanks John. Real subtle.
- ninkendo 8y agoI've only really worn a "web developer" hat twice in my career so far (both for internal tools), once in 2011-2013, and another from 2014-2015. The first time around was rails with HAML/sass, with a light sprinkling of jquery used like CSS, mainly to make things like sortable tables, search w/ typeahead find, and a few other fancy things work. The second time around I used rails as a REST api and wrote an angular 1.x SPA for the frontend. Honestly, the first time around was far, far nicer from a developer ergonomics perspective. Just writing your HTML in nice reusable, composable templates, even though there's a lot of scary abstraction violations being able to access @variables from your ruby controllers, was a very straightforward experience. And the jquery was used mostly like CSS with something to the effect of `$("input.search").search({...});` to just apply a jquery plugin to all css-selected elements indiscriminately. And you know what? It was pretty darned easy! Move onto the next problem. My angular experience was far more complicated, and building the SPA was a level of effort on par with designing an entire application from scratch, with almost as much time spent developing it as I spent on the backend code. You can talk a lot about how jquery isn't necessary because you can do equivalent stuff without it, and I'd totally agree, but it was just the perfect tool for what I needed it for at the time. Lots of awesome plugins to enhance (with graceful fallbacks) the views that rails spit out, without me having to write anything. Angular had lots of cool plugins too but the level of effort was just too high.
- patorjk 8y agoAround 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.
- jotato 8y agoI'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.
- RobertRoberts 8y agojQuery was awesome, and needs to be entered into some kind of web-tech historical hall of fame. But it's time has come to be replaced. I had used Prototype.js, and just a couple years ago finally gutted it from our code base. And shortly after started removing jQuery. It's a long slow process. After starting with Vue.js, I completely understand why jQuery is no longer needed. Vanilla JS/CSS3 does 98% of what jQuery did for us, and our own micro-library fills in the blanks. And Vue is replacing all the jQuery scaffolded apps. If it weren't for reactive interface libraries though, jQuery would still be a staple. One example, I use a jQuery library for sorting tables. When I saw how sorting a table is so basically easy in Vue.js, that no plugins or 3rd party code needed, I saw the downfall of jQuery in general.
- thermodynthrway 8y agoI don't even bother with vanilla JS. Babel and Typescript let you magically use the latest features without caring about compatibility at all really, except CSS
- StavrosK 8y agoHow big is the compiled output?
- munchbunny 8y agoIn my experience (compiling TS + babel down to ES5), the compiled output is generally fine. Unless you're trying to squeeze every last kb out of it, asset optimization and NPM dependency bloat are much bigger optimization opportunities anyway.
- 8y ago
- mattbierner 8y agoHow 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 8y agoThe 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 8y agoReally? 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 8y agoCertainly 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)
- ape4 8y agoI assume jQuery itself will use this modern browser functionality. Making it smaller.
- floatboth 8y agoWell, 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.
- TamDenholm 8y agoJust 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?
- topoftheforts 8y agoYes, cash.js[0] does almost that, although it doesn't mirror all of jQuery's methods (like .fadeIn() .fadeOut() for example) [0] https://github.com/kenwheeler/cash/ https://github.com/kenwheeler/cash/
- TamDenholm 8y agoThanks! This is the kind of thing i was interested to find out about.
- driverdan 8y agoWhat 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 8y agoFYI 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 8y agoTrue. I quickly threw that out as an example.
- TamDenholm 8y agoYes i mean exactly that, but implementing as much of the jQuery library as possible, or certainly the most used parts. Was just a thought excercise.
- interlocutor 8y agoRemoving 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.
- Sephr 8y ago> other things such as replaceWith() and before() are not available even in Edge Huh? http://youmightnotneedjquery.com/#replace_from_html http://youmightnotneedjquery.com/#replace_from_html and http://youmightnotneedjquery.com/#before http://youmightnotneedjquery.com/#before show solutions that work in IE8+ and Edge.
- interlocutor 8y agoThe replaceWith() function as documented here does not work in IE: https://developer.mozilla.org/en-US/docs/Web/API/ChildNode/replaceWith https://developer.mozilla.org/en-US/docs/Web/API/ChildNode/r... You may be able to find hacky alternatives, but if you use jQuery you don't have to.
- Sephr 8y agoelement.replaceWith(replacement) is just an alias for element.parentNode.replaceChild(element, replacement) with some bonus functionality to convert strings to DOM text nodes. parentNode.replaceChild is not exactly a 'hacky' alternative. Here it is in the form of a basic polyfill that only supports Elements: Element.prototype.replaceWith = function(replacement) { if (typeof replacement === "string") { replacement = this.ownerDocument.createTextNode(replacement); } this.parentNode.replaceChild(this, replacement); }
- ergothus 8y agoAs 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.
- softwarefounder 8y agoIt'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 8y agoThat'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 8y agoFor 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 8y agoThat'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 8y ago> 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.
- chrismorgan 8y agoFor finding parents matching a selector, there’s a fairly recent addition, Element.closest(). There’s not magnificent support for it yet (notably, no IE), so you will probably need a polyfill.
- Twisol 8y agoThe `$.extend` example seems a little overdone -- isn't `Object.assign({}, objA, objB)` a sufficient replacement for most uses?
- h1d 8y agoThe simplicity of the grammar is what counts here.
- Twisol 8y agoI 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.
- lousken 8y agobut is the page smaller/faster now? that's what matters
- jcl 8y agoApparently, 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 8y agoSurprised they are using flow, the new version of their Git GUI is written in TypeScript
- rident 8y agoI 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.
- G4BB3R 8y agoI hate when I see a javascript question in stack overflow and all answers use jQuery without needing it.
- captain_perl 8y agoAs 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 8y agoRight on! You may want to look into Sweet Alert, it's super easy to integrate! https://sweetalert2.github.io https://sweetalert2.github.io
- geuis 8y agoNothing 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.
- deleted 8y ago[deleted]
- EugeneOZ 8y agoWithout comparison of performance "before" and "after" (in numbers, not words), this news doesn't have any sense.
- Lurkars 8y agoA 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 8y agoDon'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?
- Daycrawler2 8y agoModern 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.
- jhabdas 8y agoGreat. How about removing the actual performance bottlenecks now? And the single point of failure.
- drawkbox 8y agojQuery 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
- k__ 8y agoI 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 8y agoIMO, 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.
- infinity0 8y agojQuery 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 8y agoHowever, 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 8y agoYou 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.
- some1else 8y agoThe thing that I found surprising is their foray into web components: https://github.com/github?utf8=%E2%9C%93&q=-element&type=&language= https://github.com/github?utf8=%E2%9C%93&q=-element&type=&la.... Custom elements are probably a great fit for .erb templates.
- franciscop 8y agoI 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!
- rkuykendall-com 8y ago> 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.
- Caipenghui 8y agoNo.