30 ms·
I loved jQuery, and still do (2019)
- BlameKaneda 5y agojQuery is still my bread and butter for DOM manipulation and events. I've found it to be much more readable than vanilla JS.
- thehappypm 5y agoI just use vanilla JS now, but it took a while to get there.
- deleted 5y ago[deleted]
- onion2k 5y agoThat's 30KB over the network and 90KB of JS code in memory so that you don't need to learn about 5 standardized browser API methods that are the same in every browser going back to IE9 then. No doubt that gives you a better developer experience but I don't think your users are thanking you.
- dageshi 5y agoThe internets users managed to live with this terrible 30k burden in the late 2000's when it was the only choice. I think probably in 2021 when 30kb is a rounding error on page sizes they can also probably manage it.
- ducharmdev 5y agoThis feels like a false equivalence; how many of those 2000s users were browsing the web on mobile compared to today?
- dageshi 5y agoDoes 30kb of js really matter on modern phones and modern mobile internet?
- recursive 5y agoIf "modern" means fast, then no. If "modern" means what people are using in 2021, then possibly.
- AnIdiotOnTheNet 5y agoThis kind of thinking is why software continues to get slower and slower despite incredible advances in hardware.
- ducharmdev 5y agoBingo. 30kb doesn't seem like much, but its easy to think it doesn't matter when viewing one dependency in isolation. But if you say "it's just x kb" to all dependencies, then you have a problem when they're all aggregated. This is why I appreciate Svelte's take: with a compiler-heavy approach, you can have a great dev experience without saddling your users with extra dependencies.
- jhgb 5y agoSince many people seem to be religious today about which "packer" is the best and that using one in the first place is a necessity, the answer is apparently "yes".
- liquidise 5y agoI don’t follow. Is the implication here that users can identify an experience difference cause by a 30KB over-the-wire asset, or more, a 90KB in memory one? I know I certainly wouldn’t claim to have that ability myself even on low quality networks.
- onion2k 5y agoIf you're a user on a spotty mobile connection in a rural location on a low-end device ... both.
- gpvos 5y agoIn that case, most of the web is unusable nowadays, and jQuery is not your main problem. Maybe your argument is valid in less-developed countries where more people have spotty connections and more websites have adapted to that (but I wouldn't know, sorry).
- basilgohar 5y agoI'm not happy about it, but the reality is that 120kB is small potatoes in the modern web world. Would it be better without, sure? But there are bigger fish to fry. If jQuery helps the developer achieve their design and development goals, that will play out better for the end-user. It's not ideal, but it's realistic.
- onion2k 5y agoIf jQuery helps the developer achieve their design and development goals, that will play out better for the end-user. That's not the dilemma though. Developer can build solutions without jQuery. They'll be faster, smaller, and have fewer dependencies. Plus, if you're only using jQuery for DOM and events then it probably isn't helping you. Those are two areas where writing vanilla JS is can often be easier than writing the jQuery code to do the same job.
- handrous 5y agojQuery versus vanilla DOM is slower, larger, and adds dependencies. jQuery versus [framework of the month] is "faster, smaller, and [has] fewer dependencies". Simpler build, too, while still keeping you from having to worry about which browser supports what. Depends on what the most likely alternative is, then.
- onion2k 5y agoThere are plenty of modern frameworks that are smaller than jQuery (svelte, Preact, etc). In some apps they may also be faster. If you pick svelte there's the same number of dependencies.
- legitster 5y ago30kb is pretty trivial. And even so, if you are using a CDN like you should the jQuery is likely already cached on the user device.
- saturn_vk 5y agoI recall an earlier discussion on here stating that using CDN nowadays doesn't have any gains, only drawbacks.
- onion2k 5y agoThis is correct. It's called cache partioning. https://developers.google.com/web/updates/2020/10/http-cache-partitioning https://developers.google.com/web/updates/2020/10/http-cache...
- dspillett 5y ago> That's 30KB over the network and 90KB of JS code in memory A fair point, but compared to the payload of most sites (let alone apps) these days that is chicken feed. Just opened that page itself and DevTools tells me 5.2Mb was transferred including ~175KB of JS from twitter, 65Kb JS for the video player (which seems to have 46Kb worth of css associated with it!), ~1Mb worth of font resource, ... > so that you don't need to learn about 5 standardized browser API methods That and the way jQuery does method chaining, which a lot of people find far more convenient, but other features. jQuery does a lot more than querySelector/querySelectorAll/friends. > No doubt that gives you a better developer experience* <attenborough>And here we see a forum commenter in its natural habitat, hunting the point. It sidles up slowly, and pounces...</attenborough> (with apologies for failing to resist being facetious and slightly dickish there) >* but I don't think your users are thanking you.* I don't think most users will notice. Those that do due to slow connections, metered connections, low-power/low-memory devices, etc, are going to baulk at much more before even noticing jQuery on this site. On something like HN (23.8K transferred for this page before my comment was added) 30Kb might look chunky, but few sites are remotely close to being as lean as HN.
- onion2k 5y ago(with apologies for failing to resist being facetious and slightly dickish there) No apology necessary. That was funny. Because it's true. :)
- thrower123 5y agoWho cares when you're slurping down 40 megapixel PNGs for images that are sized with CSS to 100px x 100px?
- lobstrosity420 5y agoCan you elaborate on what JQuery does for you that you can't do with modern JS features such as fetch and query selectors?
- mschuetz 5y agoThis page gives a pretty good overview of why jQuery is still relevant: http://youmightnotneedjquery.com/ http://youmightnotneedjquery.com/ Requests have gotten better with "fetch", but unfortunately, the "modern" DOM API is quite bad in some parts, making lots of stuff unnecessarily verbose. On top of that, it's really odd that the DOM API is not compatible with for-of loops, which could have been a selling point.
- lobstrosity420 5y ago>it's really odd that the DOM API is not compatible with for-of loops, which could have been a selling point. I'm not sure what you mean by that? querySelectorAll returns an iterable. Also, your link is outdated. It doesn't include the fetch API which has enjoyed wide support for quite a while now.
- mschuetz 5y ago> I'm not sure what you mean by that? querySelectorAll returns an iterable. Apparently my knowledge is outdated. Last time I tried to switch from jQuery to vanilla JS, the results of document.getElementsByTagName and others were not iterable with for-of.
- legitster 5y agoFor me, the code is easily 10x more readable than vanilla JS. And much shorter, so I can hand code everything quicker without typos.
- BlameKaneda 5y agoTo use an example, I'd much rather do $(".elements").css("color", "red") versus var selector = document.getElementsByClassName('elements'); selector.style.color = 'red';
- thoughtpalette 5y agojQuery will always have a soft spot in my heart. I came from a design background and the naming conventions and "utility" functions for common events and selectors made it so simple to understand.
- mkl95 5y agoI'm not the biggest fan of jQuery because I have had to deal with massive tech debt created by other engineers over the years (and I'm not a frontend dev). However the Ajax API is a genuinely good tool.
- dehrmann 5y agoThe jQuery API is really good. It's still better than the DOM API, it's just that now, your framework might give you some of what it does, and the DOM API is almost good enough (and free). You're right about how it was historically misused, thought that has less to do with jQuery than a lack of good client-side frameworks, design patterns, and how rich frontend experiences used to start as just a few callbacks.
- ChrisArchitect 5y agoThey loved it still in 2019. How about since then?
- gpvos 5y agoProbably still. I don't think that that much has changed in the last two years.
- ItalyPaleAle 5y agoI'm the author of the post. I was not expecting this to surface out of the blue 2 years later, so I had to go back and re-read what I wrote I still stand behind what I wrote for the most part. If what you are looking for is not building a full SPA and you need compatibility with most browsers, for most users, then jQuery is still a very solid alternative. A few things have changed however since then: - As others have pointed out in the comments, a larger chunk of the Web has moved to SPAs, sometimes just because they wanted to build on the back-end something API-driven that can be reused for other scenarios (like mobile apps). The amount of apps that follow the more "traditional" model of server-side generation and then use JavaScript just to "augment" that experience is much smaller, but there's still a lot of use for them if you want to build something quick-and-dirty, like an internal app for your business. - Browsers are now implementing [cache partitioning](https://developers.google.com/web/updates/2020/10/http-cache-partitioning https://developers.google.com/web/updates/2020/10/http-cache...) which means that jQuery must now be re-downloaded by every website. It's still a rather small library, and compared with most modern apps the impact is negligible (average web page size is now [1900-2100KB](https://httparchive.org/reports/state-of-the-web#bytesTotal https://httparchive.org/reports/state-of-the-web#bytesTotal)). But this has negated one of the benefits of jQuery, the ability to serve it from a CDN that then is reused by other websites. For a SPA, I would go 100% with Svelte as my first choice (but you may say I'm biased), but other frameworks are good too especially if you need to leverage existing skills on your team.
- ChrisArchitect 5y agoRight, not expecting this to surface out of the blue 2 years later, OP. Thanks for the addition insights anyways
- franze 5y agoI created box2d jQuery https://github.com/franzenzenhofer/box2d-jquery https://github.com/franzenzenhofer/box2d-jquery (Demo Pages sadly down) a physics engine for the DOM. I really learned to appreciate jquerys clean codebase at that time. Learned a lot about the DOM and how to misuse it.
- spicybright 5y agoThat sounds interesting! Too bad it's down...
- whalesalad 5y agoI am deploying Vue ui's now without webpack or any kind of bundler – jQuery and I have been through hell and back but I do wouldn't say I love it.
- drummer 5y agoJQuery is a tour de force of API design. Still use it in all my web projects.
- deleted 5y ago[deleted]
- legitster 5y agoI love jQuery. I can just drop in the library onto any existing webpage, and have almost complete control of the DOM with just a few lines of code. And the built in actions and animations are all so simple and perfect for the web. And the structure and naming is so good that I rarely need to look up any references anymore. I get that browser support isn't as important as it used to be, but it is nice to know that you can just use an effect in jQuery and it will just work exactly as you expect it.
- dr-detroit 5y agonote that jquery is already cached in browsers and infinitely more performant than some random low IQ web developers js bundle of the day
- klysm 5y agoI don’t know how universally true this is, but I find that the easier it is to write the first time, the harder it is to maintain. For example, it’s really easy to write a python script but it’s harder to change. It’s harder to use types on a program the first time but it’s easier to change. I think that’s the core of the issue here with peoples negative feelings about jQuery. Sure it’s super easy to make the page do the thing but it’s a long term mess almost always - especially compared to something with more built in structure.
- legitster 5y agoI'm not sure if that's true. I find jQuery much easier to maintain than vanilla or even some modern JS libraries. > $("#button").on('click', function(){ > $(".modal").slideUp(); > }); Obviously a simple example, but this is really easy to understand - even for a non-programmer! The equivalent vanilla JS to do this is honestly pretty nasty in comparison. The only problems I have seen when maintaining jQuery is when someone wants to drop in a bunch of custom functions they have designed in vanilla JS - or try to treat it as a replacement for a front-end framework. But for it's intended purpose of adding interactivity into HTML content, I think it is still the king.
- VWWHFSfQ 5y agoDjango templates + Bootstrap + jQuery is all I've ever needed to make great, modern websites. Server-side rendering with some nice layouts and interactivity on the frontend. I've tried some of the SPA frameworks and I've always felt like my productivity tanked.
- notoriousarun 5y agoDo you develop REST API also....? The fundamental issue is that it binds the server to the client, who must understand HTML structure. It also makes it more difficult to reuse the endpoints in different ways or for new applications. Returning data and letting the client render it decreases coupling and increases flexibility/testability- you can run unit tests on the client for mock data, and run unit tests on the server to test the desire
- rubyist5eva 5y agoI don't use Django but I use Ruby on Rails, and turning a server-side rendered page into an API is trivial. Rails requests automatically understand the format of a request and let you specify what do when a specific kind of format comes in: ie. when it's an html request, render this page, when it's a "js" request, render a jbuilder template. ezpz whatever frontend framework you're using has really nothing to do with it at all.
- 1337shadow 5y agoConfirmed this is also trivial with Django, have done it to my crud, and even have a view that parses my url router for views and return an openapi definition with a swagger ui.
- notoriousarun 5y agoDo you use Django REST Framework with Web Swagger Console UI?
- 5y ago
- deleted 5y ago[deleted]
- developeron29 5y agoYes Jquery does makes things easier than vanilla JS Best being $("#id") replacing document.getElementById("id"); Makes code look cleaner
- cptrp2101 5y agohttps://developer.mozilla.org/en-US/docs/Web/API/Document/querySelector https://developer.mozilla.org/en-US/docs/Web/API/Document/qu... Does the same as the $ query but native in every browser in IE9+ and gives you a native node. Also more performant than getElementBy<whatever> methods.
- Turing_Machine 5y agodocument.querySelector(selector) is more typing and more visual clutter on the editor screen. jQuery is elegant, concise, and was designed by a genius. The "modern" methods are ugly, verbose, and were designed by a committee.
- rement 5y agoYou can define your own `$` function. This way you can have the clean code without the entire jQuery library function $(arg) { if (arg.charAt(0) == "#") { // HTML spec does not support ids to start with numbers [0] // (you may not need this conditional on your website) return document.getElementById(arg.slice(1)) } return document.querySelector(arg) } Using this function you can select your comment with $('#27677234') jQuery does add many extra features but if clean code is the only thing you are after there are other options. [0] https://www.w3.org/TR/html4/types.html#type-id https://www.w3.org/TR/html4/types.html#type-id
- rement 5y agoThe HN js actually does just this. The file isn't very long but has some great functions at the top https://news.ycombinator.com/hn.js https://news.ycombinator.com/hn.js
- 5y ago
- cmer 5y agojQuery used to be (necessarily) bloated because it needed to support so many poorly-behaving browsers. Now that these browsers are no longer relevant and support has been removed from jQuery, what is the performance hit, if any for using jQuery as opposed to vanilla JS? I agree with many, I find the jQuery syntax to often be better than the alternative.
- rchaud 5y agoJquery minified is 83KB. That's about the size of a compressed 300x300 px JPG.
- cptrp2101 5y agoI had a big post but deleted it all. I can more concisely say this: The people here saying they still use it have so far demonstrated what I always say. If you're using jQuery, it's time to go back and relearn javascript. Most people should REALLY research the querySelector and querySelectorAll DOM methods. I've always felt that jQuery encourages you to let your skills stagnate and you don't learn what your code is actually doing. Learn what the current spec has to offer. You don't need another dep just to target dom nodes ffs.
- zackify 5y agoi couldn't agree more!
- racl101 5y agoFor new projects I agree. Go jQuery-less. But for existing projects that still work well and for which there is no reason or gain from updating the code and, for which, time and money would be spent for what is really a lateral move, I think it's fine to leave it as is. And there are many projects like this where the JavaScript barely changes, jQuery is holding it in place and nicely and there's hardly any technical debt. There's no incentive to spend the money and time. Making a developer feel better is not really worth it in these situations unless they'd like to work for free.
- cptrp2101 5y agoI agree. No need to go into something that exists and do a big refactor to pull it out. I'm advocating for not adding it to things you start now.
- audessuscest 5y agoI disagree, jQuery is still nice for some complicate dom manipulations and still simplify it a lot. Of course I'm not saying you can't do that without it, but saying if you use jQuery you doesn't know JS doesn't make sense.
- sam0x17 5y agoHave fun when your page randomly gets visited by IE7 running behind some ancient corporate firewall.
- ricardo81 5y agoI've depended on jQuery, not a strictly front end designer myself but have done a bit of client side dev the past 20 years. If I had a choice, I'd go with one of the reactive libraries, I've used Vue. For me, if you're relying on Javascript IMO it gets the job done quicker. It'd be interesting to see what jquery is used for in aggregation of all its usage. For me it was always selecting element(s) and XHR requests. With fetch (and a polyfill for IE), and the likes of querySelector it seems that a lot of the problems jquery solved have also been solved by the majority of popular browsers. I say that as a layman of client side dev, happy to be corrected.
- cptrp2101 5y agoYou're bang on here. Why import an entire library when once polyfill and native features will serve you nicely.
- dylan604 5y agoI've never been a UI dev, but have frequently been forced to put a UI as a PoC that becomes production UI. ugh. I had always turned to JQuery just for the browser compatibility aspect. I got out of the game for a few years and have recently gotten back on the that horse. I turned to JQuery as that's what I knew. Now that supporting IE is no longer a thing, and since modern JS essentially includes the missing pieces JQuery filled. I am slowly converting to plain JS in aims of removing JQuery. I am awaiting my fetches with async functions in place of $.ajax with MDN pages in the next tab. Don't see how replacing one library of JQuery with another library like Vue/React/etc is any better. A crutch is a crutch by any other name.
- ricardo81 5y ago>replacing They're not so comparable TBH, the reactive element is the key difference. I can simply create logic, apply changes to the input data and the UI is updated. With jQuery you have to update the UI and data, far less easy. Point I was making is that if you're site relies on JS, I'd pick a reactive framework to do the heavy lifting.
- racl101 5y agoWill never understand the snobbery against jQuery. It was a great library for what it did and it holds up a lot of sites still.
- acabal 5y agoI still use jQuery even for new projects. Yes, these days it's possible to do everything jQuery does using native JS, but I find the native version to be much more verbose and its naming conventions to be far less clear. For example, natively getting a list of children is `el.children` but natively getting the parent is `el.parentNode`, not `el.parent`. Meanwhile, natively getting a list of classes is `el.classList`, but when I'm getting children I also get a list, so why not `el.childList` instead of `el.children`? Natively cloning a node is `el.cloneNode(true)`, so now I have to remember what `true` is for and whether I want it or not (surprise: the default changed between JS versions, so the "optional" argument must always be included for compatibility!). Probably the most commonly used line in web JS in jQuery is the terse `$('selector')` but natively is the mouthful of `document.querySelectorAll('selector')`. So while jQuery isn't strictly necessary, it's certainly a nice syntactic sugar, and IMHO a more sane and consistently-designed API than native. It's a great choice for developers who want avoid big frameworks like Vue and get as close to plain HTML/JS as possible, but still want a pleasant JS development experience.
- Aperocky 5y agoI've used jQuery in the past, but switched to native js/ts. I found that while jQuery offers some nice synthetic sugar, it's mostly geared towards web frontend and actual logic continue to have to reside in native. I'd rather just know one thing (but I'm a backend programmer that only does js/ts for fun, so there's that).
- chrismorgan 5y ago> For example, natively getting a list of children is `el.children` but natively getting the parent is `el.parentNode`, not `el.parent`. Actually, .children is the child elements; .childNodes is all the children (including comments and text as well as elements). > Meanwhile, natively getting a list of classes is `el.classList`, but when I'm getting children I also get a list, so why not `el.childList` instead of `el.children`? I’m not sure why they want with .classList instead of .classes, but I expect .className is a part of the history. If redesigning it from scratch and still retaining the functionality of .children, I’d rename it .childElements. Certainly not .childList. And of course, the reasons for most of this stuff is the history. Some of the web’s APIs have aged well; others haven’t.
- thera2 5y agoSome people talk big about dropping jQuery and saving one request, yet they have a shipload of bloat elsewhere. Not using jQuery in and of itself is not an optimization of any kind. I use jQuery and my page has a perfect score in GTmetrix. If the goal is optimization, you have to consider the total package. Addititionally, jQuery loads on the first request and sits in local cache thereafter. And it could already be in local cache if you use a CDN.
- mechanicum 5y agoIt won’t be cached already. Safari, Chrome and Firefox all have partitioned cache now.
- AlexAndScripts 5y agoYet another example of abusive tracking destroying the web.
- mortenjorck 5y agoI finally learned some React a couple of months ago on the premise that as a designer, I needed a better understanding of the frameworks used by the developers I work with. I know React enforces some better practices that my spaghetti-jQuery of yore never followed, and that I was getting a crash course in those practices at the same time, but I was nonetheless surprised at just how slow I felt working in it! It gave me a new appreciation of just how accessible jQuery is, and how intuitive its concepts are to someone without a background in software development, perhaps for better or worse. Obviously this is a bit of an apples-to-oranges comparison, given the intended uses of the two frameworks, but for simple projects, it's hard to imagine a better balance of accessibility and flexibility than jQuery.
- bdcravens 5y agoSounds like you're working on jQuery-sized apps, not React-sized. The problem is that many don't know the difference, and everything is React-sized, even apps that have no business being anything but server-rendered.
- lordgroff 5y agoYep... I mean, part of that is a problem of "SPA everything" cargo cult; basic web page? SPA everything! Content management? SPA everything! I manage my wife's electronic store that's based on WordPress, and I see absolutely no reason for ever changing it. I've written a bunch of custom scripts, all in PHP back-end and jquery front-end, and... It just works. And it's fast. And complexity is totally manageable. But, I've also written a few SPAs for her business deployed as PWAs, and I can't even begin to think about how it would look like if I was using jquery for these tasks. React (or Vue or whatever) is an escape hatch from going insane in such situations.
- bdcravens 5y agoThe software I manage is a very complex asynchronous workflow engine sometimes spanning across hundreds of containers. It's our bread and butter. Our marketing site is in Wordpress.
- warpech 5y agoI definitely agree with jQuery's legacy. We owe many parts of modern DOM and JavaScript to jQuery and Prototype.js (may I say that Prototype.js was to JavaScript what jQuery was to DOM). There is probably no reason today to use Prototype.js, however, jQuery still is a better choice than React/Angular/Vue for small projects if the author prefers some syntactic sugar over plain DOM.
- vlunkr 5y agoDo people still hate jQuery? I feel like the consensus is that that jQuery was a great tool for the time, but is not so critical today. Yeah, we've all seen spaghetti code monstrosities that involve lots of jQuery, but it's just a library, it can't be blamed for people not knowing how to structure their code.
- rchaud 5y agoEvery time anything about jQuery is posted, someone will inevitably post the "You might not need jQuery" site. [0] I look at that site and laugh. Is this supposed to be making the case ~against~ jQuery? Maybe the audience for that site are seasoned developers for whom the vanilla JS syntax is easily understood. Everybody else is going to look at those code snippets and think jQ is the way to go. For people that have struggled through HTML and CSS, there is perhaps nothing more deflating than to realize that even basic UI interactivity requires JS. But with jQuery the code snippets needed are short and understandable. Vanilla JS in comparison looks like an entirely different language. [0] http://youmightnotneedjquery.com/ http://youmightnotneedjquery.com/
- ThePadawan 5y agoI agree that the vanilla JS snippets seem hilariously more complicated, but simplicity isn't everything. In a corporate environment, if "I need to include jQuery as a dependency" involves asking another team how to set up custom deployment or whatever, and that is the difference of days between deploying a feature or not, then I'll definitely take the hit of 10 more SLoC vanilla JS.
- rchaud 5y agoIf it's a corporate environment, the standards are different, understandably. But the hostility to jQuery is also primarily concentrated among corporate devs that seemingly cannot imagine that jQuery might be valuable for use cases other than their own. Not every site out there is an database-driven SPA that needs QA review and a deployment pipeline each time an update is made. Lots of sites are just simple WordPress or even raw HTML pages that need a little bit of a facelift, with animations or transition. jQuery does the trick, and as a bonus, it's a much gateway drug to JS than the official ES6 documentation could ever be.
- FinalBriefing 5y ago> little bit of a facelift Proceeds to download 30kb (compressed) swiss army knife of a library when just a toothpick would do. jQuery is about as much of a gateway to ES6 as pot is to heroin. Devs who still use jQuery have had 10+ years to learn `document/element.querySelectorAll()`. Longer for event listeners.
- bstar77 5y agoI agree with the author that jQuery was essential for the time. Abstracting away browser compatibility issues in the era of IE6 was a wonderful thing, for sure. The problem is jQuery has no business being used today unless you have to maintain legacy code. Even then I would deprecate jQuery wherever possible. Using jQuery for a "quick and dirty" application today is just terrible and it sends the message to green devs that jQuery code slinging is a skill worth having. If you like quick and dirty, just make sure you have a working Node.js environment and generate a simple project that supports Webpack or Parcel. You will get all the advantages of Babel and Polyfills (if you need them) with little to no effort. jQuery has no value except for maintaining legacy code. jQuery was useful back in the day (and John Resig had the best solution), but I don't love it anymore. In fact, I have serious judgements of the devs that use it that should know better. Edit: I should note that jQuery is bad because it has no state management and you cannot easily track side-effects. I would much rather see someone use something like Svelte and construct the functionality with modern best practices while keeping a very small footprint.
- bluedevil2k 5y ago> If you like quick and dirty, just make sure you have a working Node.js environment and generate a simple project that supports Webpack or Parcel There’s nothing quick or easy about these steps. Linking to a jQuery CDN and getting working code immediately is easy.
- bstar77 5y agoI respectfully disagree. If you take 15 min to understand the basics it becomes trivially easy and the productivity you gain going forward is massive.
- sc68cal 5y agoIt's not going to take 15 minutes to understand WebPack and Parcel. Let's be a little more realistic. Sometimes you don't have the luxury of time and tools that you already know are going to get used, instead of new tools you don't.
- neals 5y agoJQuery and backboneJS were all I needed up until very recently. Now it's modules all the way down, alien syntax and overengineering.
- nailer 5y ago> Although, at the time we weren’t really using the word “SPA”, and so we’d refer to that category of apps with terms like Rich Internet Application (RIA) or “Web 2.0 app”. 'Rich Internet Applications' were not the same thing as web 2.0 sites. Rather, they were a precursor to modern concepts like Electron and webview2.
- mbostleman 5y ago> Then GMail came in 2004 OWA and Ajax appeared 6 years earlier. Why would Gmail be considered the milestone instead?
- LukeBMM 5y agoWhile the tools were available earlier, I think it's fair to say that GMail was most folks' first experience with a functional (while the content of the emails was still present, the point of GMail was reading and managing emails, rather than displaying their content) web app, rather than an informational one. It seems a valid milestone, if not the first example.
- byteface 5y agoI guess it's easier to remember $ than queryselectorall . I recently realised most of its methods are now natively supported. I think people who don't use js a lot may not realise that.
- afiori 5y agoin many ways jQuery has a lot of developer friendly niceties, in a different timeline jQuery became the new standardized DOM API and everyone would be happy
- tossaway9000 5y agoIn 2012 or so we doubled down on jQuery UI, specifically the widget factory and a few dozen custom widgets extended from a custom parent widget. That application is STILL in production today, chugging along in both the private and public sectors.
- evo_9 5y agoAny suggestions on a jquery-like easy to implement calendar control? That’s the one thing jquery still does better than everything else, at least that I know of.
- 1337shadow 5y agoHonestly I rely on input type=date nowadays
- shmiga 5y agoIt's like with smoking. Sure, you're writing jQ for decade it's hard to quit. I strated coding relatively late and I have no fucking idea why do you ever need jQuery.
- earthboundkid 5y agoThis was a dumb opinion when it was posted the first time. There is no reason to repost it, but the joy of dunking on something dumb. Good repost.
- thrower123 5y agoI still think they should have just shipped jQuery or lowdash with browsers as a defacto JS standard library.
- locallost 5y agoIt's really a great piece of engineering -- it a technical building block that is very well designed and solves a great number of problems. Some of the things that came later put development on a new level, but this doesn't take anything away from jQuery for the time it was made. Resig's book is in a large part "how jQuery was made" and it was a great read. Also some of the built in APIs that mimicked it like querySelector are not as elegant as jQuery, even though it was a solved problem at that point.
- princevegeta89 5y agojQuery is great, especially when you are low on time available and wanted to put together your product with minimal friction. VueJS, React etc. are great, but not when you have no more than 2 developers working. We are in the age of 5G internet and high bandwidth network streams, downloading a couple of hundred extra kilobytes of js files on mobile clients and desktop browsers should be no problem to at least 85% of the users. Oh and BTW it pairs really well with StimulusJS. I've used it thoroughly and it's been a godsend
- mouzogu 5y agoNO, you can't use jQuery!! It's against the law!!! (proceeds to build non-interactive static page with create-react-app) I find jQuery and Bootstrap great for fast prototyping. The thing I love about jQuery is the cross-browser compatibility. I know things have improved but I have very little faith in native JS "just working" as I would expect on all browsers. But of course it was not designed for building reactive apps and so should not be used for that. It's nice just for fast-and-dirty UI interactions and animations.
- olliej 5y agoI recall people arguing that browsers should have jquery built in, because "it's clearly never going away"