19 ms·
Removing jQuery is not always a good idea. The best advertisement for jQuery, ironically, is this site: http://youmightnotneedjquery.com/ http://youmightnotneed
by interlocutor 8y ago
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.
- 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); }
- interlocutor 8y agoIs that just as readable? Is the intent just as clear? Is the improved readability of the jQuery version worth the extra 80kb download to you? EDIT: Regarding the polyfill, now you are beginning to write your own little jQuery clone.
- Sephr 8y agoGitHub says they are using polyfills instead of jQuery as well. The point is to not have to rely on external frameworks.
- balfirevic 8y ago> The point is to not have to rely on external frameworks. Why is that a worthwhile goal?
- mschuster91 8y agoTo reduce attack surface as well as maintenance burden for compatibility whenever something breaks during an upgrade. A polyfill is something that's not needed at all in modern browsers and thus can be considered pretty much final. jQuery is actually surprisingly stable compared to Angular/React/npm/rest-of-the-hipster-crap, but it has had its fair share of incompatibilities too.
- Spivak 8y agoIs a set of polyfills philosophically different than a framework?
- AlphaSite 8y agoIt does get much closer when you set the minim IE version to 10.
- phyzome 8y agoYeah, it doesn't serve the site well to include the animation and XHR stuff right at the top. But if you had a small site that just needed to perform a few DOM manipulations, this would be highly relevant. If I just need to pop a div open and closed when a button is clicked, I sure won't bring in jquery just for that.
- vbezhenar 8y agoThe reason I used jQuery is to have script working on every browser in the wild. Now that jQuery dropped support for old browsers, this advantage is no more (sure, I could use old jQuery, actually I'm doing exactly it, but I don't like to use outdated versions). I think that it was one of strongest point of jQuery and the that they decided to get rid of it is questionable decision.
- deleted 8y ago[deleted]
- pferde 8y agoIt sounds like someone (motivated enough) should fork jQuery before the old browsers support got removed and maintain it as jQuery-legacy, backporting fixes from "new" jQuery" if applicable.
- nwienert 8y agoTo be fair, that site doesn't use `fetch` on the ES side which bloats all the starting examples. Further, there are many better animation libraries. And finally if you use any view framework you have very little need to be traversing the DOM.
- floatboth 8y agoThere's also the native Web Animations API!
- Ajedi32 8y agoFor comparison, here's the first example, but using fetch: fetch('/my/url').then((r) => r.json()).then((data) => { }) And as an added bonus, fetch uses promises, so in an async function that's just: let data = await fetch('/my/url').then((r) => r.json())
- aloisdg 8y agoYou can write `(r)` like this `r`. Remove clutter. You don't write `let i = (0)`
- klodolph 8y agoThat’s not a good analogy at all, the () is there in arrow functions always except, as a special case, it’s optional if there’s a single argument.
- Cthulhu_ 8y agoI'm not a fan of mixing await and .then myself; let data = await (await fetch('/my/url')).json(); That's a one-liner, but you can split the request and json data as well (and you usually want to anyway because of error handling).
- thermodynthrway 8y agoIf you have even medium complexity you're better off using something like React with Babel or Typescript. Much more sane way of event handling than JQuery, and no mucking with HTML by hand. I agree with JQuery for the most simple sites, but React+transpiler will give you much better compatibility
- ergo14 8y agoThing is react is only compatible with react ;-)
- thermodynthrway 8y agoIt's extremely easy to use React in small parts of the page and spread it out over time. It's a couple lines of code to init React in a div and fully supported. You can even communicate between React bits spread across the page. React also let's you mark areas/divs within its domain as "don't touch this". So in those areas you can use things like that old map widget you love so much, without resorting to iframes Angular is a huge fail in this regard. Zero support for mixing with "non angular" pages.
- FLUX-YOU 8y agoAngular is a nightmare for complex UI interactions for components that are spread out. I'm sure experienced people know how to do that properly, but it's really difficult starting out.
- thermodynthrway 8y agoAngular's learning curve is the worst I've ever seen. We mostly use it because "Enterprise" but I prefer React when we get permission for that reason. Too much abstraction, too much magic. It's possible to do just about anything but the docs are sparse enough that you'll be crawling through github PR's and source to figure out how to achieve it sometimes
- EugeneOZ 8y ago
- zackbloom 8y agoI 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 8y agoI 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!
- brailsafe 8y agoI think those are some broad generalizations that I can't agree with, but Sizzle might be what you're looking for. https://github.com/jquery/sizzle/wiki https://github.com/jquery/sizzle/wiki
- floatboth 8y agoSizzle is ancient history at this point. It's the selector engine jQuery used before querySelector became available everywhere.
- prophesi 8y agoWhile we're on the topic of our favorite JS toolsets, I've been having a blast using just a ES6 transpiler and Greensock. No need for neither jQuery nor a giant SPA framework.
- Shorel 8y agoIf you only care about writing code, sure. But in this case (as in many others), code is written just a couple of times per month, and executed millions of times per day in millions of computers all around the world. Therefore this kind of "low level JavaScript"* optimizations will have a net benefit much, much bigger than the convenience of reading shorter code for a relatively small group of people. * Quite the contradiction, I know.
- andrei_says_ 8y agoEach computer executes it a limited number of times, with lightning speed. Differences are imperceptible. The cumulative effect you are speaking of is hypothetical. Writing code which just works on multiple browsers results in faster development and easier to maintain code and frees dev cycles to focus on performance.
- bihnkim 8y ago> frees dev cycles to focus on performance Perhaps this is the case--jQuery saved them so much time that they've reached a point where they are free to optimize their frontend by removing jQuery.
- kthejoker2 8y agoKnuth would approve. If you don't have a product, what are you optimizing?
- andrei_says_ 8y agoMaybe these are not the same developers? I know I may be replacing jquery with stimulus or eventually vuejs but writing 5 lines of jquery code for my MVP is exactly the right balance today.
- Shorel 8y ago> Differences are imperceptible. That argument sounds very postmodern. The main issue with perception is that it easily tricked and even more, it can be strongly influenced by bias. The cumulative effect can surely be measured and reasoned about. It is very different to program for your new startup idea where adding features faster than your competition is more important than anything else in order to grow your user base, compared to improving an established product already being used by millions of people. Different needs, different approaches.
- nostalgeek 8y ago> 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. Many of these can be polyfilled, Going the polyfill route IMHO is a bit better. I use this now : https://polyfill.io https://polyfill.io .
- WorkLifeBalance 8y agoThat polyfill relies on a third party which can then effectively gain analytics for your site. They store and keep the referring URLs and user agent combinations.
- nostalgeek 8y ago> That polyfill relies on a third party which can then effectively gain analytics for your site. They store and keep the referring URLs and user agent combinations. That polyfill relies on nothing since you can run your own custom 'polyfill' server, or just download the bundle and serve it from your website. It's completely open source. https://github.com/Financial-Times/polyfill-service https://github.com/Financial-Times/polyfill-service You're complaining that a public CDN runs some analytics. But they all do that, and this project doesn't mandate that you use their CDN.
- rado 8y agoBloat and slowdown for the customer is not worth the dev convenience and no library can fix poor work organisation.
- Raglov 8y agoIt's rather ironic how in object-oriented programming chaining is considered a bad practice, e.g., breaking the Law of Demeter.
- pwm 8y agoIf GP is correct re failure propagation then this is monadic composition vs. OOP object chaining.
- andybak 8y ago> breaking the Law of Demeter How so? You have an instance. You're allowed to call methods or access properties of that instance. You're not supposed to call methods or access properties of properties. So chaining is just: $foo.something().somethingelse().blah(); At each point you're getting a new instance and accessing that. You're never reaching inside of a property of that instance.
- GlitchMr 8y agoThings have changed since then. For example, AJAX now is much simpler to use than it used to be. async function printExampleCom() { let response = await fetch("https://www.example.com/") // NB: Response has other methods like json. console.log(await response.text()) } printExampleCom() You need a polyfill for `Request` for Safari and Internet Explorer (but not Edge), but that's about it.
- shams93 8y agoYeah actually I stead of so much focus on frameworks it's better to focus on better polyfill implementations. It's only a temporary issue in many cases but the larger web does move slowly and then stardards like web components sometimes take a deacde or more to be fully baked. Wasm based polyfill would enable more browser maker innovation and competition without leading to slow and bloared pages for all but one device.
- Spivak 8y agoWhat's the point of polyfilling a nice API when you could just have a nice API to start with which leverages native functions when present? They don't seem to be philosophically different. Or stated differently, "jQuery is just a JS polyfill for browsers that don't support native jQuery yet."
- Spivak 8y agoIs there really much of a philosophical difference between a polyfill that exposes a common API and emulates when not present and a library that exposes a common API and uses native functionality when present?
- macca321 8y agoI don't think there's a good replacement for: $(document).on("click", "#foo", function(){...}); either
- benaadams 8y agoCan do it in < 629 Bytes https://github.com/benaadams/delegate-dom.js https://github.com/benaadams/delegate-dom.js
- nailer 8y agoIndeed its easy! But damn it gets boring having everyone patch the DOM with things that should be in the standard DOM API already by now.
- pawelk 8y agoEvent delegation was a thing before jQuery, and is not that hard to implement as a helper function, e.g. https://jsfiddle.net/jbctqupz/ https://jsfiddle.net/jbctqupz/
- Vinnl 8y agoIs that not simply document.getElementById('foo').addEventListener('click', function() { ... }); ?
- talmand 8y agoWell, it could be. As long as #foo exists on the page at the time that line is executed. If you inject #foo into the page after load then the click event won't work. The jquery example delegates #foo, so it can be injected in the page after load and the click event will still work. But there are ways to mimic the behavior as another person has pointed out.
- combatentropy 8y agoThe vanilla equivalent of: $(document).on("click", "#foo", function(){...}); is: document.addEventListener('click', function (ev) { if (ev.target.matches('#foo')) { } }); The advantage is that #foo can come and go (after page load be injected and removed and injected again, but the event listener must be registered just once. Since the example is an ID (#foo) the advantage is less obvious. Something like a class (.foo) makes it clearer that there could be many, and it could get expensive to attach an event handler to each one --- though I'm guessing it takes hundreds before it becomes a big deal. But again, .foo's can come and go without having to worry about reattaching the event handler. P. S. My library, https://github.com/combatentropy/listenup.js https://github.com/combatentropy/listenup.js (31 lines)
- austincheney 8y agoIt isn't about writing code. As a developer writing code is your job. If writing a couple of extra lines of code makes you sad then perhaps this isn't your cup of tea. For me it has always been about performance. jQuery is slow. Even way back in the day before JavaScript got fast you could access the DOM quickly if you knew what you were doing. Likewise DOM access could easily make your code 5 times slower if you didn't know what you were doing. Since 2012 JavaScript has been fast in every major browser and querySelectors are a standard feature. Since about that time accessing the DOM has always been 10s-100s of times faster than using the standard querySelectors. In Firefox it is 10s of thousands of times faster. The standard querySelectors are faster than using modern jQuery. To me this is the difference between a junior developer and a competent developer. Some people NEED the extra help. I understand that. If product quality and achieving a superior user experience are important though you will simply figure out a better way of writing code, especially since writing code is probably your job.
- yAnonymous 8y agoSoftware development is a lot about making good use of resources and if you reinvent the wheel for every job you do, maybe it isn't your cup of tea. I've worked with developers who completely ignored good libraries and instead created their own terrible implementations. They got nothing done and what they did was a buggy mess that often needed months of patching. Finding a good middle ground is the best way to go and when the loading time increases by only a few milliseconds, but the development is a lot faster and cheaper, that's a good compromise in most cases.
- posting2fast 8y ago"friend to your coworkers, enemy to your craft"
- austincheney 8y agoCliche ad nausium. It’s like saying I should never have to write my name more than once, because it is reinventing the wheel. In this case every call to the DOM goes from a slow baby crawl to rocket speed. In no other aspect of life do people make such empty excuses, using cliches no less, to intentionally remain in the stone age.
- Cthulhu_ 8y agoThat's one paradigm that operates directly on the DOM, but, a lot of modern-day development tools (e.g. redux) don't work like that, and their programming model is a lot more straightforward than "remove the selected property from all siblings", instead just having a selected boolean expression for each element. The performance question becomes a bit more tricky too then, because instead of comparing direct DOM manipulation you're comparing 'rendering' as a more abstract concept.
- scns 8y agoMaybe the percentage of people browsin github on IE11 is 0%?