[HN Gopher] jQuery 3.6.0
___________________________________________________________________
jQuery 3.6.0
Author : mkurz
Score : 227 points
Date : 2021-03-02 18:51 UTC (4 hours ago)
(HTM) web link (blog.jquery.com)
(TXT) w3m dump (blog.jquery.com)
| jariel wrote:
| For those wondering, JQuery is still used on the majority of web
| sites in the world apparently [1]
|
| I'm not sure how the data is run, but it's quite massive share
| however you cut it.
|
| JQuery is still in it's foundational phase, it's still a 'core'
| thing, it's not remotely legacy yet.
|
| [1] https://almanac.httparchive.org/en/2019/javascript
| llimos wrote:
| A lot of them are probably due to Bootstrap (<5.0) bundling it.
| cronix wrote:
| And WordPress, even current versions.
| [deleted]
| superfamicom wrote:
| jQuery is also an amazing educational tool for teaching people to
| program in steps, learning the native DOM methods and then being
| introduced to jQuery has been really fun to see light bulbs going
| off for new students.
| elwell wrote:
| Those API docs are so nostalgic.
| singhrac wrote:
| I love the fact that they haven't changed styles in a decade.
| It really does bring me back to high school.
| didip wrote:
| I super love jQuery. The proliferation of SPA is super
| unfortunate, maybe one day the pendulum will swing back to server
| side HTML with lighter JS for progressive enhancements.
| j-krieger wrote:
| React is trying that with server rendered components
| newsbinator wrote:
| > We still have our eyes on a jQuery 4.0 release, but until then
| we will continue to support the 3.x branch and address important
| issues.
| pier25 wrote:
| This caught my eye too. What could they be cooking?
| TimTheTinker wrote:
| My guess is a slimmed-down API with most or all support for
| older browsers removed, perhaps something similar to Zepto.
|
| There is _still_ something to be said for the usability of
| jQuery 's API for direct DOM manipulation, as opposed to the
| more verbose API offered by the DOM itself.
| pier25 wrote:
| I love modern reactive frameworks, but for DOM manipulation
| the jQuery-style API is great.
|
| Some problems are much easier to solve working directly
| with the DOM (eg: drag and drop). The problem is that you
| either have control over the DOM, or let someone else do it
| (React, Vue, etc).
| henryfjordan wrote:
| There seems to be milestones for 4.0 setup on Github:
| https://github.com/jquery/jquery/milestone/7
| hising wrote:
| jQuery solved (and solves) a lot of browser inconsistencies
| (fewer now than before) and I guess a lot of older codebases
| still rely on it, so I am glad to see it is still moving forward.
| However, jQuery has a built in problem in modern web development,
| as the DOM-functions that now makes it obsolete, as in it does
| not solve the more complex problem of state management and
| scoping of components. For some sprinkling on top of server side
| rendered web pages I guess it still has some value if you need to
| cater for older web browsers, but for those who build
| applications that handles state and components for the current
| setup of browsers it is not needed in your toolbox any more when
| bootstrapping new projects. However, it helped us getting to a
| point where we could rely on solid libraries and focus on
| building better user experiences. I am glad it still gets updated
| but will probably not write "jQuery-code" anymore in my
| professional life.
| synergy20 wrote:
| Frontend has been a pain in the ass for me for quite a while as
| someone trying to learn frontend development.
|
| jQuery's concise syntax beats everyone, I hope Javascript can
| adapt it someday, truly a KISS design gem. However I do need
| write code to do data-binding myself, which is important for
| interactivity.
|
| Vuejs can be used to replace jQuery however it does not have the
| simple syntax, you do get data-binding for free without using its
| full-blown SPA framework. However you do need master a lot more
| concepts comparing to jQuery.
|
| React/Angular are both overkill for 90% use cases, unless you're
| doing a serious SPA that is.
|
| For me it's between jQuery and Vuejs these days, I learn both,
| one reason I worry about jQuery is that it's losing some steam
| and the development is not very active. Still I'm excited about
| this new release.
| alexk307 wrote:
| I still believe that jQuery is the best tool for the job if
| you're creating a small web application and don't want to learn
| an entire new framework.
| distrill wrote:
| I know jquery is still in use a lot all over the web, but are
| people still starting new projects with it?
| greenie_beans wrote:
| I've had to learn it at a new job after starting my career
| making UIs with React. It's not so bad.
| [deleted]
| garymoon wrote:
| I think it is still widely adopted in CMSs like Drupal and
| Wordpress and they have a big market share. Jquery will not die
| soon even if it is not the first choice for starting a new
| project. It's been years since the last time I used it.
| noisem4ker wrote:
| Yes. It's fine for progressive enhancement of server-side-
| rendered webpages.
| ativzzz wrote:
| Absolutely. Starting most new projects with something like
| React/Vue is complete overkill and jquery makes adding small
| incremental JS functionality to your app a breeze.
| cphoover wrote:
| Do people still use jQuery?
|
| I thought the biggest advantage of this library back in the day
| was css selector access of DOM nodes (back when we only had
| getElementById, getElementsByClassName, and
| getElementsByTagName). This has been rolled into the Javascript
| document api via document.querySelector, and
| document.querySelectorAll.
|
| Also there are browser compatibility issues that jQuery solved
| but a lot of these are solved with smaller footprint libraries
| like lodash.
|
| Also for me, along with I'm sure many others, keeping state
| within the DOM has fallen out of favor of more comprehensible
| state management inside of JS (like React Hooks, Redux...etc.)
|
| What is the current use-case for jQuery? I'm curious from hearing
| it's current users answer this.
| aakkaarr wrote:
| It is still bundled in WordPress and WP is still most popular
| CMS (30% sites on the web runs on it)
|
| It is not necessary to use jQuery when you build site but tons
| of tutorials on the web is using it so people does.
|
| Plus wp-admin still loads jQuery for itself so it is in use
| even unnoticed.
| handzhiev wrote:
| jQuery is bundled in WordPress and many of the plugins so I
| guess there are a few sites still using it :)
| abhisuri97 wrote:
| Yep. I still use it for side one-off projects here and there.
| For me, there's just something so convenient about being able
| to make a html page that you can drop in a quick CDN link for
| jquery and not have to worry about compiling, webpack, create-
| react-app etc. I'll still use React when something is a larger
| project with a ton of moving parts, but otherwise I stick with
| jquery.
|
| As for why I'm not using the native DOM api's...I could, but
| haven't gotten around to learning that syntax since I'm very
| used to jquery (being specific, if I want to do things that are
| more complicated than selecting an element + changing its
| properties, the native API is more complicated). jquery is just
| a nice default.
| megous wrote:
| It's not that more complicated. There are
| after()/before()/closest()/remove(), and a lot of other
| similar easy to use methods these days.
|
| It's not el.parentNode.insertBefore(new, el) and
| el.parentNode.removeChild(el) days anymore.
| cphoover wrote:
| I hear you. Personally I think learning the native APIs isn't
| so bad once you take the plunge. They are easily memorized
| with practice. Imagine not needing to go for that CDN link
| (or depending on some 3p for your website to work correctly)
| AdrianB1 wrote:
| Ajax, foreach, Datatables, small but perfect reasons to use it.
| spiderfarmer wrote:
| Daily.
| john-shaffer wrote:
| > What is the current use-case for jQuery?
|
| WordPress ships with it, so using jQuery often doesn't require
| any extra footprint. I still prefer vanilla calls for admin-
| only code, but jQuery has better compatibility for user-facing
| pages.
| manishsharan wrote:
| I use it extensively to maintaining our apps ui which has coded
| with old fashioned Backbone, Underscore and Jquery. our UI is
| working and we do not see need to re-engineer/refactor it to go
| to newer frameworks just for the sake of it.
| tenryuu wrote:
| I dropped it a long time ago for similar reasons to only using
| selectors. It was not worth adding the extra request and
| execution time for what was really now a vanilla feature.
| dr-detroit wrote:
| any popular library is already cached in everyone's browser and
| therefore * _ANNIHILATES* the performance of every character of
| .js code you 've ever written including inline_
| RHSeeger wrote:
| It is literally the first thing I add to every personal project
| I build, and it's included with a lot of things I work with
| professionally. Jquery just makes life easier.
| lostgame wrote:
| This. I can just prototype something so gosh darn quickly in
| jQuery and I'm so used to it by this point that between that
| and advancements in CSS it's incredibly awesome.
|
| Why replace what's not broken?
| Havelock wrote:
| Browser compatibility issues can be resolved with Babel and as
| such fulfills the need of jQuery and allows me to just write
| javascript.
| Turing_Machine wrote:
| > Do people still use jQuery?
|
| All the time.
|
| > This has been rolled into the Javascript document api via
| document.querySelector, and document.querySelectorAll.
|
| The official replacements for the stuff jQuery does tend to be
| verbose and non-orthogonal, as compared to the much more
| unified and consistent API of jQuery.
| brunojppb wrote:
| You wouldn't believe in the amount of solid applications using
| jQuery out there. It's still widely adopted, specially when you
| are maintaining legacy applications. While I personally don't
| use it in my day job anymore (Mostly React nowadays), I still
| know a good number of people that use jQuery in my local
| community. Worth noting: Legacy doesn't mean bad. Just software
| that sustained the tough test of time.
| rzwitserloot wrote:
| Still use it. Still love it.
|
| Just last month I decided to toss a quite arbitrary `=>` in my
| javascript (I still write `function (args) { code }`), and
| shipped it. Immediately got a _TON_ of user complaints.
|
| Turns out, we sent a link in a newsletter, and most folks were
| reading those in Outlook, and that evidently just opens links
| internally, and that is still IE11. We don't ordinarily support
| IE11, but given that this is a specific info page shown there,
| for this we make an exception, and... => doesn't even work
| there.
|
| Thus, another year goes by, and another year where I am 100%
| convinced it is totally not worth my time or effort to
| investigate newer options.
|
| I'm honestly confused about why jQuery is considered 'bad'.
|
| It's a dependency - yeah, 30k or so. This complaint (that it
| adds load time) boggles my mind; in this day and age of 10MB+
| load pages, and the choice is to complain about a 30k library?
| Some javascript-library variant of the Total Perspective Vortex
| may be warranted to try to make sense of this.
|
| A more interactive (as in, between server and browser), more
| stateful integrated model? Oh, yeah, totally, I can see that,
| but that 'formula' surely isn't the go-to strategy for every
| web page out there, right? Most of the pages I write work
| perfectly well via a 'server generates data, server throws it
| through a template and sends it to browser, client downloads
| jquery and some javascript for that page which adds interactive
| elements', and wouldn't be any 'nicer' if it was a much more
| javascript-native fully state-shared amalgamation. When I do
| need that live-updating stateful interaction model, sure, don't
| need jQuery. But that 30k is the least of my worries if that
| happens.
| shaicoleman wrote:
| "Fun" fact: Outlook today still uses Word to render HTML,
| which is about as capable as IE3 released in 1996.
| colourgarden wrote:
| Your use of the word "still" is a little misleading. IE
| _was_ the default email rendering engine until 2007 when
| Microsoft made the inexplicable decision to move to Word
| 2007 instead.
| unilynx wrote:
| My theory is still that it was about using Word as a
| component to write replies. However, if they delayed the
| HTML->Word conversion to that point, everyone would
| complain to MS "Reply is broken!"
|
| By using Word as a viewer the email is broken right on
| delivery and users now complain "The email you sent me is
| broken!"
|
| At least it's still better than Notes
| dragonwriter wrote:
| Outlook is part of Office; Word is part of Office.
|
| IE, and now Edge, is a different business unit.
|
| Not inexplicable at all. NIH doesn't only apply at
| corporate boundaries.
| tambourine_man wrote:
| It's not that simple. It used to have a more capable
| renderer, they rolled it back to the Word one (no animated
| GIFs!) and have since upgraded again. So Outlook 2007-2016
| is really crappy, versions before and after that, a bit
| less so.
|
| The lovely world of enterprise software.
| mortenjorck wrote:
| jQuery is like WordPress. There may be other more streamlined,
| purpose-built solutions out there, and they all have their
| uses, but sometimes ease of setup is the thing you're
| optimizing for, sexiness be damned.
|
| When you have a vast, mature ecosystem and a decade and a half
| of community knowledge to draw upon, even the most obscure use
| cases tend to have a precedent _somewhere_. Being able to jump
| right to a StackOverflow answer to exactly what you 're trying
| to do is, in my opinion, a highly underrated feature of legacy
| web technology.
| andrei_says_ wrote:
| I've seen the code of Wordpress and would not touch the
| spaghetti cluster-f that it is.
|
| I won't even speak of the ecosystem built on the above
| principles.
|
| All I can say is that a 1-click install does translate to
| popularity :)
| tyingq wrote:
| _" What is the current use-case for jQuery? I'm curious from
| hearing it's current users answer this."_
|
| I still see it used for file upload/download, as the fetch api
| doesn't provide a reasonable way to show progress if the
| channel is using gzip or deflate. The ajax functionality is
| also still popular for a compact way to deal with different
| types of errors (app errors vs connectivity errors).
| mschuetz wrote:
| I'm trying to wean off of jQuery to reduce dependencies, but it
| makes me appreciate jQuery all the more. The native JS API is
| quite a bit more verbose and cumbersome to use, and my absolute
| biggest gripe with it is that it doesn't even build on modern
| JS features. It's not compatible with for...of, map, filter,
| find, etc, which seems really strange for a relatively recent
| vanilla JS API.
|
| Ironically, http://youmightnotneedjquery.com/ makes a pretty
| good case in favour of jQuery.
| bigfudge wrote:
| What I don't understand is why the modern js api didn't just
| adopt query's conventions... they're so much nicer and more
| expressive most of the time.
| fendy3002 wrote:
| They cannot. If they do and remove the old
| getelementbyname, etc, then it will be breaking change.
|
| If they just add $ notation, then there will be redundancy
| / inconsistency with existing api. Furthermore it will
| break / confuse apps which use jquery.
|
| Then it's far easier to just include minified jquery into
| your apps when you want to use it, and you have more
| control about it's version, etc.
| megous wrote:
| You can easily extend NodeList.prototype with Array.prototype
| functions you like, and then just use them:
| ['map', 'find'].forEach(f => NodeList.prototype[f] =
| Array.prototype[f]);
| document.querySelectorAll('bla').map(el => whatever)
|
| That's what prototypes are for, anyway.
| rburhum wrote:
| Yes. For quick small things.
|
| When I need a to write a small web service, I usually just grab
| a python micro-framework and do the work. Not much complexity
| and not a lot of setup required. When I need to do something
| more elaborate that needs structure because it will get
| extended over time, I will take my time to setup something like
| Django... but it would be too much unnecessary work do to that
| for small web services.
|
| The same applies to front-end.
|
| When I need a few quick HTML pages that need some quick DOM
| manipulation, I usually just grab jQuery and do what we have
| been doing for years. Whenever I know that something will get
| extended over time and needs structure, that is when I take the
| time to setup React/Redux and all the build scripts necessary
| to make it work.
|
| Just personal preference, but I am sure I am not alone...
| tambourine_man wrote:
| >Do people still use jQuery?
|
| Oh yes. Everyday. Still love it.
|
| >...Javascript document api via document.querySelector, and
| document.querySelectorAll
|
| The jQuery API is still (and probably aways will be) far
| superior to the native DOM (terser, composable, more
| expressive, etc).
|
| >...smaller footprint libraries like lodash
|
| jQuery is [?]30k gziped and most likely already cached from
| CDN.
|
| >...has fallen out of favor of more comprehensible state
| management inside of JS (like React Hooks, Redux...etc.)
|
| Managing state is hard. There shouldn't be much of it in any
| single view. IMO, React doesn't bring much to the table in this
| regard while adding a lot of complexity and heft. Vue is a bit
| better, but still, I'd much rather use jQuery if given the
| choice.
|
| If you're building something like Spotify/Slack, I can maybe
| see the need for virtual DOMs, etc. If you're sprinkling
| interactivity to your webpage, which is arguably what most of
| the web should be, jQuery is probably as good as it will ever
| get.
| [deleted]
| actuator wrote:
| > IMO, React doesn't bring much to the table in this regard
| while adding a lot of complexity and heft.
|
| Strongly disagree with this. In any complex web application
| with a lot of components, specially ones where a lot of fixed
| components can live for a while, React is definitely a
| massive improvement over vanilla JS or something like
| Backbone which allows wild west.
|
| Imagine state coming from sockets, rest APIs etc with updates
| being either pull or push. A user might do an action which
| changes the state in some other component, keeping track of
| the components gets hard if the state is distributed. Also,
| centrally managed state with things like Redux allows for
| good caching of API data which can make a SPA considerably
| fast.
|
| While I love plain HTML pages which need little or no JS, a
| lot of applications are better as SPAs.
| megous wrote:
| That's more like redux and company...
| actuator wrote:
| Yeah, but redux etc gained traction with React, and
| together they make SPAs good.
| megous wrote:
| SPAs were perfectly good before with ExtJS and similar,
| and more easily extensible too.
| tomc1985 wrote:
| SPAs were never good, the entire notion of them or
| shoehorning full apps into a browser is a farce. But, as
| parent says, that ship has long sailed
| e1g wrote:
| ExtJS = "What if JSX, but in JSON" ;)
|
| For me, ExtJS redefined what's possible on the web a full
| decade before React/Angular & co, and it's sad that
| Sencha is now part of a heartless corporate graveyard.
| tambourine_man wrote:
| I'm exactly arguing against this Webpack, Typescript,
| React, etc approach to web development. I'm more productive
| in PHP + jQuery, a lot due to familiarity, of course, but
| I'm also a huge believer in a simple stack.
|
| If you've 20+ mutually dependent inputs, maybe you need a
| better UI, not a complex state management framework.
|
| If your browser is ultimately executing an untyped crazy
| dynamic language, is it worth trying to shoehorn types into
| it, only to later transpile it back? Not to mention JSX.
|
| It all seems so crazy to me, but this ship has long sailed.
| pknopf wrote:
| Make Postbacks Great Again.
| j-krieger wrote:
| At Work, we're building web applications that need to be
| accessed by hundreds of editors with thousands of pages.
| Most of them share an essential bundle of components. Are
| you telling me a project that complicated can be built
| using just jquery?
|
| Also, what's bad about typescript?
| folkhack wrote:
| > It all seems so crazy to me, but this ship has long
| sailed.
|
| Nope. And it's why Svelte is something that I've been
| hard adopting because it looks the closest to old-school
| JS/CSS/HTML while still bringing some of the same
| capabilities over that I love from React and VueJS. It
| also runs without a VDOM or a constantly running event
| loop - both things are incredibly attractive to me.
|
| Although it's not a perfect solution (nothing is) I would
| strongly suggest you checking into Svelte as it looks
| more like traditional web development vs. highly complex
| Webpack + TS + React + eslint + Babel etc etc-based
| development.
|
| The ship hasn't sailed. Your instincts to be weary of
| such a complex, constantly re-invented toolchain to get
| traditional development tasks accomplished are a natural
| response to the craziness that these tools bring to the
| table.
| tambourine_man wrote:
| I saw the Svelte presentation a few years ago when it was
| released and my jaw hit the floor hard. That was some
| cool radical thinking. I haven't used it beyond playing
| with a few examples, so I can't really tell for sure if
| it holds up. Everything looks great on the demos.
|
| Unfortunately it hasn't caught on, though it maybe be too
| early to call.
| pknopf wrote:
| Too early to call.
|
| Wait until Typescript is properly supported.
| lhorie wrote:
| That happened like half a year ago[0]
|
| [0] https://svelte.dev/blog/svelte-and-typescript
| mixmastamyk wrote:
| Svelte has been on my list to try, thanks for the
| reminder. I've also liked htmx (from intercooler) for
| keeping complexity managed. Any comparisons?
| girvo wrote:
| https://htmx.org
|
| For when I've wanted to sprinkle interactivity, this is
| what I've turned to lately. It's quite brilliant, and
| more declarative than most solutions.
|
| But React is still necessary in my day to day job, as our
| web application is incredibly complicated in terms of
| feature set and customisation. They both have a place.
| spyridonas wrote:
| I'm on the same boat, super productive with
| php/twig/jquery. But recently my boss gave my a side
| project without any specific requirements, 10 charts and
| 2-3 tables with their associated crud. I made everything
| with react + php, and oh my god that site is super fast.
| It's eye opening!
| ivosaur wrote:
| > jQuery is [?]30k gziped and most likely already cached from
| CDN.
|
| This part isn't so true in reality anymore, due to revised
| browser caching systems[1]. Doesn't mean you shouldn't use
| jQuery, just that part of the benefits of a centralized CDN
| are no longer a factor and it's a lot more sensible to self-
| host.
|
| 1: https://www.stefanjudis.com/notes/say-goodbye-to-resource-
| ca...
| tambourine_man wrote:
| Right you are. But jQuery is around the same size as Vue,
| and that's the _lean_ alternative to React. So the "jQuery
| is bloat" argument still doesn 't make much sense.
|
| A single retina hero banner is larger than most JavaScript
| libraries/frameworks.
| srgpqt wrote:
| A _lean_ alternative to React would be preact.
| cout wrote:
| Vue is the lean alternative to Angular.
| cultofmetatron wrote:
| > and that's the lean alternative to React.
|
| _Ahem_ https://preactjs.com/
| dangerbird2 wrote:
| One thing that doesn't help jquery's case is that it and
| its plugin ecosystem isn't modular, making it impossible to
| trim the code size below the minified size via dead code
| elimination or even es6 partial imports. It would be nice
| to see more fluent DOM apis like jquery, but having 1st
| class support for es6 modules so you can import only the
| functionality you need in your final bundle
| brylie wrote:
| Cash supports partial builds:
|
| https://github.com/fabiospampinato/cash/blob/master/docs/
| par...
| brylie wrote:
| ZeptoJS has a modular build tool, allowing you to select
| only the desired modules
|
| https://zeptojs.com/
| Sn0wCoder wrote:
| Thanks for the article. I was just telling someone that
| jQuery was most likely already in the browser cache so
| don't worry about it. Guess I need to go back and say I was
| wrong...
| sshb wrote:
| Well, you are still getting less server load and faster
| response times across the globe, right?
| csswizardry wrote:
| > ...and faster response times across the globe, right?
|
| Unfortunately not. There is no benefit to leaving your
| critical files on anyone else's infrastructure:
| https://csswizardry.com/2019/05/self-host-your-static-
| assets...
| abhinav22 wrote:
| As someone who is well experienced in web dev, that was a
| great article! Not so easy to find online, keep up the
| good work and I've become a fan
| [deleted]
| steviedotboston wrote:
| I agree with this 100%. Even though "vanilla JS" is more
| powerful now, JQuery is still much easier to work with.
| [deleted]
| Kudos wrote:
| Firefox and Safari use partitioned caches, and Chrome is
| following with the feature behind an experiment flag for now.
| The argument that it's probably cached from a CDN is just
| about dead.
| 1shooner wrote:
| >most likely already cached from CDN.
|
| I don't believe any major browser allows sites to share 3rd
| party caches anymore.
|
| Previous HN discussion:
| https://news.ycombinator.com/item?id=24894135
| starik36 wrote:
| True, there is still a perf win however since CDNs are
| located geographically closer to a global consumer than
| keeping the libs on your own box.
| 1shooner wrote:
| But don't modern frontend-oriented sites/apps deploy to
| CDNs anyway?
| pseudosavant wrote:
| "The jQuery API is still (and probably aways will be) far
| superior to the native DOM"
|
| The jQuery API really is so well done. I stopped using
| jQuery, but implemented a simple script (jSugar.js) that
| exposes many basic jQuery things but is really just a wrapper
| for native DOM operations. It only operates on individual DOM
| nodes. Any looping should be done using your JS loop of
| choice (forEach, for loop, which, etc).
|
| The script started out really small. I've slowly added more
| and more as I need more functionality for some projects.
|
| https://gist.github.com/pseudosavant/b86eedd9960ade958d49447.
| ..
| enraged_camel wrote:
| I used to write a lot of JQuery, and I've switched to Vue
| three years ago. Occasionally I have to go back and write
| more JQuery, and it makes my head hurt.
|
| edit: why the dowvotes? are we not allowed to share our
| experiences now?
| terracatta wrote:
| I write a lot of B2B apps that have tabular data views. For all
| of its quirks, DataTables (https://datatables.net) does a great
| job and with the right plugins offers all the features my
| customers expect (re-ordering/resizing columns, column based
| search, fixed headers, fixed columns, item selection, etc.)
| DataTables requires jQuery.
|
| Lots of other vanilla JS table plugins out there but I can't
| find one with all of those features that work when they are all
| on.
| k__ wrote:
| Legacy systems, probably.
|
| I read, Ember.js would depend on it.
| racl101 wrote:
| A ton.
| gorgoiler wrote:
| I think it's like Lisp, or rather the reaction to Lisp.
|
| In a world without jQuery every site / devshop uses their own
| little set of conventions and polyfills (analogous to macros)
| to add useful abstractions.
|
| In isolation, these are neat. En masse though it means that
| each site has their own meta language (conventions) which have
| to be memorized before you can contribute to the code base.
| Languages like Ruby and Lisp suffer from this too: there are so
| many minute variants across code based that it becomes hard to
| truly view them as the same _language_. jQuery, in the context
| of JavaScript, is a standardisation track for all those little
| language additions.
|
| Personally, I just use the native APIs. I don't work with
| enough people across enough sites to benefit from
| standardisation. You will probably find a big overlap between
| proponents of jQuery and professionals -- especially
| contractors -- who work with many other people on many
| different codebases.
| bigfudge wrote:
| Or just people who have a poor memory, or who are not very
| self consistent. I love things like jquery (and Django and
| other opinionated frameworks) because it saves me the hassle
| of having bike shed trivial details for myself and then
| remember them later. And naming things is one of the two hard
| problems etc...
| FpUser wrote:
| >"Also for me, along with I'm sure many others, keeping state
| within the DOM has fallen out of favor of more comprehensible
| state management inside of JS (like React Hooks, Redux"
|
| In my opinion using React / Redux combo for state management is
| a poor choice. So to each their own. The arguments like:
| everyone else including my cat does that do not make really it
| any better in my eyes.
| m00dy wrote:
| I use it for my landing page in countingcarbons.co
| duxup wrote:
| Every day I do.
|
| Granted I don't so much as use it as I fix it / change it.
|
| Anything new is just vanilla as far as the legacy systems go.
| But those legacy systems pay the bills...
| blain wrote:
| Well, Wordpress and Drupal still uses jQuery, they auto load it
| by default and there is no reason not use at this point, unless
| you specifically building React or some other custom thing on
| top of either of them.
| bredren wrote:
| The Django ecosystem still has a pretty strong tether to
| jquery. It's a problem.
| bigfudge wrote:
| What's the problem?
| andrei_says_ wrote:
| Yes, absolutely.
|
| The use case: a small CraftCMS-driven site using a bunch of
| long-lived jquery plugins and almost no custom JS.
|
| Also, no need for transpiring or bundling.
|
| It is wonderful.
| muglug wrote:
| I think a lot! For example, the new https://www.whitehouse.gov
| uses jQuery.
|
| When you just want to add a small bit of interaction to a
| mostly-static site, jQuery can help.
|
| There's a current trend to complicate things with a JAM stack
| that really don't need to be complicated.
|
| I've seen people propose something like
| [NodeJS/Ruby/PHP backend] -> GraphQL API
| -> React Frontend -> static html
|
| Where really they could have just gone with
| [NodeJS/Ruby/PHP backend] -> static html
| snemvalts wrote:
| There's no need to complicate static sites with jQuery. All
| it does can be achieved with vanilla.
| labster wrote:
| As a competitive code golfer, I can confidently say that
| vanilla JS has never offered the raw performance of jQuery.
| cphoover wrote:
| I tend to agree, and unless you have to support like IE
| prior to IE9 it will probably easily support all of your
| target browsers.
| WhyCause wrote:
| Promises aren't available in IE11, and as the last "true"
| IE, I imagine it'll be around a bit longer than it should
| be.
|
| I recently had to rewrite a bunch of vanilla promise-
| based code to use jQuery promises once I realized IE11
| didn't work.
| cookingmyserver wrote:
| Vanilla has always been able to do what jQuery can,
| otherwise jQuery wouldn't exist. It all depends on what
| your threshold for abstraction and verbosity is. That is
| going to depend on what you are doing and who you are.
| Turing_Machine wrote:
| Exactly.
|
| I mean, all you _really_ need is a Turing Machine, but
| they 're not very pleasant to program.
|
| Same thing with vanilla JS and jQuery.
| colejohnson66 wrote:
| > All it does can be achieved with vanilla.
|
| Well, yes. Every JS library can be written in vanilla JS.
| The point of jQuery, React, etc. is to make it easier for
| the programmer to reason about what is going on while
| avoiding bugs.
| solraph wrote:
| > When you just want to add a small bit of interaction to a
| mostly-static site, jQuery can help.
|
| For very small amounts, perhaps, but honestly, even then I
| think it has limitations. As an anecdote, about six months
| ago, I needed to add a couple of dynamic forms to a static
| site. The forms were a simple contact us, and a mailing list
| sign up form, and only needed to handle the states of
| Open->Submitting->Thanks|Failed->Open, while preventing
| double submissions, etc.
|
| I wrote the first one in jQuery (site was already using it
| due to the theming), and making sure handled all the various
| edge cases, and fixing one bug didn't cause another was far
| harder and time consuming than it should be.
|
| Out of frustration, I wrote the other form in VueJS, and
| hacked the whole form in about an hour or two. My take away
| was that anything involving state in jQuery can get overly
| complicated very quickly.
| moocowtruck wrote:
| whitehouse.gov uses jquery because its wordpress
| wishinghand wrote:
| > When you just want to add a small bit of interaction to a
| mostly-static site
|
| Then I'd reach for Alpine. Very lightweight, and I can use
| the fetch API instead of $.ajax.
| makeworld wrote:
| Perhaps even htmx?
|
| https://htmx.org/
| iagovar wrote:
| This looks very cool, thanks.
| ergo14 wrote:
| or Lit-Element.
| purple_ferret wrote:
| Jquery has been around for 14 years. That framework..16
| months.
|
| You want to be as confident as possible you can bump to a
| new version on your old site in 4 years if you have to? Use
| Jquery.
| SamuelAdams wrote:
| Plus it's easier to hire for. Chances are more developers
| have experience with JQuery than <new hot js library>.
| wishinghand wrote:
| Or just fork Alpine and fix it. It's javascript, not
| rocket science.
| ognarb wrote:
| I do think in some cases SPA make sense, but in many other
| cases just using a bit of jQuery/vanilla js to add a bit of
| interaction is enough. Server side rendering is way easier to
| do and is often faster to load for the client.
| dna_polymerase wrote:
| SPA make sense whenever you want to write a proper
| application running in the browser. When you just want a
| website, stop the SPA madness.
| kyriakos wrote:
| To be fair the first case is only static for the initial load
| then becomes a single page application
| muglug wrote:
| Yeah, but very few sites need to be SPAs. SPAs come with a
| tremendous amount of extra requirements that, over time,
| can mire projects in cruft.
| krab wrote:
| For me personally, it's partly familiarity and also still
| compatibility. I know that if I use jQuery, then (for the parts
| it covers) I don't have to search caniuse.com.
|
| But then, I'm not a front-end web developer, so I optimize for
| different type of projects.
| pull_my_finger wrote:
| > there are rowser compatibility issues that jQuery solved
|
| Current browser support[1] isn't really _that_ great. I know it
| used to be, but I'm not sure that's a legit selling point these
| days. Not that it's bad, but I hear that argument come up a
| lot.
|
| [1]: https://jquery.com/browser-support/
| HaloZero wrote:
| I use it primarily because it provides an easy interface for
| ancestor, descendant utilities. But I'm also not doing this in
| a FT setting, just for side projects.
| okhan wrote:
| I help teach an introductory programming class to high school
| students. We still use jQuery to teach basic programming
| concepts, because it helps students add basic interactivity to
| a web page without a) the overhead of learning a full framework
| like React, or b) exposing them to the insanity of web APIs.
| Check out the curriculum if you're interested:
| https://github.com/itscodenation/curriculum-20-21
|
| If you just want to add simple interactivity to a web page,
| jQuery provides a really nice API to do just that. Sure it's
| not the ideal thing to build a whole SPA on, but it has its
| place.
| llarsson wrote:
| Every single WordPress blog ships it by default.
|
| I would not start a greenfield project based on it today, sure,
| but it is used by a truly staggering amount of sites today, so
| having it get updates in the form of security fixes and some
| additional functionality benefits a large part of the web.
| bcrosby95 wrote:
| > This has been rolled into the Javascript document api via
| document.querySelector, and document.querySelectorAll.
|
| Have you actually compared the two methods in a real website?
| It's like saying why use Ruby when you can use Java. The
| Javascript document API is super verbose. No thanks.
| bilekas wrote:
| > The Javascript document API is super verbose.
|
| Can't say I've ever heard that as an issue before..
|
| Also I think the main point was there are so many better
| frameworks that manage the DOM better than jQuery as the need
| has evolved. I'll always have fond memories of jQuery but I
| don't see it as my go-to anymore, by a long shot.
| runj__ wrote:
| I'm still a little bit sad we got fetch as part of javascript
| when the request module had such a great interface. I still
| prefer the look of it.
|
| https://www.npmjs.com/package/request
| frabert wrote:
| How so? Who stops you from doing something like `const $ =
| document.querySelector`?
| cphoover wrote:
| Good point
| Epskampie wrote:
| There's a ton of other functions you need like
| element.addEventListener, insertAdjacentElement,
| XMLHttpRequest (when you need progress) etc. etc. At that
| point you might as well save yourself and the person after
| you a major headache and just use jQuery whose API
| everybody knows.
| cortesoft wrote:
| The big magic of jQuery is that you can act on an array of
| elements as if it were a single element. Your alias does
| not give you that at all.
| cphoover wrote:
| You don't have to use all of it though, right? You can choose
| to only only use the applicable parts: eg:
|
| ``` $('.container-element') .addClass('active');
|
| // vs
|
| document.querySelectorAll('.my-class-selector')
| .classList.add('active') ```
|
| I use the native APIs all the time, they are not that
| complicated or overly verbose. Easily memorized with practice
| IMHO. Also they are all extremely well documented on MDN.
| vbezhenar wrote:
| Your example does not work. querySelectorAll returns array
| and you can't write `array.classList.add("...")`, because
| array does not have that property. You need to iterate over
| that array. And that's exactly why jQuery is so much more
| convenient over native API: you can just treat collections
| of elements like an element and jQuery will iterate for you
| if necessary.
|
| Another jQuery advantage is pseudo-selectors which don't
| exist in CSS.
|
| There are plenty of convenient one-liners in jQuery which
| will expand to plenty of lines in native API. That said,
| with modern API and JS features it's not that bad either.
| mkl wrote:
| querySelectorAll returns a NodeList, which is even more
| limited than an array (e.g. no map or filter).
| ROARosen wrote:
| but [...querySelectorAll()] does return an array and is
| just as concise
| lhorie wrote:
| but beware of ASI :)
| t_tsonev wrote:
| Just a nitpick, but querySelectorAll returns a NodeList.
|
| This can bite at times, for example IE supports
| Array.forEach, but not NodeList.forEach
| dceddia wrote:
| Yeah this gets me every time. You can .forEach a
| NodeList, but can't .map. I usually end up wrapping it in
| an array and calling map on it like
| [...theNodeList].map(...)
| [deleted]
| cortesoft wrote:
| I think the fact that your very simple example (which is
| already longer and more complicated in your version)
| doesn't work shows the advantage of jQuery
| lhorie wrote:
| Technically that breaks, you want:
| document.querySelectorAll('.my-class-selector').forEach(el
| => el.classList.add('active'))
|
| Personally I use the native APIs because they aren't _that_
| hard to use (most of them, anyways) and I tend to be OCD
| about bundle sizes, but to each their own, I suppose.
| megous wrote:
| Yeah, oh so many years ago I realized that I use just a
| small subset of jQuery, and just rewrote those bits, to
| avoid having to inject whole of jQuery into all pages
| that I browse (I had some global https?://* userscripts,
| so I was basically injecting jQuery into every single
| page and frame).
|
| https://megous.com/dl/tmp/basic.js
|
| 1.3kB compressed. Much better. :) And I avoided having to
| rewrite my extensions with platform APIs. That was before
| FF killed all the joy in writing userscripts for me,
| because I was no longer able to install and update them
| just by copying them to mozilla folder and had to invoke
| a lot of clicking ceremony to just get my 20 scripts or
| so from git into firefox past the webextension
| limitations on storage/access to mozilla folder.
| dan-robertson wrote:
| Isn't your example a type error. JQuery's operations auto-
| broadcast over the lists of elements it returns whereas the
| native methods don't
| Kaze404 wrote:
| Conversely, looking at how you do it through jQuery after
| seeing how it is in Javascript gives me the same reaction.
|
| The fact that jQuery is usually assigned to the dollar sign
| definitely doesn't help, especially for beginners. The amount
| of questions I've answered that stemmed from a fundamental
| misunderstanding of how Javascript works, all because they
| learned jQuery instead of Javascript, is pretty significant.
| cosmotic wrote:
| That argument stands true for most frameworks on most
| platforms. I prefer the dollar sign; it's pervasive and
| concise.
| Kaze404 wrote:
| I disagree. There's nothing about React, Vue or any other
| framework that I'm aware of that does anything similar to
| jQuery's dollar sign. The only magically-looking
| abstraction I can think of is JSX, and that's not only
| not mandatory but very obviously something that's off the
| curve. Unlike the dollar sign, which just looks like a
| special construct of the language.
| mettamage wrote:
| I remember when I was in uni that the $() must've had a
| special meaning or something. I was pretty convinced that
| the $ was some tough mathematical operator or computer
| science concept that I didn't yet understand.
|
| When I learned that it was simply a function invocation
| that returned a jQuery object so you could chain it, I was
| absolutely shocked about the simplicity of that statement.
|
| Beginning developers sure like to project their cognitive
| insecurities onto programming. Or at least, I did :)
| macintux wrote:
| There's so much magic in programming that as a beginner,
| it's hard to know which magic you should dig deeper into,
| vs which is such a treacherous rabbit hole you're better
| off cargo culting.
| bigfudge wrote:
| It think this is true of many technical things.
| Statistics, sailing, car mechanics, photography... What I
| love about HN is it often gives clues as to which are the
| interesting rabbit holes.
| laurent92 wrote:
| I never understood why people say "We've solved your jQuery
| problem" by introducing getElementsByClassName() or even
| querySelector(). When I come back to my older app, $(".my-
| class") is still much nicer. jQuery gets out of the way, the
| class gets syntax-highlighted, and .focus() can't create an
| NPE.
| wishinghand wrote:
| One could also save document.querySelector to $ as a
| constant.
| vbezhenar wrote:
| That would be very confusing for unsuspecting reader.
| Please use something different, I would suggest `qs` for
| `querySelector` and `qsa` for `querySelectorAll`.
| tyingq wrote:
| I know it doesn't replace jQuery, but this is fairly
| straightforward: $ =
| document.querySelector.bind(document) $$ =
| document.querySelectorAll.bind(document)
| vijaybritto wrote:
| Using this since ages. Also use window.DOM = document
| josteink wrote:
| > jQuery gets out of the way, the class gets syntax-
| highlighted, and .focus() can't create an NPE.
|
| So if your selector is wrong, you won't actually know,
| because your code will pretend to run along just fine.
|
| I personally consider that a con, not a pro, and one of my
| (many) reasons _not_ to use jQuery.
| brundolf wrote:
| There were other things like the "Ajax" (remember that word?)
| API, but that one's also been matched by a native API (fetch())
|
| > keeping state within the DOM has fallen out of favor of more
| comprehensible state management inside of JS
|
| Not everything needs a whole reactive templating library.
| There's absolutely still a usecase for mostly-static sites to
| do imperative DOM manipulation.
|
| The usecase for jQuery itself these days is dodgier, since as
| you point out most of its big features are native now. It
| should still help with browser compatibility (not necessary for
| modern-ish browsers, but many sites don't want to limit
| themselves to modern-ish browsers), its APIs are arguably still
| a little nicer in some places, and it does have a significant
| ecosystem of plugins so there's probably some value in having
| that stuff integrate together. But personally I would have a
| hard time justifying a whole library just for slightly nicer
| APIs unless I was doing something significantly complicated,
| and at that point I would just use React.
| kemiller2002 wrote:
| There are still a ton of legacy sites that use it. New
| development? Don't know, but the last 2 companies I worked for
| had massive systems written in JQuery.
| justsomeuser wrote:
| I like jQuery because:
|
| - The API is still more concise than what is built into the
| browser (Compare the number of lines used here:
| http://youmightnotneedjquery.com/)
|
| - It is still useful for older browsers that might not support
| something.
|
| - The API is burned into my brain, it speaks jQuery.
|
| - If I have any issues, Google will usually surface how to use
| the API faster than the (standards compliant API * can I use
| it?)
|
| I do use React for UI, but sometimes you have to interact with
| the DOM; in those cases for larger programs I find jQuery
| easier to read and write.
| [deleted]
| TedShiller wrote:
| > Do people still use jQuery?
|
| Oh yes. Very much so.
| yawaworht1978 wrote:
| JQuery and reading Resig's book and viewing the source code are
| responsible for lifting me from horrible dev to below average
| dev:-)
|
| I learned to extend the library and understood to create some
| minimal libraries for myself.
|
| It can be very useful to this day and is almost a ballerina when
| comparing the bloat of other frameworks or library stacks.
|
| You never know maybe the come up with something better than
| react.
| _the_inflator wrote:
| jQuery taught me how to write JavaScript frameworks. John Resig,
| the founder of jQuery, wrote a book called "Secrets of the
| JavaScript Ninja" was back then really a mindbender.
|
| Function.prototype.toString() is really the craziest thing I know
| to date regarding JS. Heavily used in earlier versions of jQuery
| according to the book.
| sethx wrote:
| Please elaborate about toString() ?
| jffry wrote:
| The toString() method returns a string representing the
| source code of the function.
|
| https://developer.mozilla.org/en-
| US/docs/Web/JavaScript/Refe...
| Dragonai wrote:
| That's pretty neat. Thanks for the link.
| byroot wrote:
| If called on a Function it returns the source of the
| function, which allows for all sorts of meta programming.
| hajile wrote:
| If memory serves, a real world example was Angular doing a
| toString then injecting dependencies before calling eval on
| the new code.
|
| To be honest, I don't know that there's ever a good reason
| to use it in production as it almost always involves
| performance and security problems.
| davidmurdoch wrote:
| > involves performance [...] problems
|
| Except when it solves them!
| https://mrale.ph/blog/2018/02/03/maybe-you-dont-need-
| rust-to...
| unbendable wrote:
| Crazy to think what legacy jQuery and others left. Now I am using
| React and the usual lib stack.
|
| But I remember using jQuery, pug (or jade), browserify, bower...
| that was what 5 to 6 years ago?
| sethx wrote:
| It's still not dead??
| neilpanchal wrote:
| jQuery has the kindest, most warm hearted, whimsical release
| notes.
|
| During the pandemic last year:
|
| > We hope you're staying healthy and safe while so many of us are
| stuck at home. With a virus ravaging the planet, we realize that
| jQuery may not be a high priority for you or the sites you
| manage. When you do have a moment, we recommend that you review
| this new version and upgrade.
|
| Some fun:
|
| > I've never gotten to say this on a jQuery release, but May the
| 4th be with you! A short time ago in a galaxy exactly like this
| one, we released jQuery 3.5.0.
|
| Release notes are also very well thought out and their philosophy
| is to "move slowly and not break things". I admire that. They go
| to great extent to provide help about how to deal with breaking
| changes. Ends with a section thanking the contributors.
|
| Super nice people.
| maxpert wrote:
| I sometimes look at react, and these modern frameworks and wish
| they had a same nice API as jQuery. I still profoundly remember
| how much simple it was compared to Prototype.js, and how simple
| it was to do a zebra stripes on table. I am still looking for
| that next piece of revolutionary simple library that will bring
| the joy of jQuery with modern concepts and simplicity.
| drummer wrote:
| Jquery is awesome. I still use it in all my web projects.
| niftylettuce wrote:
| I'm a happy jQuery/Bootstrap user @ https://forwardemail.net.
|
| The site scores ~100% on Lighthouse and PageSpeed Insights and is
| ranked #1.
|
| Open-startup @ https://forwardemail.net/open-startup!
|
| Completely open-source too @ https://github.com/forwardemail
| tluyben2 wrote:
| Offtopic but thanks for launching this.
|
| A happy customer.
| spiderfarmer wrote:
| Yes but if you're not using the latest JS framework how do you
| get girls.
| pqdbr wrote:
| This. I was a happy Rails dev but html over the wire wasn't
| cutting it at the club anymore. So I had to switch to React
| and now I'm married.
|
| Just kidding. My wife loves Rails.
| rubyist5eva wrote:
| Jokes on you, html over the wire is HOT NEW SH*T.
|
| https://hotwire.dev/
| megous wrote:
| You get a girl by going places where girls congregate at a
| similar or higher percentage to guys. Took me a while to
| figure that out... Anyway, I understand sarcasm, too.
| Sulamitachica wrote:
| Nice open start up page! Congrats on success, will be signing
| up for the free plan with my domain!
| Johnny87 wrote:
| Wow 15k??? That's impressive. I use another email forwarder but
| haven't been happy with it, maybe I'll switch.
| mehphp wrote:
| From your FAQ
|
| > No. Prices will never increase. Unlike other companies, we
| will never shutdown our service either.
|
| How can you guarantee this?
| WORMS_EAT_WORMS wrote:
| Super cool. I really like that you can also reply using this
| service to each individual inbox. Like a universal inbox but
| not married to any specific client/app. Maybe suggest making
| that a little more easier to learn on your marketing homepage.
|
| For your current users, are you seeing them use this more like
| the demo gym owner video or for other use cases? Thanks
| thesimon wrote:
| Do you use automatic translation? At least the German version
| feels a bit odd.
| kureikain wrote:
| I no longer use jQuery nowadays due to React/Stimulus but one
| nice thing about jQuery is ability search for an element in a DOM
| note and append html. You can do it with raw JavaScript but
| jQuery API is light years ahead.
| megous wrote:
| For a good reason. XSS is no joke. I even block innerHTML and
| friends in my apps via empty trusted-types and require-trusted-
| types-for 'script' CSP.
| [deleted]
| claytongulick wrote:
| I think a lot of the comments in this thread that are critical of
| SPAs are thinking about them wrong.
|
| SPAs aren't (shouldn't be) a replacement for websites.
|
| They are a fantastic option for replacing native apps (PWAs).
|
| Moving from walled garden native apps to the open web is good for
| everyone except the app stores.
| Klonoar wrote:
| I think jQuery is amazing, but one thing that I've found over the
| years is that the real killer for it was CSS animations becoming
| simpler to use and more widespread in terms of support.
|
| The final thing I used to reach for jQuery for was animation
| support, but that need is by and large gone now. AJAX/JSONP is
| good there, but to be honest it's not something that needs a
| wrapper these days.
|
| Glad to see the library is still updated, though - for sites that
| might not have a budget to upgrade, knowing it's still got
| support must be nice.
| Tenal wrote:
| CSS animations are a pain-inducing non-starter for thousands of
| recurring use cases.
|
| Example: Using Javascript to SHOW a modal, but then relying
| applying addClass('animate') using CSS animations to transition
| that modal (eg: bottom of screen to center, while fading in)
| are nearly impossible without tons of hackery. The animations
| do not render.
|
| Hence jQuery animation calls.
| megous wrote:
| CSS animations are a necessity if you want any kind of
| performance on mobile browsers and older phones.
| bredren wrote:
| They are. But I still wouldn't turn to jquery to solve this
| particular problem.
___________________________________________________________________
(page generated 2021-03-02 23:01 UTC)