44 ms·
You might not need jQuery (2014)
- barnaclejive 6y agoSomeone should make a youmightnotneedspringboot.com
- nobleach 6y agoWell sure, you could do so much better with a small library like Vert.x (which I love). But getting an entire app framework with config/routing/db connectivity/etc is just so easy with Spring Boot. Plus, you get a vast ecosystem. Now the memory usage and compile times? Yeah, youmightnotneedspringsmemoryoverhead.
- ironmagma 6y agoIf someone can buy this argument but not then immediately understand why a library like jQuery or React is popular, that’s a shame. It’s the exact same reasons: maturity, flexibility, and community/precedent.
- nobleach 6y agoIt's basically a hard no from me on adding a dependency that buys me next to nothing, and bloats my payload to a customers/users mobile device. In that industry, every byte counts. In backend Java/Kotlin apps? I can pay the extra money for memory usage. I cannot ask my users to do the same.
- ironmagma 6y agoBundlers these days are very good. Any code that isn’t used is removed with tree shaking/dead code elimination, and React can be swapped with Preact which has a lot smaller bundle size as well.
- dehrmann 6y agoI'm less interested in what people are running their backend on because that tends not to be where performance issues with sites lie.
- gt565k 6y agoWHAT? That's exactly where performance issues come from. Chances that the client side code is so poor the site doesn't load is very low.
- yashap 6y agoIt’s extremely app-dependent. For example, lots of heavy analytics, data crunching type apps can easily have multi-second (or longer) backend requests. For these, the BE tends to dominate perf issues. However, for your standard CRUD type app, honestly round trips of 100-200 ms for backend requests are really common/standard. On the FE, loading and evaluating big JS bundles, rendering, etc., can be way slower. For CRUD apps I’ve worked on, perf issues on the FE have been more common than on the BE. Especially with the common React/Redux stack, it’s very easy to make perforce mistakes and end up with a lot of unnecessary component updates when things aren’t really changing.
- dehrmann 6y agoI mean that it's not usually the language or the framework, but what overall interactions look like. If static HTML loads slowly, yes, it's the backend, but that's not what most sites look like these days; they're rich, client-side apps making lots of API and resource requests, not to mention overhead something like React adds.
- redis_mlc 6y agoThat's funny. The RoR folks asked the HAProxy developer to add a feature to only direct one request at a time to RoR servers - because it's that inefficient. :) Not to be outdone though, microservice operators have influenced HAProxy to help manage short-lived hosts, sometimes in the subsecond lifetime range.
- jojobas 6y agoThe biggest benefit of jQuery is concealing some levels of complexity that are somewhat hard to grasp. The biggest flaw of jQuery is concealing some levels of complexity that are absolutely vital to grasp.
- halis 6y agoHaving used react and redux for several years now, I'm a bit burnt out on how bloated and silly the entire front end has become. If I could decide for myself, I probably would use raw DOM or jQuery at this point.
- leetrout 6y agoThere really isn’t a good middle ground yet. Look at svelte if you haven’t.
- ratww 6y agoI like Svelte too, but I find Preact with HTM[1] is more of a middle ground. Or Preact + Domz [2] if you're not into the HTM syntax. It doesn't have a compilation phase but it allows us to use Preact, and it's only 5k. [1] https://www.npmjs.com/package/htm https://www.npmjs.com/package/htm [2] https://www.npmjs.com/package/domz https://www.npmjs.com/package/domz
- qudat 6y agoThis might be interesting to you: https://github.com/alpinejs/alpine/ https://github.com/alpinejs/alpine/
- acemarke 6y agoHi, I'm a Redux maintainer. Please note that "modern Redux" code is very different than what most older tutorials show. We've introduced newer APIs like Redux Toolkit, which is a set of utilities that provide a light abstraction to simplify the most common Redux tasks, and the React-Redux hooks API, which is generally easier to use than the traditional `connect` API. I strongly recommend reading through the newly rewritten official tutorials in the Redux docs, which have been specifically designed to show our recommended practices: - "Redux Essentials" tutorial [0]: teaches "how to use Redux, the right way", by building a real-world app using Redux Toolkit - "Redux Fundamentals" tutorial [1]: teaches "how Redux works, from the bottom up", by showing how to write Redux code by hand and why standard usage patterns exist, and how Redux Toolkit simplifies those patterns The older patterns shown in almost all other tutorials on the internet are still valid, but not how we recommend writing Redux code today. You should also check out the Redux "Style Guide" docs page [2], which explains our recommended patterns and best practices, and why they exist. Following those will result in better and more maintainable Redux apps. [0] https://redux.js.org/tutorials/essentials/part-1-overview-concepts https://redux.js.org/tutorials/essentials/part-1-overview-co... [1] https://redux.js.org/tutorials/fundamentals/part-1-overview https://redux.js.org/tutorials/fundamentals/part-1-overview [2] https://redux.js.org/style-guide/style-guide https://redux.js.org/style-guide/style-guide
- jamiesonbecker 6y agoIt's ironic that there's probably no bigger sales pitch for jQuery than this site. In every single example, the jQuery version is basically one or two lines of code, versus 10-15 lines for the alternative. (and the jQ version seems significantly easier on the eyes as well.) Also, jQuery supports promises and has for quite a while. This page hasn't aged well. I've come full circle and am now using jQuery again.
- Zaheer 6y agoI generally agree but I think the site is specifically calling out use of jQuery in libraries to avoid a big dependency. "If you're developing a library on the other hand, please take a moment to consider if you actually need jQuery as a dependency"
- jamiesonbecker 6y agoAgreed! Especially for a smaller library or one that wouldn't adequately take advantage of jQuery shortcuts (or if you're using another library for DOM/shadow DOM, like react/angular/vue/etc) Counterpoint, if you're developing a library, then (based on this page itself), each line that would depend on jQuery would otherwise balloon to 15 times as large, so maybe the highly optimized jQ dependency would be worthwhile if the extra functionality would actually be useful (or perhaps "slim" jQuery). The savings would increase for each additional library that had a shared dependency on jQuery. But, anyway, developer time is valuable, and the 80kb or so for jQuery will probably be blown away as soon as you stick a single image on the page.
- jart 6y agoThis comment is a great example of what I call "lines of code mindset" which is form of tip of the iceberg mentality, where programmers optimize for simplicity only the code they see. Is saving 10-15 lines worth it if you need an 86.1 Kb vendor dependency? Hidden complexity you don't control is the most expensive kind I think.
- jamiesonbecker 6y ago
- cocktailpeanuts 6y agoWhat we need in 2021 is not this site, it's a youmightnotneedreact.com
- jonny383 6y agoAnd of course in 2021 you could build the site using Vue with GraphQL and a CDN deployment pipeline with auto scaling :)
- 6510 6y agoBuild it as a single document in pure html + inline css with 20 mb of text on it and lazy loading images.
- john-doe 6y agoTHIS
- quickthrower2 6y agoKubernetes, docker, nuxtjs, mongo
- jjcm 6y agoI would say that this corollary would only be possible once webcomponents have form support in all browsers. In my opinion this is the last major hurdle before there is a native alternative for reusable components in the browser. Firefox is working on it[1] but there's no current roadmap for the work for Safari (though the initial form element proposal was well received by their team). [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1552313 https://bugzilla.mozilla.org/show_bug.cgi?id=1552313
- deergomoo 6y agoThe Shadow DOM spec always seemed like a good idea poorly implemented to me. As well as the form issue, what made webcomponents untenable for me was that you can't use slots without opting the whole component into CSS encapsulation. Great if you want to distribute components without fear of the consumer's CSS messing with your styles, absolutely useless if you want to extract common patterns in your own app because now you have to duplicate the relevant CSS in every component.
- abiogenesis 6y agoNow only if someone could combine the snippets on the right hand side in an easy-to-use library. Oh wait...
- krapp 6y agono no no... what we need to do is break them down so that each line is a separate library composed of a single function with its own independent dependency tree and test suite, then build another library out of that, all written in a language that compiles to javascript, and publish it to a proprietary package manager. If we're really clever we can probably get it up to several megabytes, require three languages and have it run from an embedded C compiler written in Webassembly. Of course, it will only work in Chrome but really who wants to waste time testing in browsers nobody even uses amirite?
- 6510 6y agoI like the functions (that were suppose to do things) calling functions suffering from the same issue. We're not in kansas anymore.
- quickthrower2 6y agoThen i would only consider it if it has an @types package I can pull
- emptyparadise 6y agoCode golf, except it's maximizing potential security issues.
- dang 6y agoDiscussed at the time: https://news.ycombinator.com/item?id=7152068 https://news.ycombinator.com/item?id=7152068
- deleted 6y ago[deleted]
- human 6y agoI’d be careful about premature optimization. If you can write your code 2x faster by using jQuery, by all means do it. Eventually, if needed, you could rewrite your JS to be free of jQuery, but it would not be a priority for me. Dev speed if more important than load speed for me.
- abiogenesis 6y agoWhat we need is a Jquery-to-VanillaJS transpiler.
- paxys 6y agoUh, what do you think jQuery is written in?
- HatchedLake721 6y agoReact?
- noisem4ker 6y agoThe point is doing the translation on the server.
- abiogenesis 6y agojQuery is written in JS, but if your code is using jQuery functions you are not writing "vanilla JS" anymore. Otherwise we wouldn't need the term "vanilla JS". What I meant was inlining the jQuery calls to their equivalent JS snippets, removing the need for including a 80K library if you are not overly dependent on jQuery. It was also a tongue-in-cheek comment.
- austincheney 6y agoThat’s not premature optimization: https://en.m.wikipedia.org/wiki/Program_optimization#When_to_optimize https://en.m.wikipedia.org/wiki/Program_optimization#When_to... If your code can execute 10x faster without jQuery then the optimization is not premature. If a developer takes twice as long to write any code the problem isn’t optimizations at all.
- ubadair 6y agojQuery is fantastic. I am not a web programmer by trade, but I can always get busy with jQuery and just a couple of Google searches. Last weekend I was trying to find new car dealerships in my region that carried a particular model of car that I'm interested in. They had a dealer search page that could return all dealerships within 250 miles, and they had an inventory search page that had hardcoded the 3 nearest dealership IDs into the URL. But they had no GUI to search all the cars for all the dealers in my region. I poked around at the elements on the dealership search page, cobbled together a jQuery one-liner to dump all the dealership IDs in my region, and pasted those into the URL to finally see every individual car in my region of the model I wanted. The page took quite a while to load, so probably have have some DoS vulnerabilities to deal with, but at least I was happy. Vanilla javascript would have been so much more cumbersome!
- fergie 6y agoHaven't used jQuery in years. This page is encouraging me to give it a whirl again.
- franciscop 6y agoI made Umbrella JS back in the day, a 3kb alternative to jQuery born from the question: You might not need jQuery, then what do you need? https://umbrellajs.com/ https://umbrellajs.com/ It's heavily inspired by "You might not need jquery" as the intro shows! Lots of the methods are just like in these examples, only with looping/multiple nodes. Example: $(el).addClass(className); vs el.classList.add(className); Do not work the same. jQuery (and Umbrella JS) deal with multiple elements and with multiple class names in multiple formats (as a string, as arguments, etc). That's why I find myself still using Umbrella JS from time to time in smaller non-React projects! Just makes everything a lot easier, for 3kb.
- donutdan4114 6y agojQuery 3+ minified is 31Kb.... Wtf is the problem with that? Can we just admit that vanilla JS is not ideal and having some abstraction (and tiny bit of page load) is worth it? I am not building web apps that are primary used in Sudan with 1G connection. 31Kb is practically nothing. THIS image is larger than that! http://content.cdn.viber.com/stickers/144/10400/00010400.png http://content.cdn.viber.com/stickers/144/10400/00010400.png
- austincheney 6y agoJQuery is orders of magnitude slower than vanilla JS. It’s not about download time but execution time. I am not deliberately trying to punish my users.
- motogpjimbo 6y agoDo you use React? In my experience, people arguing against jQuery are usually simultaneously arguing for React as a replacement for it, and are therefore arguing for replacing a ~30kb library with multi-megabyte bundles of catastrophically broken SPA code.
- austincheney 6y agoI do not, but Angular is worse. Last I looked it’s a 300mb download after installing the npm dependencies.
- iaml 6y agoWhy do you think you can only write multi-megabyte apps with react? And why do you think those two are the only options? You can write decently sized react code that's 300-500 kb bundled and if you're not ok with that you can start dynamically loading dependecies. Companies just choose to not spend any time optimizing it.
- austincheney 6y agoThe need for convenience libraries is like parenting with television. It doesn’t seem bad and is just so much easier in every possible way, but any objective observer readily sees the difference in quality of product. The primary reason for that distinction is that you are willing to spend a tiny bit of effort on micro-improvements to quality of product or aren’t, just like parenting. Yes, the effort is ridiculously tiny because it pays for itself with only a trivial amount of practice.
- ant6n 6y agoNot sure whether the comparison is apt. Especially during the lock down, parenting without using Media ... well, it does not involve a „trivial“ amount of practice or a „ridiculously tiny“ amount of effort.
- Mooty 6y agoNo one mentions the fact that jQuery is still used in Wordpress (33% of all websites) everywhere and (as far as I know) in the last theme version they provided this year. Which makes it somehow the biggest library around in terms of usage. I'm still confused why people needs node/react or vue to achieve simple thing that back in the days where pretty easy to do with basic php/jquery. Simplicity in coding was better at the time.
- KptMarchewa 6y agoThe raw count of websites, aka copies of code sitting on some server means nothing, and is bad metric. What matters, is either website view count, or some metric of developer time spend on developing those websites.
- aheckler 6y agoI think the percentage that the GP is referencing is from W3Techs [0]. It's currently 39.7% in fact, and that's only looking at the top 10 million websites [1], so it's not just a simple installation count across all sites ever created. [0] https://w3techs.com/ https://w3techs.com/ [1] https://w3techs.com/technologies https://w3techs.com/technologies
- hathym 6y agoThe first example alone (3 lines vs 18) convinced me that I still need jQuery.
- deleted 6y ago[deleted]
- murtazakhussain 6y agowow, no other proof is needed to user jQuery :)
- porker 6y agoAnd yet, jQuery's AJAX related methods are more convenient than the native fetch() API. And AFAIK not matched by any simple wrapper for the newer APIs (it's fashionable to go to heavier ones like axios). I still grab jQuery into projects for the sheer convenience.
- bisRepetita 6y agoOne thing I need jQuery for: tracking progress on file upload. Fetch does not do it.
- fabiospampinato 6y agoI'd suggest to anybody wanting a thin wrapper over the DOM to just go with Cash [1] instead, which I maintain. Cash is largely a drop-in replacement for jQuery Slim at a significantly smaller size (~6kb vs ~24kb min+gzip). The methods listed in youmightnotneedjquery.com are a little simplistic/buggy at times and not tested, if you just need a single method from jQuery it would probably be a better idea to simply copy/paste it from Cash. [1]: https://github.com/fabiospampinato/cash https://github.com/fabiospampinato/cash
- DangerousPie 6y agoI bought into this a few years ago and ended up regretting it. My code has become much harder to maintain and read due to all the extra boilerplate code, and it probably has hidden bugs and compatibility issues that I'm not even aware of. And for some things I still ended up requiring jQuery, because they just weren't feasible to do in vanilla JS. I have actually gone back to making heavier use of jQuery again these days.
- kebman 6y agoI guess the irony is that jQuery is indeed written in JavaScript, so whatever you set out to do is still "feasible to do in vanilla JS." With that said the main difference is of course that there's far more people involved in maintaining jQuery than there is on most people's individual codebases. Personally I try to make do without it, if nothing else than because it forces me to learn JavaScript better.
- DangerousPie 6y agoOf course - what I was trying to say there was that it was not feasible without writing hundreds of lines of extra code, with all the development and maintenance cost that brings. In some use cases that trade-off may make sense, but in mine it doesn't.
- nate 6y agoI miss jQuery. It's funny that an argument against jQuery is "oh, but you have to load that big thing to access your site", but then we'll create Single Page Apps that then proceed to spend loading json for 10 seconds before we start interacting with them. :)
- schwartzworld 6y agoThe techniques listed in that website aren't really used for single-page apps. They're listing APIs that you used to need jQuery for that are now natively supported by the browser. This is for people still doing the jQuery style of development.
- thecrumb 6y ago2021 ... still using jquery
- m1kal 6y agoIt's funny this site doesn't mention dialog - the only feature I'm using that is hard to replace by vanilla JS... jQuery speeds up development, but in most situations it's straightforward to replace. On the other hand, I never remove React (and especially Reagent) from an existing site - too much effort, too much to break.
- tyingq 6y agoThat's jQueryUI rather than the base jQuery.
- thrownaway561 6y agoAll that sites does is make me glad I still use jQuery. If something is working and saves me time, I don't see the reason for me to have to replace it simply cause it is the next hot thing. jQuery has it's place in the world.