[HN Gopher] Gov.uk drops jQuery from their front end
___________________________________________________________________
Gov.uk drops jQuery from their front end
Author : feross
Score : 345 points
Date : 2022-05-19 13:34 UTC (9 hours ago)
(HTM) web link (web.dev)
(TXT) w3m dump (web.dev)
| tomc1985 wrote:
| I miss the days when jQuery reigned supreme, and all the
| tenderfoot magpie developers didn't yet have the twinkle of React
| in their eyes
| smrtinsert wrote:
| I remember doing pocs with observables, angular and react back
| when they were all way new and thinking observables really
| makes the other two unnecessary.
| Cthulhu_ wrote:
| I don't; it was an improvement when BackboneJS came out so I
| could reason about larger scale applications, and another
| improvement when AngularJS came out so I could build and write
| tests for logical, reusable components, and another when React
| (especially in 2022) was there and reduced these components to
| simple JS functions.
|
| That said, I don't like how complicated modern day front-end
| development is, to the point where you need a university degree
| to even try and fathom some of React's inner workings (e.g.
| https://reactjs.org/blog/2019/11/06/building-great-user-
| expe...) etc.
| tomc1985 wrote:
| Oh god, Backbone. I absolutely hated that framework. It
| didn't even seem to do anything, it seemed like I had to
| implement all of the logic myself. Except I had to do it
| their way, for some reason, and practically nothing made
| sense. (I haven't touched it in years, though, so my memory
| is probably distorting my experience)
|
| I like the _idea_ of React, just not what it has turned into.
| The amount of tooling that it has created to do things that
| should be simple (but aren 't because of the runtime and/or
| the programmer), and the gymnastics it goes through so that
| people can have their precious (often unnecessary) SPAs, is
| ridiculous. That, and JSX continues to be an abomination that
| shits all over separation of concerns so that smoothbrains
| don't hurt themselves trying to reason over it.
| LNSY wrote:
| Re: React, have you looked at Vanilla custom elements:
|
| https://javascript.info/custom-elements
|
| I've been using them lately and I think they are the bees
| knees.
| tomc1985 wrote:
| Yeah I have been looking them over and they seem very
| interesting. Have not tried them yet.
|
| Would love for there to be One True Way(tm) without the
| framework question.
| DeathArrow wrote:
| HTMX + custom elements + Alpine.js = love
| egberts1 wrote:
| [deleted]
| shadofx wrote:
| CSS is too much as well, client XSLT to XHTML is good enough
| for any reasonable website.
| egberts1 wrote:
| Agreed. So far it's -4 karma for me.
|
| There must be a grain of truth in there ... somewhere. Nah,
| just an inconvenient truth.
| mkrishnan wrote:
| bullshit. there are tons of images in this site most are above
| 10kb, there are several images I could find which are above 20kb.
|
| Jquery is passive, just loading jQuery in the page itself doesn't
| do any harm. could be some plugins they are using might be doing
| something unnecessary.
| [deleted]
| divbzero wrote:
| You Might Not Need jQuery [1] has been my favorite resource for
| convincing myself and others that it's OK to forgo jQuery.
|
| [1]: https://youmightnotneedjquery.com/
| ei8ths wrote:
| I love jQuery. I've been trying to do vanilla when it makes
| sense.
| d1sxeyes wrote:
| I don't mind so much gov.uk using jQuery, but I noticed recently
| that the UK government's 'parliamentlive.tv' has a dependency on
| jQuery loaded from Google's CDN, when there was a Google outage
| in the country I live in (I think it was something to do with
| routing on Vodafone's side, rather than an actual Google outage).
|
| I see that's now removed, but Recaptcha is still there. The site
| works without it, but it seems a bit odd to me that by default,
| my data is shared by my government with a third party company
| when I want to participate in democracy online.
| zendaven wrote:
| I still use jQuery for frontend JavaScript when I can. It's so
| much more efficient than native JavaScript. I can't imagine
| anyone prefers to write
| document.getElementById('element').style.display = 'none' rather
| than $('#element').hide();
| SadWebDeveloper wrote:
| When you are dealing with less than 5 "interactive things",
| jQuery is awesome... beyond that it might be better to consider
| a front-end framework.
|
| Jr devs have the tendency then to discard jquery because "is
| old" not because it isn't working anymore.
| Beltalowda wrote:
| I think it's not so bad if you organize things reasonably
| well and minimize "lemme just modify the DOM a wee bit here"
| hacks. jQuery was popular at a time when "cowboy programming"
| was very common, leading to a lot of really bad/difficult
| jQuery apps; but that wasn't strictly jQuery's fault, as
| such.
|
| That said, front-end frameworks can of course be a better
| choice for many things, even if it's just because it provides
| this kind of organisation by default making it easier for
| the, ehm, less organized devs.
| dspillett wrote:
| Though for that little work, I'd rather have a small local
| library that implements what I need over standard DOM & JS
| parts instead of the full weight of jQuery.
|
| Unless of course I need to support legacy browsers, then jQ
| is a no-brainer - that crap is solved there and I don't want
| to have to deal with it myself.
|
| And while jQ is large compared to my little home-grown set of
| wrappers, it is small compared to all the other stuff many
| pages draw in these days, so perhaps size isn't a great
| metric to criticise it on!
| ulisesrmzroche wrote:
| that crap is solved in a lot of places, jQuery is no longer
| the only library, and you don't need to support legacy
| browsers as much anymore, if at all
|
| Companies are getting more security-conscious because of
| all the hacks and the pain of keeping old browser support
| is no longer outweighing the risks of upgrading is my
| theory.
| psnehanshu wrote:
| There are tools like babel (even typescript) which can help
| you support older browsers.
| parksy wrote:
| I am not against jQuery but if it's just verbosity then it's
| quite easy to:
|
| const $ = document.querySelectorAll.bind(document)
|
| Then later:
|
| $('#element').whatever
|
| I used to be a big proponent of jQuery especially in the heyday
| of shims and browser hacks, but in the last few years I find it
| often gets in the way of what I'm trying to do. Now that the
| native browser APIs are maturing and relatively consistent,
| having direct access to the objects and their properties is
| simply more predictable than having to second-guess a layer of
| abstraction that does the same job but differently.
|
| I have to remember, what does jQuery's .hide do again? It
| doesn't just set display to none or visibility hidden. Give it
| a duration, and it will use the style attribute to manipulate
| the display, width, height, opacity, padding, margin, etc. Then
| it leaves some style properties behind. Ugh. Do I really want
| to do all that stuff? Do I really want to build my UI framework
| around jQuery so I can avoid annoying transition artefacts?
|
| Not hating on jQuery. Just my own experience. I used to feel
| liberated when using it because browser APIs were so terrible
| but now I feel encumbered if it's included as a dependency on a
| project I'm forced to work with, because it does so much black
| box magic. If you avoid certain things and stick to what it
| does well then it's not bad, but then there's no point using it
| because what it does well is no longer a pain point in browser
| APIs.
|
| For me the main thing it excelled at was DOM selection and
| manipulation. Native does that just as well now. The secondary
| benefit was animation, which these days native CSS can go a
| long way without excess verbosity, and if you really need a
| more feature rich animation library I've not come across any
| better than Greensock for getting the job done, even if it does
| have a paid tier, though I am sure there are dozens of other
| libraries equally suited for animation, the point is that is
| not jQuery's strength either.
|
| Anyway circling back to what you were saying, efficiency-wise,
| for any complex animations jQuery isn't the best tool for the
| job. For DOM manipulation native can be just as easy with some
| sugar. It can do a lot of unexpected and hidden things most
| people aren't aware are happening, so many bugs and time wasted
| realising jQuery was messing with style attributes that break
| an otherwise well designed layout.
|
| I would rather write a few characters more code or a couple of
| lines more to have direct control over what's actually
| happening. That seems more efficient to me.
|
| Edit: Ok on reflection I guess I am against jQuery, but I don't
| hate it. Using it these days just feels like trying to figure
| out how to get it to do what I want to the underlying APIs,
| when I could more easily and predictably just be manipulating
| the APIs directly.
| dbrueck wrote:
| jQuery was great in its time and still has some places where it
| can be a good tool for the job, but it isn't used less now
| because people like writing the longer form of Javascript; it's
| used less now because for many projects people are using
| frontend frameworks that let you operate at a higher level
| altogether.
| marcolussetti wrote:
| I think the more direct comparison is
|
| document.querySelector('#element').style.display = 'none'
|
| That has the same ergonomics as the jQuery selector, and is
| just a bit longer. I feel like with editors that autocomplete,
| it's not enough of a difference to warrant the extra
| dependency.
| [deleted]
| hbn wrote:
| I think the vanilla JS is better actually, because I actually
| know what it's doing.
|
| I've never used JQuery before and would have assumed calling
| .hide() on an element would set the CSS attribute
| "visibility: hidden" rather than "display: none"
| yyyk wrote:
| >That has the same ergonomics as the jQuery selector
|
| Nitpick: This crashes if #element doesn't exist, while the
| jQuery one does not. Also, the jQuery selector is a tiny bit
| more powerful (:even, :odd).
|
| IMHO, jQuery is good for what it's built for - a nicer
| interface than vanilla - but the main use case is much less
| needed now that frameworks exist.
| zamadatix wrote:
| The same power exists, again a bit longer, :nth-of-
| type(odd).
| jacobsenscott wrote:
| A but fugly, ?. helps - document.querySelector('#element')?
| .style?.SetPropery('display', 'none')
| dbbk wrote:
| Does your IDE autocomplete the jQuery code though? I'd imagine
| it wouldn't. But it would for the native code.
| jacobsenscott wrote:
| There are fewer and fewer people who know jquery, so while this
| might be convenient for you or me, this is just more cognitive
| overhead for programmers who don't know jquery. There are
| multiple ways to hide an element, and what does `hide()` do?
| Some future programmer will need to look this up, and every
| other jquery method they stumble across.
|
| The main problem I have with jquery though is there's no
| convention for event binding, so there is literally no way to
| know if an element depends on a jquery event handler without
| grepping the js for every class, id, and data selector on the
| object. Even that doesn't always help. This makes it almost
| impossible to remove jquery from a project without breaking it.
|
| Alpine or stimulus do a much better job of filling the event
| handling holes that still exist vanilla js. Dom
| traversal/manipulation in vanilla js is good enough, even if it
| isn't 100% as good as jquery.
| upupandup wrote:
| but see now you are reliant on jQuery and need to figure out
| how to load that first.
|
| with vanilla, it would be just typing a bunch of extra
| properties.
| savanaly wrote:
| I would say jQuery has a place in any codebase that's simple
| enough it has imperative statements like that. Past a certain
| not-too-high level of complexity you're much better off writing
| "if (condition) then <element> else null" in your view and
| "condition = false" in your update instead of even the short
| $('#element').hide();.
| junon wrote:
| I prefer to write the first.
| my69thaccount wrote:
| By "more efficient" it seems like you mean "less typing"
| because that is significantly less efficient in terms of
| downloaded code size and performance (the jQuery code calls the
| vanilla code.)
|
| PS. $ is an alias for document.getElementById so you can just
| do $('my_id').style.display = 'none'.
| pastor_bob wrote:
| most people probably have jquery cached in their browser if
| you're pulling it from the google cdn
| jameshart wrote:
| Thanks to cache partitioning, this is no longer true.
|
| See, it turns out that by carefully leveraging cached
| retrieval of third party resources, scripts on two
| different domains can figure out if they are running in the
| same web browser, effectively pulling off browser
| fingerprinting.
|
| To stop this, modern browsers don't share third party
| resource caches cross domain.
|
| So using a well known CDN no longer confers any benefit -
| even if a user has pulled down jquery for another site's
| benefit, when they come to your site and you request the
| same resource, the browser will go out and re-retrieve it,
| to prevent you or the third party domain from being able to
| infer anything about the user based on the speed of the
| response or whether or not the request got made.
| pastor_bob wrote:
| ahh wasn't aware, and good to know
| jameshart wrote:
| Indeed. We cannot have nice things.
| sensanaty wrote:
| LocalCDN is great for this! Avoids both the privacy
| concerns, plus makes things a bit speedier as everything
| is readily available locally already
| dbbk wrote:
| As others have mentioned this isn't the case, also the
| browser still has to parse that JavaScript, which for a
| lower end mobile phone is often significant.
| my69thaccount wrote:
| That hasn't been the case for years because of per-origin
| caching. CDNs get their performance from edge routing, not
| caching.
| mrtksn wrote:
| These days it seems like you don't touch DOM yourself anymore
| because it's all about virtual DOM that is managed by the
| framework of choice, which is probably ReactJS.
| ufo wrote:
| According to the Matt Hobb's twitter thread, they had to do a lot
| of work to get rid of the JQuery dependency. Does anyone know
| what kind of challenges they encountered along the way?
| jjice wrote:
| Tangential, but sometimes I see people say that jQuery is
| dead/failed. While it's not as popular anymore, I think that's
| actually the perfect evolution for it. jQuery was making up for
| browser API shortcomings, and now many of those shortcomings have
| been addressed and been incorporated into browser APIs (not
| everything, but quite a bit).
| legitster wrote:
| > jQuery was making up for browser API shortcomings
|
| While this is true, I can still code circles around frontend
| developers using vanilla JS.
|
| The decline of jQuery is mostly due to the rise of webapp
| frameworks like React and Vue. But if you are tasked with
| adding like, a button to a static webpage, jQuery is still the
| king.
| macspoofing wrote:
| >The decline of jQuery is mostly due to the rise of webapp
| frameworks like React and Vue.
|
| Partly. Frameworks like Angular/React/Vue are a necessary
| byproduct of building and maintaining large codebases. But
| the fall of jQuery was largely a result of a more standards
| approach in mainstream browsers (said another way:
| deprecation of IE and not needing to work at maintaining
| consistent behavior across browsers), as well as adding
| traditional jQuery-like features to vanilla JS.
|
| There really isn't a big use-case for jQuery anymore,
| although I will remember it fondly.
| fatnoah wrote:
| >While this is true, I can still code circles around frontend
| developers using vanilla JS.
|
| My first use of jQuery was in the dark days was building UIs
| (with things like drag and drop, etc) that had to run on
| Internet Explorer and Netscape. We'd started with "vanilla"
| but were ending up with what was effectively two separate
| codebases. Moving over to jQuery let us eliminate a massive
| amount of duplicate code and dramatically increased our
| productivity.
| wnevets wrote:
| one of the nice features of AngularJS when it came out was
| the inclusion of the jquery lite api for interacting with the
| dom.
| martin_a wrote:
| I never really knew jQuery besides the five things that I
| googled, so once I had to do more "dynamic" frontend things I
| just looked into Vanilla JS and it kind of works for me. Not
| sure if I had WTF-moments besides the normal "this seems to
| be how things work" stuff, so I think it's easy enough?!?
|
| Only thing I always have to look up is how to make sure my
| script is executed once everything is done and not before and
| "ready()" is obviously easier than adding an event listener
| to "DOMContentLoaded". Yeah, had to look it up for the
| comment.
| legitster wrote:
| Simplifying interaction with the DOM is obviously a huge
| feature of jQuery. But also the functions are just very
| nicely laid out with the assumption you are doing web
| stuff.
|
| $(thing).doThis() is just so perfectly terse and
| understandable for what it's doing. Not just writing, I
| find jQuery to be very, very easy to understand and read.
| martin_a wrote:
| Yeah, you're right. Maybe I should give jQuery another
| look. :-)
| ulisesrmzroche wrote:
| I call bullshit on all accounts. If someone actually tasked
| you with adding a button to a webpage...
| hinkley wrote:
| When people have said this to me in the past I would trot out a
| list of features that were still useful, but there are one or
| two where I think the defaults are backward. There was a long
| time between when "jQuery is dead" and parent selectors of any
| kind existed, and list comprehension is still a huge miss.
|
| I still wonder occasionally if there's a place for a library
| that works like a strict subset of jQuery, but with different
| error/empty set handling defaults. Especially with list
| comprehensions. I found that 9 times out of 10 if I run a
| selector I'm expecting results, and jQuery will silently eat
| that error, requiring a bunch of inline error handling in the
| 'interesting' paths in your code. I'd be much happier with an
| optional parameter for silent failure or even writing the
| occasional try/catch.
| SemanticStrengh wrote:
| I really don't get this discourse, jQuery API is much more
| ergonomic, concise and clearer than the DOM api. Sure you can
| do it but that doesn't mean you should
| ldiracdelta wrote:
| I think that the improved vanilla js is now "satisficing" for
| more people. Their threshold of ergonomic usability has been
| achieved and they stop looking:
|
| https://en.wikipedia.org/wiki/Satisficing
| [deleted]
| pastor_bob wrote:
| Just replace that one liner with a 15 liner.
| LNSY wrote:
| document.querySelector('html')
|
| And for React: https://javascript.info/custom-elements
| DeathArrow wrote:
| And you would replace $.getJSON by how many lines?
| nobleach wrote:
| are we doing CORS? Adding headers? If it is just a one-
| off fetch, I'd probably long-hand it. If I intended to be
| fetching from many endpoints, I'd probably write a tiny
| little abstraction. I'm not exactly keen on loading a
| 30kb lib (gzipped) so that I can write (maybe) fewer
| lines for data fetching. Especially considering jQuery's
| async requests don't conform to the fetch standard. (They
| reject on 404s)
| [deleted]
| SemanticStrengh wrote:
| It's not because you know how to do a hello world that
| you know how to program.
| mejutoco wrote:
| Other functions are much more difficult to replace
| $('.sth').closest('ul')
|
| To me jQuery is like Regex or Linq. I think it had a
| really good api.
| frosted-flakes wrote:
| You can also do this with DOM APIs, no?
|
| https://developer.mozilla.org/en-
| US/docs/Web/API/Element/clo...
| mejutoco wrote:
| This did not exist the last time I looked. TIL. Thank
| you!
| augusto-moura wrote:
| Is not the same thing as it is a Element method, not
| NodeList one, so you will would need to map it instead.
| Because NodeList doesn't have the .map method you would
| also need to transform it to a Array first.
|
| So the actually drop-in replacement of
| `$(foo).closest(bar)` would be something like:
| Array.from(document.querySelector(foo)).map(el =>
| el.closest(bar))
| CraigJPerry wrote:
| Is it harder or just a bit longer-winded? E.g. i'm
| thinking this is the same behaviour
| document.getElementsByClassName('sth')[0]?.closest('ul');
| zimpenfish wrote:
| That's not exactly the same, I don't think, because
| jQuery will give you all the `ul` that are closest to
| `.sth`, not just the first. You'd have to write a loop
| over the list returned from
| `document.getElementsByClassName('sth')` to get the same
| behaviour (because it doesn't look like the standardised
| `closest` works on lists.)
| CraigJPerry wrote:
| If i'm following right, i think this expression would
| match?
| Array.from(document.getElementsByClassName("sth")).map(e
| => e.closest("ul"))
|
| The jQuery is definitely nicer to read than this though
| zimpenfish wrote:
| Yeah, that seems to do the same.
| mejutoco wrote:
| Thanks, this is now standard it seems. TIL
| [deleted]
| cmer wrote:
| I think it's a bit of both. jQuery served the purpose of
| making web development more sane back in the day by handling
| all browser quirks. Part of that was the nice syntax.
|
| I personally have tried to drop jQuery, but truthfully, its
| syntax is just much easier to use. Nowadays, I use Cash
| https://github.com/fabiospampinato/cash to give me the nice
| syntax without the bloat. It strikes the perfect balance for
| me.
| mmis1000 wrote:
| Although writing jQuery is still shorter (And likely will
| forever be). Editor (like vscode) nowadays is much more
| smarter then the era.
|
| A lot of API with long names is no longer a issue to type.
| You just mark the variable as a element. After that,
| autocomplete handles the rest for you. Shorten the gap with
| experience of using jQuery. If developer tools is still as
| dumb as that era. I would think the transition is
| impossible.
|
| And there are also more frameworks to enhance experience of
| style modification or templating. Back to then, there are
| only some dumb template that do initial rendering. But
| framework these days also handles update for you. So you
| don't really need to modify it directly by yourself unless
| in some edge case.
| masklinn wrote:
| > I personally have tried to drop jQuery, but truthfully,
| its syntax is just much easier to use.
|
| It's not just the syntax, it's also the expression-heavy
| and chained API which makes it much more flexible. As well
| as the set-oriented approach, which can lead to performance
| issues if you're not careful but is generally extremely
| enjoyable.
|
| The DOM is an extremely procedural, plodding API, you need
| to name everything because you always need to set
| attributes and call non-chainable side-effecting APIs, not
| to mention the fecking NodeList which has to be converted
| to an array to do basically anything useful (in part
| because Javascript never really embraced iterators, and
| instead uses arrays for everything still).
|
| I guess you could mitigate that with an "API adapter",
| but...
| acomjean wrote:
| I did a javascript project targeting web/blackberry and
| early ios. We used jQuery to smooth out the kinks (or
| that's what our lead told us). It worked as expected.
|
| Went from disliking it to really liking the syntax. Its
| pretty clear and easy to use, which is why I still use it.
| We don't use it extensively becaue we're still on the
| "submit form, get page back with javascript graph and data
| tables table, development model. We probably should
| transition to a framework, but they evolve so quickly ...
| threatofrain wrote:
| Ad hoc manipulation of the DOM contradicts the philosophy of
| a lot of frameworks, as that is state which is unaccounted
| for.
| icedchai wrote:
| Yes, the DOM API is painful to work with.
| moffkalast wrote:
| Time to drag out this old classic: https://pics.me.me/what-
| does-l-use-jquery-jquery-mean-tmeans...
| dgb23 wrote:
| I agree. Also reminds me of CSS resets, the goal of modern-
| normalize is to make itself obsolete.
| DeathArrow wrote:
| What's more convenient
|
| $.getJSON('/my/url', function(data) {
|
| });
|
| or
|
| var request = new XMLHttpRequest(); request.open('GET',
| '/my/url', true);
|
| request.onload = function() { if (this.status >= 200 &&
| this.status < 400) { // Success! var data =
| JSON.parse(this.response); } else { // We reached our target
| server, but it returned an error }
|
| };
|
| request.onerror = function() { // There was a connection error of
| some sort };
|
| request.send();
|
| ?
| jefftk wrote:
| fetch('/my/url').then(response => response.json()).then(data =>
| handle it)
| MaxLeiter wrote:
| Why not use fetch?
| divbzero wrote:
| To be fair with the comparison, we should add error handling
| for the jQuery example: $.getJSON('/my/url')
| .done(data => { // success })
| .fail((jqxhr, textStatus) => { if (textStatus ===
| 'timeout') { // connection error } else {
| // HTTP status error } })
|
| And also consider the Fetch API alternative:
| fetch('/my/url') .then(response => { if
| (!response.ok) { // HTTP status error }
| return response.json() }) .then(data => {
| // success }) .catch(error => { //
| connection error })
| duxup wrote:
| Good policy, but also not huge gains here IMO. I wouldn't choose
| jQuery as I can do everything I need without it, but I also don't
| know of any serious issues it represents if it hangs around here
| or there.
|
| I have a bunch of old code that uses jQuery, it works, everything
| new is vanilla but otherwise it's not a big impediment / problem
| that I find.
| lelandfe wrote:
| I am _all for_ dropping jQuery. But...
|
| Unless this team perfectly did a 1:1 replacement of jQuery calls
| with equivalent native JS functions, this isn't "removing a 30KB
| dependency reduced blocking time by 11%."
|
| It's "we rewrote our JS and it reduced blocking time"
| hinkley wrote:
| Talking to developers sometimes feels like hitting the same
| wall when I talk to people about whether putting all of your
| money into a house is a sound investment strategy.
|
| There's a lot of willful blindness about cost structures. If it
| were just one or two people you might conclude that folks are
| trying to sweep things under the rug, and when I was just
| starting out I did feel that way. But it's so consistent that I
| often end up bonding with people who _don 't_ feel that way,
| without putting Dunbar's Number into any sort of danger.
|
| One of the hardest "Code smell" issues I've had to contend with
| is the habit of people to spread out problems so thin that you
| can no longer see them, because they're everywhere. Like being
| in a room with a bad smell, eventually you can't detect it
| without a major change of perspective. Even though everyone new
| who comes in starts with, "what _is_ that smell? "
|
| 11% of your blocking time on a library could be a perfectly
| reasonable *budget*. The mistake is not having a goal, or
| assuming the goal is zero. Zero is dumb, because if that's your
| target then we'd be talking a static HTML page and then why are
| they paying you? So what's your _real_ budget? And given that
| budget, what 's a reasonable proportion for different concerns?
| 1/9th spent on a library is probably a bargain.
| petepete wrote:
| There's only a small amount of JavaScript used on GOV.UK and
| everything degrades gracefully.
| SemanticStrengh wrote:
| > It really begs the question: Do we really need Ergonomy today?
| That's a question that GOV.UK has answered with a resounding
| "no".
| Smaug123 wrote:
| I don't know if you've ever used gov.uk, but I have literally
| no complaints about it (other than a few content-level ones,
| which the web design team can't help with). It's honestly a
| brilliant site.
| brainwipe wrote:
| Bravo gov.uk, the design/web team do a fantastic job. I'd be the
| first on the bash-the-government bandwagon but their work is
| exemplary. If they can work with modern js alone and still be
| compatible to people on Safari 9 and IE11 then respect to them!
| snowl wrote:
| There's almost no point talking about javascript on HN with the
| amount of anti JS & anti framework rhetoric that happens here
| systemvoltage wrote:
| There is also excessive praise for Gov UK design system that
| takes up half of the vertical space with cookie banner, flash
| messages, and navigation bar. It has so much useless negative
| space.
|
| I would give it 5 marks out of 10. It's decent but not a
| bastion of good design.
| jackdh wrote:
| Maybe not design but I would say it is a bastion of
| usability.
| systemvoltage wrote:
| I prefer USWDS for usability:
| https://designsystem.digital.gov/
|
| Gov UK design system is poorly usable. From color use to
| disorganized, scattered layout; it's put together with
| haste and not much thought.
|
| What it's good at is looking sexy and minimal which
| captivates a lot of people.
| zinekeller wrote:
| While I haven't experienced USWDS deeply, that's kind of
| a problem in itself. A good design that doesn't get
| deployed is just that - a design. Gov.UK might not be
| pretty but it's consistent across different ministries,
| departments and instrumentalities which helps
| tremendously, but US government websites, even if
| restricted to the federal level, is a mess that I would
| prefer to hold my tongue at the inconsistency. What is
| GAO's plans to deploy them at least at a federal level?
| _Is there even a plan?_ By the way, it 's not solely
| Gov.UK which has this level of consistency (Singapore
| comes to my mind) so it's not a unique property.
| hinkley wrote:
| jQuery isn't a framework though (that's half of why I like(d)
| it). Or are you talking about the number of lunatics on both
| sides of the argument crowding out everybody else?
| jenscow wrote:
| The 'H' is for Herd
| Taylor_OD wrote:
| I've used jQuery at 2 of the 3 companies I worked for. It can
| take you very far. Frankly some of the critical features, like
| making selecting element easier/shorter, should have been ported
| into JavaScript long ago. I think jQuery is still around largely
| because it makes, otherwise vanilla, JavaScript easier to use.
| psnehanshu wrote:
| jQuery is still around because it's hard to get rid of. Think
| of all those WordPress websites that use themes, which have
| jQuery in it. Who is brave enough to remove jQuery?
| happyopossum wrote:
| This article says makes 2 competing claims
|
| A) jquery deals with inconsistent browser implementations,
| largely in older browsers
|
| B) replacing it with modern API calls made the website more
| usable for all users including those on older machines (and
| presumably OS's)
|
| I don't see how to square those.
| acdha wrote:
| The older browsers which shaped jQuery's design aren't in use
| any more but you're still paying for the code which now largely
| duplicates built-in features. For example, if I use
| querySelectorAll I'm using the browser's native CSS parser and
| getting a native NodeList back - all of the work is being done
| in some of the most optimized C++/Rust code in existence. If I
| use jQuery, there's a lot of code which has to parse that
| selector, build data structures, etc. and some of that is
| working around limitations which haven't been an issue since
| IE6 was released. It's not as bad as a full virtual DOM, there
| are a lot of smart optimizations there but it's still running a
| lot more non-native code & memory which inevitably adds up on a
| large project. On older devices with less RAM and memory, this
| is a lot more noticeable - especially if those are Android
| devices which started at half the equivalent iOS performance
| when they were new.
|
| The other problem you get is common to a lot of frameworks:
| it's good that you can get a lot done but that means you can
| get s lot further without learning how it works underneath and
| by then you don't want to revisit all of that code. This is
| especially easy to miss when your developers all use fast
| systems - React 3+ orders of magnitude slower isn't noticeable
| on your $5k MacBook Pro but it might be when your grandfather
| tries to use that site on his 2011 PC, and by then you probably
| don't want to do a messy refactoring on a large codebase.
| zamadatix wrote:
| "Older" in those lines isn't fungible. E.g. jQuery's older
| browser would be IE 9 while Gov.uk's older browser would be IE
| 11 (they do have limited support for back to 8 though but it's
| not expected to be matching).
| bob1029 wrote:
| The extra verbosity of vanilla JS never really bothered me.
|
| I currently work with B2B applications in a sensitive banking
| context, so any time I can feasibly remove a 3rd party dependency
| it's almost certainly getting removed.
|
| The extra LOC and time overhead is more than worth it for us. We
| get dinged on older products which _do_ use jquery all the time
| by our customers who insist on using other 3rd party security
| scareware to light up random parts of their infra. I can 't use
| 'but its elegant' or other technical handwavey bullshit as an
| excuse when the Chief Security Officer of Bank of America shoots
| me an email, even if there is zero chance the detected
| "vulnerability" would actually pose any risk in that particular
| context of use. Certainly, we could spend the time & energy
| fighting for exceptions, but its _way_ easier to write a few
| extra lines of JS.
|
| Don't forget the performance angle either. If you are doing a lot
| of element selection in a hot loop, document.getElementById can
| be orders of magnitude faster than the jQuery alternatives.
| qwerty456127 wrote:
| AFAIK (I'm not a front-end dev but tried some) vanilla JavaScript
| has much of the things jQuery provided built-in nowadays yet they
| look much longer.
|
| Now as JavaScript accumulated a lot of legacy stuff only kept for
| compatibility + also numerous verbally/syntactically sub-elegant
| APIs IMHO it is time to design a language which would simply be
| "better JavaScript" - clean, modern and elegant yet have no
| fundamental differences so it would be very easy to transpile by
| just string replace/mapping, essentially just a lightweight
| "syntactic sugar+discipline" layer. Then it can be integrated in
| browsers directly.
| cies wrote:
| > design a language which would simply be "better JavaScript" -
| clean, modern and elegant yet have no fundamental differences
|
| JS' problem is that it is fundamentally not "clean, modern and
| elegant". It was designed in a couple of days. And all the
| greatness that's added to it nowadays is done in a much better
| design process than at it's inception, yet some choices made at
| it's inception can never be reversed.
|
| I've written some Elm and think it is phenomenal at being a
| better JS; but it fundamentally very different. Rotten
| fundamentals are notoriously hard to fix; especially when a lot
| has been built on top and needs to keep running.
| qwerty456127 wrote:
| AFAIK Elm can not be considered "a better JavaScript" because
| it not only is fundamentally different, if also is not self-
| sufficient - in many cases you have to resort to JavaScript
| pieces while engineering an Elm app.
| overgard wrote:
| Idk, with a cdn and caching you're really talking about a one
| time 30k hit, ie, nothing. But im glad the web has adopted its
| innovations
| synergy20 wrote:
| jQuery has the best API design ever, I hope Javascript can
| support that natively one days.
| tbranyen wrote:
| We found it to be about 32kb gzip+minified in our builds. I just
| dropped it from one of our apps, where it wasn't even used except
| in a legacy logging module. We replaced the ajax call with XHR.
| The other app we maintain has it as well, again only for the ajax
| method.
|
| While it may be nice, for large production apps we'll take the
| filesize gains where we can find them.
| tomschwiha wrote:
| I believe it's kind of sad that in the days of 2 TB USB sticks
| that 32kb matter.
| tbranyen wrote:
| Our product is used by all sorts of devices and resources.
| Many use it on super old hardware in different countries.
| 32kb isn't much, but when you're analyzing Time To Render
| metrics, you might be surprised how little is necessary to
| move the needle.
|
| That said I don't expect a massive impact from this change,
| but removing unused code is going in the right direction.
| tomschwiha wrote:
| Removing large chunks of unused code feels refreshing, that
| is true.
| llIIllIIllIIl wrote:
| Can someone ELI5 what's wrong with jQuery? People complain about
| 30 kilobytes jQuery consumes. But at the same time their 5mb
| minified react babellized gulped uglified webpacked blob is
| alright to load. Is there anything else that is missing?
| velcrovan wrote:
| Good
| JJMcJ wrote:
| We don't know what else was done to the site while jQuery was
| removed.
|
| I would assume that the British government had considerable
| resources to put on the rewrite so it's quite possible that the
| removal was part of a general site refresh.
| seydor wrote:
| The more Jq goes out of fashion, the better it becomes, because
| it means it stops changing and you can rely on it for decades.
| The other framework that looks interesting is htmx
| account-5 wrote:
| I'm new to web-dev.
|
| Having read the vast majority of comments it seems some people
| think jQuery is unnecessary/obsolete. Others say it's API is
| better, more concise, more flexible, etc.
|
| As a newbie I decided to learn vanilla JS as I was too confused
| with the state of the various frameworks; I mean what one would
| you choose to start with?
|
| That said I'm interested in what jQuery can do that vanilla JS
| can't.
| hu3 wrote:
| jQuery is very comfortable and succinct for some DOM
| manipulation here and there. That is, when you need to sprinkle
| HTML with a bit of JavaScript.
|
| But if you're starting today and want to have it easy in your
| career, learn React or Vue. They pay better and they look good
| in your CV. And I say that as someone who likes jQuery.
|
| If you want to bet on something new, I suggest
| https://kit.svelte.dev or https://www.solidjs.com
| jenscow wrote:
| > That said I'm interested in what jQuery can do that vanilla
| JS can't.
|
| jQuery is written in JS, so jQuery can't do what JS can't.
|
| The main reason for using jQuery, as you say, is a cleaner API
| for DOM manipulation...
| $(".something").parent().append($("<button />").text("click
| me").click(fn));
|
| If you know nothing about jQuery, you can guess what that does.
| Of course, you can do it in vanilla JS too. However it's a
| little harder to write and (more importantly) read.
| [deleted]
| dbrueck wrote:
| Try Svelte, it's amazing!
|
| I never consciously made a decision to stop using jQuery, but
| after moving to frameworks like Svelte, there's just not a need
| for it most of the time (it's been years since I last added
| jQuery to a project, and I think that was only because I was
| using some third party lib that depended on it). YMMV of
| course.
| reggieband wrote:
| When I first started programming I was pretty lucky to get a job
| at a games company. My first lead was a veteran who had shipped a
| lot of AAA titles and he loved his war stories. He was personally
| interested in performance and he would often cite hardware
| timings for specific cpu instructions.
|
| One story he told a couple of times was about some grey beard who
| was before his time. The grey beard was once a legend in the
| company, often helicoptered into projects at the last minute to
| help them squeeze out the last bit of performance. His secret was
| he had a mental library of assembly language tricks applicable to
| the hardware of his day. But every few years his tricks were less
| and less relevant as hardware changed and compilers advanced. One
| day the grey beard was helicoptered into my leads project and
| everyone expected him to get them some gains. However, this was
| new hardware and none of his old tricks worked.
|
| I think of this story whenever I see jQuery popup on Hacker News.
| There is always a strong contingent of devs who swear by this
| library. But to me, they are like the old grey beard who didn't
| update his knowledge as the times changed. At one time jQuery
| allowed them to be the hero and "Get Things Done" faster than
| their competition. But times have changed.
|
| Argue with me if you must but take stories like this one for what
| they are worth. The writing is on the wall for jQuery. I was
| writing websites before jQuery existed, during the reign of
| jQuery and still today. If some candidate mentioned proficiency
| with jQuery during an interview I would be polite but internally
| I would note that the person might be out of touch. Not a red
| flag, but a yellow flag that I would follow up on. Nothing worse
| than bringing on a guy who claims to be senior/experienced and it
| turn out his old tricks won't work because they are no longer
| appropriate.
| smrtinsert wrote:
| Yeah this is why I fired my contractor for using a wrench. A
| hammer should be good enough.
| Andrew_nenakhov wrote:
| I fall in a different camp. If somebody proposes to use a brand
| new hot technology in a project that is planned to exist more
| than a few weeks, I tend to politely stop them in their tracks
| and use a stable reputable solution proven by time.
|
| You see, new hot technology is always replaced by another newer
| hot technology, and after hotness wanes, projects often become
| a abandoned and unmaintained.
|
| Extra this if the proposed hot new tech comes from Google. In
| this case person pushing it should not only be stopped, but
| also slapped hard, to help come back to senses.
| simion314 wrote:
| I wish JS would get all the nice jQuery features, like all the
| css selectors jQuery has, like a nice feature would be when you
| retive an HtmlElementCollection to be able to apply some
| transformation to all elements without having to write a for,
| or make use Array.from and then use forEach.
|
| But I agree I would not use jQuery in new project and when
| possible I would replace jQuery in existing code too.
| [deleted]
| acdha wrote:
| > to be able to apply some transformation to all elements
| without having to write a for, or make use Array.from and
| then use forEach.
|
| This has worked for many years. I typically add a shorthand $
| for the QSA part and on projects where I used to support IE11
| you could add Array.from there but I haven't bothered since
| IE was deprecated. jQuery does more but some of those things
| had performance impacts which were worth thinking about and
| the combo of QSA and fetch took care about about 90% of my
| projects.
|
| document.querySelectorAll("div").forEach(i => i.innerText =
| "test")
| Someone1234 wrote:
| That's what everyone keeps missing. Can vanilla do what
| jQuery can? Of course, and that has always been true. What
| jQuery (and similar) offer is quality of life stuff, vanilla
| has never even tried to offer.
|
| This is still an ecosystem without a standard library and
| with no consistent design style/layout. It is janky and bad.
| It being "less bad than it used to be" isn't the shiny
| endorsement that everyone thinks it is.
| nikanj wrote:
| jQuery is implemented in vanilla JS, thus logically all of
| it's features can be done vanilla JS
| adamisom wrote:
| That is generally true and not really specific to jquery
| 0xFF0123 wrote:
| That's a bit like saying everyone should code in
| assembly. The argument isn't whether it's possible, but
| whether it's easier / more efficient.
| nikanj wrote:
| I guess I should have added more meat to my comment:
|
| It's frustrating when people reject a good tool like
| jQuery, with the argument that the same functionality can
| be achieved with just vanilla JS.
| [deleted]
| megous wrote:
| You can extend HtmlElementCollection prototype with any
| methods you like. (it's NodeList, btw, what's returned from
| querySelectorAll)
| strbean wrote:
| My understanding is that mutating built in prototypes is
| very bad. Not just for interop reasons, but because doing
| so really hinders many optimizations javascript engines
| perform.
| cogman10 wrote:
| Adding methods to prototypes is effectively free. The
| only time mutating a builtin prototype has negative
| consequences is when you replace a builtin function with
| your own thing. All javascript engines (that I'm aware
| of) JIT at the method level so there's not really a
| performance impact modifying a prototype.
| simion314 wrote:
| There is an issue you need to be aware , be careful if you
| hide the fact that this collection is "live". I mean this
| part from the docs
|
| >An HTMLCollection in the HTML DOM is live; it is
| automatically updated when the underlying document is
| changed. For this reason it is a good idea to make a copy
| (eg. using Array.from) to iterate over if adding, moving,
| or removing nodes.
|
| So you need something that will also be efficient and
| correct, not a 5 minutes implementation.
| vlunkr wrote:
| I think you're greatly exaggerating the death of jQuery
|
| > old trick's won't work
|
| > writing is on the wall
|
| jQuery still works and is used in an crazy amount of websites.
| It's not going away soon. The biggest downside is the extra
| network request, but it's probably cached in 99% of browsers,
| so all that's left is some extra CPU time.
|
| You're also exaggerating the claims of jQuery defenders. No one
| here is arguing that the site should keep jQuery, or that you
| should write a ton of new jQuery code.
| somehnacct3757 wrote:
| Chrome started partitioning the cache a couple years ago to
| mitigate timing attacks, so there's no network savings
| anymore when a bunch of sites all link to the same jQuery cdn
| entry.
| Gigachad wrote:
| Someone did tests on it before this and found that with how
| many versions and cdn sources there are, your exact jquery
| is almost never in the cache.
| sefrost wrote:
| I believe Safari has been doing it since 2013.
|
| https://bugs.webkit.org/show_bug.cgi?id=110269
| samwillis wrote:
| While I agree to some extent, jQuery is so prolific online [0]
| there will always be jobs for those "grey beards" who know it
| well. There will always be legacy codebases that make extensive
| use of jQuery that will never be rewritten and are too
| important to retire.
|
| jQuery is the new Cobol!
|
| I'm not a "grey beard" but I'm currently doing a freelance
| project updating the UI on a Perl+jQuery site... As much as we
| would like to rewrite it from scratch it's very unlikely to
| ever happen, it's going to be maintained as is with small steps
| towards "modernisation" over time.
|
| 0: jQuery is used by between 15-40x more sites than React
| depending source:
|
| https://www.similartech.com/compare/jquery-vs-react-js
|
| https://w3techs.com/technologies/comparison/js-jquery,js-rea...
| dheera wrote:
| To be fair, vanilla JS, especially document.querySelector,
| still hasn't caught up with all the features of jQuery and
| any other framework is going to be much, much bigger than
| jQuery.
|
| It's not COBOL until something replaces jQuery that is
| _easier_ than jQuery.
| 0xCAP wrote:
| Speaking of gamedev and jQuery, I work at a company where we
| basically make games for education purposes, for high profile
| universities, mostly. The games are all web applications, and
| we've learned to bend React in each and every direction to best
| serve our uncommon use case. A few months ago we needed some
| extra firepower, and offloaded a project to a small team of
| external consultants. I'm still shocked by what they shipped:
| the smoothest and juiciest web game I've ever seen, made with
| the messiest and most ancient clusterfEUR#k of jQuery I've ever
| witnessed in existence. The moral of the story to me is: no
| matter how cool your new shiny tool is, old, battle-tested
| tools have generated generations of wizards which, given the
| right scenario, can still bring magic to the table.
| SEJeff wrote:
| Amusingly, I always joke that I'm fluent in jQuery, but no
| absolutely no javascript. As a mostly backend go/python/non-
| javascript developer that has always held true.
|
| It is just a tool in the belt for an engineer. Can you use
| jQuery in 2022 or later to solve really amazing problems that
| impact user experience? You sure can! Would you be better off
| to use a modern javascript variant and stuff like react
| instead? You also absolutely would.
|
| So just because a tool is old doesn't mean it can't be used to
| solve real user problems. There are still banks and airlines
| that run COBOL, and as a user, do you really care that much?
| I'd take "knows $insert_older_less_hip_tech_here" as experience
| of having done something for awhile.
|
| Now if I was asked to write a front end today, I'd have to sit
| down and properly learn react + typescript (because javascript
| is awful without sensible type checking), and that would add to
| the time to ship, but is the correct thing to do.
| cogman10 wrote:
| While I think that's the right choice, I'd just like to point
| out that the problem with jQuery today is it was a library
| built to smooth over and fix differences between browser
| JavaScript engines (IE, well, IE).
|
| Over the past 15 years or so browser JavaScript engines,
| except at the extreme edges, are roughly comparable. Further,
| a lot of the features of jQuery have been adopted into
| standard JavaScript.
|
| So, the reason of eschewing jQuery, even for small pages, is
| simply that you don't need it. Vanilla JS (or typescript) +
| modern CSS have pretty much all the same capabilities without
| any of the bloat. Using it today would be a little like using
| a library made to back port java 8 features onto a java 5
| JVM.
| strbean wrote:
| > smooth over and fix differences between browser
| JavaScript engines
|
| And let us avoid some of the extremely verbose and un-
| ergonomic standard APIs.
| tinco wrote:
| Why react though? Just modern JavaScript (and typescript) is
| a great replacement for jQuery.
|
| The react part is just for when you need to build something
| that needs architecture.
| tambourine_man wrote:
| >Would you be better off to use a modern javascript variant
| and stuff like react instead? You also absolutely would.
|
| Why?
| planetsprite wrote:
| when you say veteran do u actually mean veteran of a real life
| combat war who later joined the games industry or veteran of
| the games industry
| Smaug123 wrote:
| You know "veteran" does mean "someone with a lot of
| experience in something", right? In non-US countries that's
| even the primary meaning.
|
| https://dictionary.cambridge.org/dictionary/english/veteran,
| https://www.oxfordlearnersdictionaries.com/definition/englis.
| .. both give its primary meaning as "a person who has had a
| lot of experience of a particular activity" or similar. Even
| Wikipedia gives the generic definition first, and clarifies
| the more specific case as "military veteran".
| 8ytecoder wrote:
| For everyone of these "grey beard" stories I can point you to a
| "young gun" story involving a fad of the week framework that's
| just over complicated and over engineered and doesn't even
| solve anything.
|
| A long time we had a really good engineer who can crack
| topcoder and coding challenges with ease. We had a problem
| where we had to collect all changes to the User models and send
| it to the marketing platform. It was initially implemented in
| Rails Active Record which took progressively more time to
| collect and sync changes. Rails was hot at the time and SQL was
| really frowned upon. A lot of developers to this day hate SQL.
| Then came a "grey beard" who simply rewrote the whole thing
| into a single complex query that let the database figure out
| the optimum way to find the exact same data. Total time went
| from over 10hrs to 10mins.
| rhapsodic wrote:
| linkdd wrote:
| what's so wrong about sprinkling some jquery on a static
| website (generated with hugo or jekyll)?
|
| On https://kubirds.com I use:
|
| jQuery appear: https://plugins.jquery.com/appear/
|
| jQuery fancybox: https://fancyapps.com/docs/ui/fancybox/
|
| Do not put jQuery to the trash yet, it still have a long life
| ahead.
| httpsterio wrote:
| It's pretty expensive to ship and compute. Wikipedia for
| example dropped jquery from their navigation and it resulted
| in a ~27% difference in battery usage IIRC.
| influx wrote:
| I checked out kubirds, and even though I'm probably somewhat
| in your target demographic, I noticed that I couldn't
| discover what kubirds does without watching a video.
|
| Even scrolling down, and through the website, I didn't really
| understand it, until you compared to Nagios, which I am
| familiar with. Hope you don't mind a little unsolicited
| feedback. The website does look super clean!
|
| I would love to read a paragraph of your elevator pitch the
| moment I lay my eyes on the site though. Cheers.
| linkdd wrote:
| Thank you a lot for the feedback! We'll definitely do
| something about it :)
| retcon wrote:
| It's only8 minutes since your responseso I'd just like to
| say that I almost immediately got the gist of your
| product before any changes. Long advertising experience
| means like a remedial English teacher I'm better than
| most reading poorer copy but I consider your(unchanged)
| copy very good. Unfortunately without the words"audit",
| "WORM" and"incident search" present or prominent I'm not
| your market. But I could think of many thousands of
| publication sites longing for your tool, if those terms
| applied.
| linkdd wrote:
| Thank you for the feedback as well :)
|
| > I'm better than most reading poorer copy but I consider
| your(unchanged) copy very good.
|
| This is nice to hear/read, yet I'm a perfectionist who
| knows perfection do not exist. The pitch can always be
| improved and clarity/transparency is very important to
| us.
|
| > Unfortunately without the words"audit", "WORM"
| and"incident search" present or prominent I'm not your
| market.
|
| This proves my previous point, since we rely on Docker
| images to implement the monitoring/reactivity part,
| literally ANY workflow/business logic can be applied (but
| we've been told that it's hard to trust "it can do
| everything").
|
| > But I could think of many thousands of publication
| sites longing for your tool, if those terms applied.
|
| I'd love to get in touch with you about that, if you have
| time, you can find my contact info in my profile:
| https://news.ycombinator.com/user?id=linkdd
| ianleeclark wrote:
| > what's so wrong about sprinkling some jquery on a static
| website
|
| You're talking past one another. He's speaking in the context
| of AAA games, and the equivalent of that in the webdev world
| is a highly interactive application.
| bcrosby95 wrote:
| I don't see anyone saying to use jQuery for highly
| interactive applications. If that is the comparison, its
| not talking past eachother, the original comment is a
| strawman.
| ianleeclark wrote:
| > I don't see anyone saying to use jQuery for highly
| interactive applications.
|
| I don't know what to tell you. The first sentence in my
| comment was a quote and the rest of the comment was
| responding to say how that quote was misunderstanding the
| OP.
|
| I never said anyone specifically said to do that, but
| that, in the metaphor that the OP made, a static website
| isn't an accurate comparison to a AAA game.
| ConcernedCoder wrote:
| The part you're leaving out, is that once confronted with the
| fact that his old easy tricks don't apply, the well-seasoned
| fellow will draw on his years of experience to provide new
| tricks to save the day.
|
| I think your portrayal of well-seasoned engineers as the
| derogatory 'greybeard' with a 'bag of tricks' and a hero
| complex -- glosses over the fact that many of these men and
| women have real hands-on experience with a multitude of
| technologies spanning decades, and in my mind there's real
| value / leadership qualities associated with individuals
| companies can rely on to just "get things done" in a pinch.
| soperj wrote:
| What newer libraries are you using for performance gains?
| treeman79 wrote:
| I've seen a single jQuery developer be replace by a team of 20
| angular developers a couple times now. The jQuery was far more
| productive
| dlandis wrote:
| > But to me, they are like the old grey beard who didn't update
| his knowledge as the times changed.
|
| Maybe it's just me but with all the rampant age discrimination
| nowadays in tech, I really don't like to see the continued
| propagation of this stereotype.
|
| All sorts of people of all ages are unwilling or unable to
| update their knowledge of new tech, there is no reason to link
| this characteristic to someones advanced age.
| Suzuran wrote:
| I have found the opposite of the stereotype to be true; I
| feel I've learned more in the last 5 years or so than I have
| the previous 30 because I now have the experience to
| contextualize and sort it all, the discipline to stay focused
| and active when Real Life doesn't want to let me, and access
| to resources that would have cost an unreasonable sum even 10
| years ago.
| judge2020 wrote:
| It was just a reference to the person in the story, not an
| allusion to "because he was old he didn't try to update his
| knowledge/continue learning".
| squiffsquiff wrote:
| So why describe him as a "greybeard" then? It are you
| claiming to have met many younger and/or female
| 'greybeards'?
|
| If your answer is that 'it's just part of the story'. Well
| that's precisely the complaint.
| jokethrowaway wrote:
| It's 2022. Men can get pregnant and women can have a
| beard.
|
| Greybeards is an inclusive term and it's a well known
| term.
| burnished wrote:
| Because it communicates a well understood idea. It is
| great that we as a society are becoming more conscious
| about the way we speak, but I feel like your complaints
| here are aimed anyone who isn't achieving the proper
| level of 'purity'.
| skavi wrote:
| greybeard has always felt like a term of respect to me.
| personally i think of the type of person who could have
| been at bell labs in its heydays. definitely could
| exclude women though.
| capableweb wrote:
| The meaning of "greybeard" have moved from being
| literally, to current be figuratively. It doesn't mean
| that the person is A) old, B) man C) have a beard and D)
| that the beard is grey.
|
| It simply means someone experienced/being at something
| for a long time. The greybeards at a company can be all
| women of the age 26, but if they been with the company
| for 5 years when the company got started 5 years ago,
| they are the greybeards of that company.
|
| Might as well say "veteran" or "old-timer", although
| "old-timer" would imply actual old age, "veteran" implies
| nothing like that.
| o10449366 wrote:
| The OP doesn't link the characteristic to their example's
| age.
| reggieband wrote:
| This is a fair criticism of how I chose to tell the story.
| The line you quoted was supposed to refer to the character
| introduced in the second paragraph and not to a generic
| stereotype of aged man.
|
| I can see how my choice of wording created an implication
| that people who have grey beards are old and that it is this
| oldness that contributes to their unwillingness to learn. The
| familiar cliche of "you can't teach an old dog new tricks".
|
| What I actually hope to communicate is that there is a hubris
| which leads some to believe their skills do not require
| updating. The caution is that sooner or later this hubris may
| lead to sudden downfall. People may call on you in their time
| of need and you will fail. And this failure is not because of
| your age, your intelligence or your willingness to work hard.
| You will fail because you became overly comfortable with a
| passed status quo and you let your skills get out of date.
|
| I see a trend of well-written, evidence backed articles where
| large, well funded sites are making a case to deprecate
| jQuery. These fact-based investigations into problems faced
| by their dev team result in a reasoned decision to remove a
| dependency that no longer justifies its cost. I encourage
| everyone to introspect if their defense of jQuery is on an
| equal technical footing to these types of investigations.
| kordlessagain wrote:
| > I think of this story whenever I see jQuery popup on
| Hacker News. There is always a strong contingent of devs
| who swear by this library. But to me, they are like the old
| grey beard who didn't update his knowledge as the times
| changed.
|
| This is a strawman argument. It's a biased view you hold.
| Because of that, you make up a story to match your biases
| around people who use such-and-such library don't think
| they need to update their skill set. I'm not angry about
| this, but am only pointing out biased arguments create
| dissonance.
|
| > I see a trend of well-written, evidence backed articles
| where large, well funded sites are making a case to
| deprecate jQuery. These fact-based investigations into
| problems faced by their dev team result in a reasoned
| decision to remove a dependency that no longer justifies
| its cost. I encourage everyone to introspect if their
| defense of jQuery is on an equal technical footing to these
| types of investigations.
|
| You read something somewhere about how jQuery is a costly
| dependency. Yet, there are no links that I can see anywhere
| in the threads here, nor a good rational argument for
| people to NOT use jQuery because it is a costly dependency.
| There are opposing opinions on this, but the opinions that
| it needs to be included via CDN don't address the fact it
| can be hosted locally and the opinions "who needs all that
| code to load?" don't take into account that browsers and
| networks are bonkers fast nowadays. Who cares if it's a bit
| more code? It's not like jQuery is growing its codebase at
| the rate compute and network speed increases.
|
| For that matter, could not the same argument be made of
| JavaScript itself? I taught myself Promises, not because I
| could stay "relevant", but because it makes good sense to
| write code that is easy to read and maintain, even if it is
| me doing both on my project. The code I produced when I
| wasn't doing Promises was "legacy" the second it hit the
| repo, and will be "costly" if someone else has to jump in
| and work on it to convert it to Promises, because they'll
| have to brain dump what I was thinking (or not) when I
| wrote it!
|
| This salt and pepper beard stays up on technology. I didn't
| really write code in the past, but now I'm great at what I
| do and I fully intend on exploring new technologies when
| they compliment what I can do rapidly in the frameworks and
| methods I well understand, if that's what it takes to get
| to market faster.
| lhorie wrote:
| IMHO this analogy doesn't really click, on multiple levels.
| Any old timer who uses jQuery surely is also aware of
| querySelectorAll and friends. There's even an entire
| website dedicated to catering to exactly that
| transition[0]. I don't think anyone defending jQuery is
| doing so out of a sense of hubris towards outdated
| knowledge, but rather because it ironically is more
| lightweight than a lot of the modern SPA craze, while still
| being more ergonomic than vanilla JS.
|
| To try to shoehorn this back into the compiler analogy,
| modern frameworks would be like the advanced, complex and
| opaque compiler, and the grey beard is the guy that
| understands how stuff like HTML streaming and font download
| prioritization and hidden classes affect performance,
| whereas the team lead is analogous to the run-of-the-mill
| bootcamp grad that knows how to use the framework-du-jour
| but is way out of their depth if venturing outside the
| comfort of the framework and into the depths of those
| advanced topics.
|
| And I think the gov.uk use case here might actually be an
| outlier in the sense that it actually considers performance
| of an already tight codebase, whereas a lot of jQuery
| deprecation efforts bring with them heavier alternatives in
| the name of maintainability or developer productivity or
| hiring or whatever. To be clear, many of these concerns are
| quite valid, but it seems a bit disingenuous to create a
| false dichotomy between understanding of low level concerns
| vs concerns about SDLC management. They aren't mutually
| exclusive.
|
| [0] https://youmightnotneedjquery.com/
| niccl wrote:
| upvoted because this is a really good example of how to
| respond to criticism
| narag wrote:
| I'm curious: what's replaced Query? I guess it's not a
| single library, but a set of frameworks...
| zelphirkalt wrote:
| Plain JavaScript replaced it. jQuery provided useful
| things at its time, indeed, but JS has been somewhat
| improved at least and learned the tricks, even improved
| upon them. JS is still somewhat ugly, but I will give it
| at least that much. Now one does not really need jQuery
| any longer for most things, which were done with it. I
| personally find plain JS API and fetch to be cleaner than
| jQuery stuff even. People still use jQuery it out of
| habbit or, because it would be a lot of work to get rid
| of it everywhere.
| namdnay wrote:
| Do you see a lot of age discrimination it tech?
|
| What I have seen is awkward situations where you have two
| developers of roughly equal competence. One happens to be 45
| and the other 28. Fine, nobody would care about that. Except
| that due to automatic annual raises, job switches, seniority
| bumps etc, the 45 year old developer is paid twice as much as
| the junior.
|
| The rational response to this would be to say to align the
| two salaries (probably somewhere in the middle), but
| obviously the older one is never going to accept that - we
| all expect our salaries to "ratchet" upwards. So we end up
| with the irrational response, which is to sideline/kick-out
| the old expensive developer
| Barrin92 wrote:
| >Do you see a lot of age discrimination it tech?
|
| Yep, especially culturally rather than financially. Almost
| everywhere I've worked there was the implicit assumption
| that engineers graduate out of coding jobs into management
| roles. In a lot of places there's the idea that focusing on
| writing software is some sort of career dead-end for older
| people which is a shame for anyone who just likes coding. I
| think it's widely perceived as a young person's job for no
| good reason.
|
| And on the business side it's also pretty blatant. IIRC
| founders in their 40s are statistically most successful.
| Yet prominent people in the industry still openly fetishize
| youth.
| vkou wrote:
| If the 45-year old developer has been with the firm for 15
| years, they may have roughly equal competence in writing
| code, but unless they spent the past decade with their eyes
| and ears closed, the 45-year old should have vastly more
| institutional knowledge.
|
| Seniority bumps, x-weeks-vacation-after-y-years-of-service
| reward that intangible.
| lanstin wrote:
| Tho institutional knowledge can cut both ways - being
| indignant rather than resigned about the problems, and
| trying to fix things without knowing why all the prior
| attempts failed, and even being friendly to people that
| are politically outcast, are all great. Even just
| bringing novel solutions from outside industries or
| organizations to bear on problems is useful (tho
| experience is also a common cause for having a variety of
| solutions in ones tool box).
| prohobo wrote:
| Really? I see 40+ people as diversity hires for the most
| part. They're there so no one can say the company is
| ageist. The "good" devs become managers or magically
| disappear. Magically as in they get banished to some other
| realm I've never been able to see.
|
| That, to me, says there's plenty of ageism.
|
| If it was as simple as "they ask for too much", then
| someone would snap them out of it and we'd see plenty of
| older devs at software companies. Maybe less than younger
| devs, but plenty anyway.
|
| Honestly, I'd prefer if there were more older engineers to
| show the younger ones how dumb they are. Maybe better at
| building dynamic frontends, but dumber. That kind of
| seniority is sorely missing in software engineering, and it
| would drive standards upwards rather than downwards as they
| currently are.
|
| I'm currently in between, and wish I had more mentorship.
| bcrosby95 wrote:
| I don't know if we're just exceptionally lucky, but my
| friend group - the vast majority of which are still doing
| coding/sysadmin/devopsy stuff - are in our 40s and we
| have all had no problem finding employment.
|
| I think a major factor is that the field just exploded so
| much over the past 20 years. Statistically, people over
| 40 are going to be in the minority.
|
| I also do think a lot of startups maybe aren't the best
| place for older people. My brain wastes a lot of cycles
| on edge cases I've learned to identify from experience,
| that don't matter if you just need to slop some shit out
| the door ASAP.
| namdnay wrote:
| > The "good" devs become managers or magically disappear.
| Magically as in they get banished to some other realm
| I've never been able to see.
|
| I agree with you here - the question is why? I don't
| think it's because we're discriminated against for being
| old, I think it's because in 99% of cases (we can't all
| be donald knuth), our cost grows faster than our skills.
| So we either move to management/business (where
| experience matters more and it's much harder to quantify
| productivity), or we become "the overpaid one".
|
| > If it was as simple as "they ask for too much", then
| someone would snap them out of it and we'd see plenty of
| older devs at software companies
|
| But they wouldn't snap out of it. (a) in most countries
| you can't demote people, (b) it's very hard
| psychologically to accept being paid less for the same
| job
|
| > more older engineers to show the younger ones how dumb
| they are.
|
| I'm talking about 45+ vs 30 years olds here, not 30 vs
| 23.
| armchairhacker wrote:
| I sympathize with older devs, my dad is an older software
| dev.
|
| But you kind of do have to be old in order to have outdated
| knowledge: nobody young is going to learn assembly tricks
| which worked on MIPS and other past architectures. Older devs
| and companies not constantly learning new things and updating
| to best practices is a real phenomenon.
|
| On the other hand, anecdotally most older developers actually
| do keep up to date with the latest best practices. And there
| are lots of decades-old frameworks which aren't obsolete:
| lots of people greenfield projects with C++ and Spring Boot
| and .NET, and unless I'm mistaken the C ABI and system calls
| haven't changed much over the past ~40 years. So it's not
| like being old automatically means or even really suggests
| you're going to use worse, outdated techniques.
| markdown wrote:
| > but you kind of do have to be old in order to have
| outdated knowledge.
|
| Not in the frontend dev space. I once left it for 2 years.
| when i came back it was a whole new world
| threatofrain wrote:
| Bootcamps such as Hack Reactor (purchased by Galvanize)
| have curriculum which is basically outdated by 10 years, so
| you're going to have graduates using var, anonymous self-
| executing functions as modules that mutate the global
| scope, and libraries like jQuery and bluebird.
|
| If any student leaves that program with a modern
| perspective of web dev (such as using Redux or even RTK),
| it will be due to their own personal grit.
|
| C'est la vie.
| seattle_spring wrote:
| This is totally wrong. I hired a couple devs from Hack
| Reactor years ago and they had tons of lessons based on
| React and the ecosystem around it.
| threatofrain wrote:
| Your information might not reflect the online-only
| program, which is now the only choice. My information is
| from two sequential cohorts of students who are yet to
| graduate. Also, if you know what to Google for, then you
| can see how the curriculum has updated over time. Some
| students do this to cheat, and they can do so precisely
| because the curriculum is largely frozen in time.
|
| Hack Reactor has made Redux completely optional and so
| almost nobody choose it for their projects. This may have
| been in response to transitioning to an online-only
| program. If students understand anything on the "React
| ecosystem" including even Redux, it is due to their own
| personal ambition. If you see Redux explicitly listed in
| their curriculum, do not be confused.
|
| If you see students with Next.js, RTK, or any other
| framework or library from the React ecosystem on their
| portfolio, that is due to their own grit.
| fallingknife wrote:
| Can't speak for Hack Reactor, but your generalization of
| "bootcamps like" is wrong. Went to a bootcamp in 2016 and
| was doing React/Redux on the front end.
| threatofrain wrote:
| > Bootcamps such as Hack Reactor (purchased by Galvanize)
|
| No, this generalization is quite correct. If you went to
| a bootcamp which was not _such as_ Hack Reactor, then
| perhaps you may wish to promote the program by name and
| discuss your experience there.
| CryptoBanker wrote:
| I went to Fullstack Academy in 2017 and React and Redux
| were both part of the core curriculum
| giobox wrote:
| > But you kind of do have to be old in order to have
| outdated knowledge
|
| I'm not so sure. Google and StackOverflow are chock full of
| outdated (sometimes dangerous!) advice and knowledge on
| just about any tech subject, which hurts the young as much
| as the old.
|
| I've seen just as many outdated suggestions from junior
| devs repeating the first thing they found on google as I
| have older devs with stale knowledge. I'd probably argue
| the former has been a larger problem, honestly.
| eyko wrote:
| I'm nearing 40 and I've seen a bit of both. By far the best
| teams I've worked in had a healthy mixture of experienced
| developers and younger ones, although I'd say the main
| catalyst was a mentoring mentality where everyone, young
| and old, was encouraged to share their experiences
| (especially the bad ones) in an attempt to
| brainstorm/crowdsource an improvement to the status quo.
|
| I've also seen the opposite of what you'd expect: a young
| startup with a very young team that functioned on outdated
| practices and tools. My first contact with their codebase
| was a shock to the system - a mishmash of competing coding
| styles and conventions, barely any of them a best practice,
| much of it not very idiomatic, an alarming lack of
| consistency. The choice of tools, libraries and frameworks
| was (by startup standards) definitely not best in class,
| and where good choices had been made, the joy was short
| lived by realisation that they were on old versions, or not
| using their tooling properly.
|
| But, anecdotes aside, there's a point that generally gets
| overlooked. Best practices and good developer experience
| are the result of intentional choices, often in retrospect.
| The only way to come up with best practices or to improve
| DX is through experience -- especially poor experiences. I
| mean, who would've thought that experience was an asset.
| edoloughlin wrote:
| >> But to me, they are like the old grey beard who didn't
| update his knowledge as the times changed.
|
| > Maybe it's just me but with all the rampant age
| discrimination nowadays in tech, I really don't like to see
| the continued propagation of this stereotype.
|
| I would agree. If you last a long time in tech, you're more
| than the sum of the libraries you've learned.
| Beltalowda wrote:
| > I think of this story whenever I see jQuery popup on Hacker
| News. There is always a strong contingent of devs who swear by
| this library. But to me, they are like the old grey beard who
| didn't update his knowledge as the times changed. At one time
| jQuery allowed them to be the hero and "Get Things Done" faster
| than their competition. But times have changed.
|
| Whenever I want to use "vanilla JS" I use jQuery, because I
| find the DOM and various other JS APIs quite annoying to work
| with and jQuery makes things a lot smoother. There are some
| other, slightly smaller, libraries too, but they offer little
| advantages, are often unmaintained, and many people at least
| kind-of knows jQuery.
|
| Bombastic absolute statements about "greybeards" being "out of
| touch" etc. is basically why I tend to avoid the JavaScript
| frontend community by the way, and also why I moved towards
| backend rather than frontend. I'm too old to deal with people
| who think there is _One True Way(tm)_ to do things and that
| everyone who disagrees is a blubbering idiot (not that FE JS
| have a monopoly on this by any means, but it 's far more common
| there).
| dagaci wrote:
| Yes as a "greybeard" i noted first that the headline
| performance gain was 10% & 11% this for a team given far more
| time and resources to optimize for their goal than most teams
| or individuals dev. I raised an eyebrow at that
|
| However devs seeking employment should always be prepared to
| play up to what is trending vs what is appropriate.
| DeathArrow wrote:
| I rather not write 10 lines of Vanilla JS when I can write a
| line using jQuery. And I do prefer jQuery-style syntax for
| manipulating the DOM.
| smrtinsert wrote:
| Exactly, I don't know why people have to pit jQuery against
| the current generation of ui or vdoms etc. Just because you
| have a car doesn't mean a bike doesn't have its uses.
|
| These threads are completely ridiculous.
| atoav wrote:
| As somwone who constantly replaces jquey with vanilla js the
| difference is more like two lines of jquery against 3 lines
| of vannila js.
|
| One line more. But you have one dependency less, which is
| quite beneficial
| pseudosavant wrote:
| Update: fixed formatting
|
| A lot of times the jQuery syntax is easier to understand
| (IMO).
|
| Remove element exmample:
|
| jQuery API: $('.element').remove()
|
| DOM API: document.querySelector('.element')
| .parentNode.removeChild(document.querySelector('.element'))
|
| or if you want to introduce another variable just to remove
| the element: const child =
| document.querySelector('.element');
| child.parentNode.removeChild(child);
|
| Create element example:
|
| jQuery API: const fooElement = $('<div
| class="foo" style="display: none">')
|
| DOM API: const fooElement =
| document.createElement('div');
| fooElement.classList.add('foo');
| fooElement.setAttribute('style', 'display: none');
|
| I know which ones I'd rather write and read.
| mikojan wrote:
| Or you could just do
| document.querySelector('.element').remove()
| egeozcan wrote:
| HTMLElement.prototype.remove exists everywhere except IE:
|
| https://developer.mozilla.org/en-
| US/docs/Web/API/Element/rem...
|
| Also for element creation:
|
| Object.assign(document.createElement("div"), { class:
| "foo", style: "display:none" });
|
| I mean, you normally abstract these things with a helper
| fn or two, without importing the whole jQuery anyway.
| wvenable wrote:
| > I mean, you normally abstract these things with a
| helper fn or two, without importing the whole jQuery
| anyway.
|
| Add enough helper functions are you're at jQuery anyway.
| Looking at the jQuery source code, it manages a lot of
| edge cases that I don't really have time to figure out on
| my own.
|
| The DOM API isn't really designed that well for human
| consumption.
|
| https://developer.mozilla.org/en-
| US/docs/Web/API/Node/nodeTy...
| egeozcan wrote:
| You need to write a _lot_ of helpers to come close to
| jQuery. Also edge cases aren 't that big of a deal now
| that IE is near it's EOL.
| wvenable wrote:
| I'm not talking about browser edge cases, I'm talking
| about API edge cases. The DOM API is not very human-
| friendly.
| ratww wrote:
| _> Add enough helper functions are you 're at jQuery
| anyway._
|
| I really hate these exaggerations. jQuery is, last I
| checked, over 200k unminified. Anyone writing enough
| helper functions to get to a fraction of that is already
| a pathological case.
| wvenable wrote:
| Browsing the source of jQuery and I don't find it bloated
| but I find a lot of knowledge in there that a naive user
| the DOM API would most likely know about.
|
| It's kind of like how you can comparing languages using
| simple example code isn't relevant because proper code
| with full error handling and edge case handling can be
| very different from a naive example.
| cogman10 wrote:
| IE 11 hits it's EOL next month. So, really probably not a
| whole lot of reason not to just pull the trigger and
| inform everyone that complains of this fact.
| jokethrowaway wrote:
| jQuery emerged from the market and it's pretty close to
| what developers wanted to express.
|
| JS is design by a committee full of people afraid to come
| out as "not-as-kind" and completely detached from reality.
|
| True, doing some of the things which were half an hour on
| stack overflow or 1 line of jQuery became a couple of lines
| of vanilla JS but the API is still pretty awful.
|
| Think about XHR > fetch vs $.get or $.post
|
| I agree, I'll try to use vanilla JS and google something
| when I need to ship some code - but for hacking around I'll
| just bring in jQuery and write 1-liners at blazing speed.
| pseudosavant wrote:
| Absolutely. I stopped using actual jQuery a while ago in
| favor of a light (78 loc) wrapper around the native DOM that
| mostly uses the jQuery API. jQuery has a really well thought
| out fluent API.
|
| https://gist.github.com/pseudosavant/b86eedd9960ade958d49447.
| ..
| TOMDM wrote:
| I agree with your sentiment in total, but I'd also add, for
| every out of touch programmer still swearing by JQuery, there
| are 5 recruiters that demand proficiency in it that other
| programmers feel they need to appease.
|
| I think the most diplomatic way of distinguishing the two types
| of programmers is just to ask why they like JQuery.
|
| "Because it helps me ship faster" may be a bit out of touch.
|
| "Because it's a required competency in working with some code
| bases" are probably the latter.
| arbitrage wrote:
| jQuery is dead, Netcraft confirms it?
|
| "Nobody goes to that restaurant anymore, it's too busy."
| lesgobrandon wrote:
| jokethrowaway wrote:
| Your examples (while beautiful) are fairly different from each
| other.
|
| The assembly tricks got obsoleted because they're not needed
| anymore - we simply don't program in that hardware anymore.
|
| jQuery still works fine to this day. It's just that engineers
| don't like it anymore. The same will happen to React in a few
| years.
|
| I wouldn't hire a jQuery developer for working in a cushy
| company with their millions and their React codebases - React
| knowledge is actually one of the things we test for (and,
| unexplainably, one of the few exceptions we'll allow to avoid
| knowing about algorithms and time complexity).
|
| If I had to build something with my money on the line, I'd
| definitely pick the jQuery veteran.
| robalfonso wrote:
| As a counterpoint, I had a similar conversation with a report
| of mine about jQuery. He said it was not necessary and you
| could just use vanilla js.
|
| I said while yes that's true as a dev if I told you I needed
| you to implement a new payment provider for billing would you
| tightly and directly align with who we used or abstract it away
| via some wrapper so that if we ever had to change it wouldn't
| be difficult? Of course everyone builds abstractions so you
| aren't stuck with a single provider because it's crazy not to.
|
| I see jQuery as that abstraction. At the end of the day each
| browser is an api implementer and while they've come so far,
| that doesn't mean the situation is stable and we'll never see
| implementation fracture again. It of course doesn't have to be
| jQuery but any direct implementation of JS seems to have that
| risk which is easily mitigated by wrapping the basic
| functionality. I don't know why you wouldn't choose to do it.
| Gare wrote:
| What? Web APIs are one of the most stable APIs in existence.
| "Don't break the web" is taken very seriously.
| damon_c wrote:
| The context for this belief has only existed for about 10
| years now.
| plorkyeran wrote:
| The phrase "Don't break the web" is a bit newer, but it's
| basically the sentiment that lead to WHATWG forming 18
| years ago, and one of the big defining goals of HTML5 was
| to set a foundation for expanding the web platform in a
| backwards-compatible way. HTML5 has been out for about as
| long as the invention of the web to HTML5.
| 8ytecoder wrote:
| More like half of that. I did web development in 2012. We
| couldn't have done it without jQuery.
| anotheracctfo wrote:
| Yeah that's what I'm afraid of. IE 5.5 diverging from
| Netscape 4 again.
|
| Are we really betting on Microsoft, Google, and Apple not
| getting into a feature fight again?
| dudus wrote:
| They do get into feature fights often. See Apple not
| adopting PWAs, or IE focusing on blocking 3rd party
| cookies. But the parts that are covered by jQuery are
| solved and agreed upon.
| lalaland1125 wrote:
| The problem is that most of the "abstractions" provided by
| jQuery are no longer abstractions and can frequently be
| replaced with simple alternatives that are directly provided
| by browser APIs that have extremely wide support.
|
| https://youmightnotneedjquery.com/ is a handy illustration of
| this.
| jefftk wrote:
| That site was very helpful when it first came out, but now
| that most of us don't even need to support IE11 it's
| assumption that you at least want to support IE10 is very
| stale.
| evilotto wrote:
| I fail to see how replacing 1 line of jQuery with 10 lines
| of plain js is simple. Sure, you don't use those 10 lines
| all over the place, you write a function ... but then
| aren't you just recreating jQuery?
| franciscop wrote:
| Yes, and if you continue long enough you end up with one
| of the many jQuery alternatives, like mine:
|
| https://umbrellajs.com/
| shadofx wrote:
| Yes but only the parts you need, which means better
| performance and job security.
| azangru wrote:
| jQuery was a useful abstraction when browsers had
| inconsistent and clunky apis.
|
| Modern browsers have apis that are about as convenient as
| jQuery's, are standard across browsers, consistent with the
| language, and guaranteed to outlive jQuery the library. Aside
| from dot-chaining in a monadic sort of way, jQuery offers no
| benefit to the developer, while costing about 30kB of
| javascript.
| parineum wrote:
| > guaranteed to outlive jQuery the library
|
| There's absolutely no reason to believe that considering
| those APIs add new features independently of each other. A
| library like jQuery can serve as an intermediary if browser
| A implements new feature X that is possible in browser B
| but through excessive (and slow) DOM manipulation.
|
| jQuery can act as a bridge between the time browser A's
| implementation and browser B's.
| MrJohz wrote:
| There's not much added to the browser that's particularly
| independent (i.e browser A adds it with browser B having
| no plan to implement it at all), and when there are APIs
| that are perhaps newer and not widespread yet, it's
| usually easier to pull in a specific polyfill (or
| ponyfill) for that specific feature, rather than rely on
| one library that's trying to cover everything. Especially
| as those libraries tend to mimic the API as it is
| expected to be standardised, rather than implementing a
| distinct API as jQuery does.
|
| In practice, I'd much rather use the native APIs to do
| things in the browser than a wrapper library, because I
| find abstraction from these wrappers tends to get in the
| way as often as it helps. With modern JavaScript (for-of,
| the spread operator, far more array functions), it's
| usually only one or two lines more code to do things the
| native way, and I find it saves me a lot of complexity
| down the line.
| gkbrk wrote:
| > There's not much added to the browser that's
| particularly independent (i.e browser A adds it with
| browser B having no plan to implement it at all)
|
| You haven't seen the privacy nightmare APIs Google is
| trying to push on web "standards"? The only other two
| browsers, Firefox and Safari, are not going to implement
| most of them in the foreseeable future.
| mg wrote:
| Javascript has become so nice, now that browsers support modules.
|
| I use a module "dqs.js" for all my query needs. It contains only
| these two lines: export const dqs =
| document.querySelector.bind(document); export const dqsA
| = document.querySelectorAll.bind(document);
|
| And use it like this: import { dqsA } from
| 'lib/dqs.js'; for (const rabbit of dqsA('#rabbits
| .green')) { ... do something with all green rabbits
| ... }
| joeframbach wrote:
| I add the parent element to mine const $ =
| (selector, parent = document) =>
| parent.querySelector(selector); const $$ = (selector,
| parent = document) => parent.querySelectorAll(selector);
| abdusco wrote:
| This is the way. In addition to `$` and `$$`, I usually have
| `$h` for creating elements: /** *
| @param {string} name * @param
| {HTMLElement.prototype} props * @param
| {Array<HTMLElement|string>} children * @return
| HTMLElement */ function $h(name = 'div',
| props = {}, children = []) { const el =
| document.createElement(name); Object.assign(el,
| props); el.append(...children);
| return el; }
| err4nt wrote:
| There is .forEach() on NodeLists, so you can do stuff like this
| in every browser, no lib, no helper functions needed:
| document.querySelectorAll('a').forEach(tag => { //
| operate on tag })
| dhritzkiv wrote:
| alternatively, if you need to use anything other than
| `forEach` for working on the list, you can turn the NodeList
| into an array using the array spread syntax (equivalent to
| using Array.from) e.g.
| [...document.querySelectorAll('a')] .filter(node =>
| node.getAttribute("data-foo") === "bar")
| megous wrote:
| Not everyone wants to be so wasteful.
| dhritzkiv wrote:
| what do you mean by "wasteful"?
| megous wrote:
| Creating an array, populating it with however many
| elements just to be able to call some methods and
| destroying it immediately afterwards. And doing it all
| over the app, just because it's syntactically convenient.
| (all while you already have an iterable collection in the
| form of NodeList)
| hombre_fatal wrote:
| It is a bit weird to consume an iterator into an array
| when a NodeList is already iterable.
|
| Not sure why it caught on.
| megous wrote:
| I see it a lot with other iterables, too. People may like
| one liners and functional style more than a procedural
| `for (of)` construct, so they use
| `[...iterable].any_array_function(...)` everywhere,
| except when foced not to by async code :).
|
| Might also have something to do with Redux and immutable
| patterns. (the use of spread operator in general)
| d1sxeyes wrote:
| I think it's just for brevity, rather than because a helper
| is _needed_. OP listed the entire source code of their module
| in their comment.
| moffkalast wrote:
| Brevity is cool, but that's kind of like naming all your
| variables one letter chars for brevity.
|
| This is something every web dev will instantly know what it
| does: document.querySelectorAll('#rabbit
| .green').forEach(tag => { })
|
| Whereas this is something nobody knows what the fuck it is
| because it's completely non-standard. for
| (const rabbit of dqsA('#rabbits .green')) { }
|
| And get what, 10 characters less in one row? Basically
| nothing.
| hombre_fatal wrote:
| for/of vs .forEach isn't the issue here. Frankly I almost
| always use for/of because it's implemented for all
| iterators and I prefer being outside of a function (e.g.
| I can use await).
|
| All they did was alias `dqsA`. If anything, it's the fn
| name that could be better.
| gfody wrote:
| how's browser support for something like
| "a:has(img[src$='.gif'])" though?
| err4nt wrote:
| For more advanced queries than standard CSS selectors
| provide, XPath is also supported by every browser and
| available via document.evaluate() (which is not eval() by
| the way)
|
| https://developer.mozilla.org/en-
| US/docs/Web/XPath/Introduct...
| zeven7 wrote:
| You probably shouldn't be making that query, unless you're
| doing something specific like web scraping and don't have
| control over the content of the site.
| cptskippy wrote:
| That's always been the blessing and curse with JQuery. It
| allows you to easily filter objects but it doesn't
| encourage efficiency.
|
| A lot of people don't have control over the content of
| their site in enterprise situations. If you're stuck
| using an old framework or CMS you could be beholden to
| someone else. And at the same time there's a lot of devs
| who dgaf and just ship what works.
| gfody wrote:
| you could be using it already w/jquery though and if you
| just switched to the native selector it would stop
| working everywhere but safari.
|
| "#some_combo:has(option:selected[value=..]) + .." seems
| like a reasonable way to conditionally target something
| to me, is it terribly worse than some other way?
| zeven7 wrote:
| > is it terribly worse than some other way?
|
| Yeah, it's fragile and will easily lead to bugs when
| someone changes the markup without realizing it's going
| to break some crazy selector in another part of the code.
|
| It would make a lot more sense to just add a class to the
| element you're trying to select.
| gfody wrote:
| it's a conditional select, you're saying just add code to
| add/remove a class to the target - of course, but that
| defeats the point of wanting a conditional selector in
| the first place
| zeven7 wrote:
| The point of selecting an element is to do something with
| it. How does selecting it by class defeat the point?
|
| Look, if you need this for some one off thing and you've
| determined it's the best way to do it in this special
| case, it's not hard to create a function that will find
| the element you want.
|
| It's not a good argument for using jQuery IMO, because if
| you're doing this regularly there's probably a better way
| to do it.
|
| But coming soon(tm) you will be able to do even this with
| `document.querySelector`.
|
| Edit: I didn't pay close attention to your second
| example. I was speaking mostly related to the a:has
| example before. Your second example seems to be something
| that would be desired more in CSS than JS, and I don't
| think it's unreasonable to do that in CSS. If you need to
| do it in JS you can workaround browser limitations just
| fine by writing more than one line of code to do the
| selection and test the condition.
| easrng wrote:
| :has doesn't exist but you can do
| [].map.call(document.querySelectorAll("a
| img[src$='.gif']"), (e)=>e.closest("a")).filter(e=>e)
| robertoandred wrote:
| :has certainly does exist, but only in Safari. Hopefully
| Chrome and Firefox will catch up soon.
| SemanticStrengh wrote:
| The bashing of jQuery comes from junior devs. Of course a VDOM is
| clearer, more productive (and less performant) however most
| webapps with a minimum of logic have many legitimate uses of
| native dom/jquery _in addition_ to the VDOM. And the interaction
| is perfectly safe as long as you do native DOM in the right
| lifecycle method (mounted). jQuery is a pleasure to use and give
| us a lot of power /expressivity. More generally this vague of
| juniors devs (e.g. CSS-in-JS lobby) are becoming less and less
| familiar with the concept of CSS/DOM selectors, despite their
| awesomeness and uniformity both for DOM operations, styling
| operations and integration tests operations (cypress) BTW a
| little known fact is that jQuery is not just sugar and cross-
| browser consistentcy, in fact it push the boundaries of what is
| possible vs native CSS, see e.g. the reverse direction paradigm
| shift of https://api.jquery.com/has-selector/ Although its true
| that augmenting jQuery with a batcher for performance doesn't
| seems currently possible? https://github.com/wilsonpage/fastdom
| zinekeller wrote:
| I do think that your complaint, while applicable to a lot of
| websites, is not specifically applicable to GOV.UK. They do
| everything to use plain HTML (and if possible no Javascript at
| all, but there are certain pages where Javascript is an
| absolute must like interactive maps), and they aren't using
| React but instead a special framework that is designed to
| minimise Javascript even to novice developers. Basically
| they've replaced jQuery with plain Javascript since that some
| older devices they're supporting (which jQuery is a better
| solution as it's bug-tested and optimised as much as possible)
| is dead.
| [deleted]
| capableweb wrote:
| Not sure you read the submission, but the move away from jQuery
| was not to move to anything "virtual DOM"/React/similar but
| rather that the functions provided by jQuery now have
| vanilla/"native" alternatives.
| SemanticStrengh wrote:
| /username checks out :)
| hinkley wrote:
| The main value I found with jQuery was that the more your CSS
| selectors and jQuery selectors diverged, the more it felt like
| you were doing the same work twice.
|
| Now I'm curious what the CSS looks like for devs who have only
| ever known VDOM frameworks. Regular CSS can be pretty bad,
| particularly on a mature project. Are we talking dumpster fire
| or three ring circus here?
| SemanticStrengh wrote:
| I think the css quality of newer projects has significantly
| regressed.
| hinkley wrote:
| When jQuery was in its prime, stubbornella was a fixture of
| youtube playlists. One of the feathers in her cap was
| cutting yahoo's CSS in half, which resonated with a lot of
| us. CSS has been problematic for a long time.
|
| I used to hate code generators because the code quality was
| always so bad that if a midlevel or senior dev was writing
| code like that I'd be talking to our manager about firing
| them, and for a junior dev we'd be talking about more
| intensive mentoring or even a PIP.
|
| Once Sass introduced SCSS, that was the first code
| generator I ever met that actually impressed me, and Less
| is very close. The default CSS out of it looked very much
| like the sort of CSS you would expect from a project after
| someone had already gone through and cleaned up all of the
| cliched failure modes for medium sized projects. It felt
| like having a fast forward button. Still one of the fastest
| 'sells' for me, and I do quite a lot of technology
| selection for projects.
|
| Not that it's perfect. Poorly written mixins/functions can
| generate way more CSS per call than is necessary, and I
| have a team of overbooked people that I need to sell on
| prioritizing fixing this sort of thing and I just can't
| find the bandwidth because there are always 2 more pressing
| issues I need to talk to them about. I can't squeeze blood
| from stone, and I can only ask for personal favors about as
| frequently as I can grant them, modulo any turnover - which
| has become a problem. Turns out if I take a shine to you,
| you're also really easy to hire somewhere else.
| kriz9 wrote:
| Most developers don't seem to understand that jQuery was not just
| a wrapper for browser compatability. Yes, we do have all that
| nice functionality in a modern browser nowadays but compared to
| jQuery it just not as elegant. jQuery still has a place.
| paco3346 wrote:
| And that place is? Not saying I disagree, this just feels like
| an incomplete thought.
| kriz9 wrote:
| You are correct sir. I was trying to keep myself going on a
| rant. I think if you want to avoid large frameworks/build
| pipelines and the ugly mess that Web APIs are then jQuery
| fits perfectly. I have tried and failed many times writing
| vanilla JS for some smaller projects but always end up over
| budget and with code ending up looking like a worse version
| of jQuery. Only if you have large enough visitor count and
| team then using vanilla API makes practical sense because you
| might save couple GBs of web traffic and that is nice to see.
| ChrisArchitect wrote:
| Right, to be clear this isn't breaking news but a blog post about
| a story from March
|
| https://news.ycombinator.com/item?id=30868760
| muglug wrote:
| The gains aren't massive -- certainly not something any human
| using the site would notice (about 20ms faster to render pages
| for the average mobile phone user).
|
| Still good to remove unncessary dependencies, though.
| Cthulhu_ wrote:
| Not on an individual scale, no, but when you consider the
| millions of visits and views they get per year it adds up from
| a global / zoomed out point of view.
|
| I'm sure with some math you can make a calculation on how much
| bandwidth and energy was saved with this One Clever Trick.
| SemanticStrengh wrote:
| They are missing on a lot of expert backed Jquery
| optimizations e.g.
| https://github.com/jquery/jquery/issues/3143
| londons_explore wrote:
| They'd be even better to just use the browsers CSS
| animation support...
|
| gov.uk doesn't have many animations anyway.
| londons_explore wrote:
| A government is the perfect place to look at this "zoomed
| out" view.
|
| Your citizens an average rate of pay of Y per year. Some of
| time they save by getting stuff done on a government website
| will be put into getting more economic work done. If the
| citizens do 10 billion pageviews of gov.uk per year, and you
| shave off 20ms, thats 27 human-years of work per year. So it
| is certainly worth making this optimization, even if it takes
| a few people a few _months_ to figure out how to remove
| jquery.
| legitster wrote:
| I love jQuery like I love a roll of duct tape. I'll use it for
| anything and everything but I also don't mind if a commercial jet
| would not like to showcase it.
| chiefalchemist wrote:
| It's a tool. If you need a hammer but use a screwdriver, then
| that's a problem.
|
| jQuery made animation and such easy to do. But now we have CSS
| for that.
|
| There's no value in chest pounding and proclaiming "Tool X is
| stupid. No one should use Tool X." Given the diversity of the
| internet, it's naive to believe you understand every possible use
| case. Just let it go already.
| exabrial wrote:
| I've noticed this a trend lately. Why does everyone suddenly hate
| jQuery?
|
| Instead, I've noticed everyone re-inventing the wheel. Take
| Bootstrap5, which "eliminated jquery and we wrote our own!" but
| now, it is much much larger. Then your next framework does the
| same, and so on, now we're downloading 1mb of javascript files
| just to display grandma's 160 byte tweet.
| Waterluvian wrote:
| Nobody "hates" jQuery. Code and libraries are a liability. All
| people care about is getting their job done and going home.
|
| This "trend" has been like 5+ years in the making. And it's
| simply a result of jQuery becoming less necessary as core
| JavaScript in the browser gains features.
| tdy_err wrote:
| One particular reason is that it can be hard to avoid or get
| rid of, if you are using third party UI modules- even "modern"
| ones, intended for use in a framework like Angular, might use
| jQuery as a dependency.
|
| This is also problematic if your project has a dependency tree
| that needs multiple (incompatible) versions of jQuery.
| spicybright wrote:
| Eh. Everyone hates on jQuery, but for most informational sites
| that's really all you need for basic interaction.
|
| Speed really isn't bad, and it's so straightforward that it's
| hard to mis-use at this point.
|
| I seem to have way more issues with newer frameworks/SPA if I'm
| not using chrome with no extensions.
|
| Makes me nervous dealing with important stuff like banking or
| government sites.
| jaywalk wrote:
| For basic interaction, you don't need anything but vanilla JS.
| Browsers have come a long way since the days where jQuery was
| almost necessary to deal with all of the minor differences/bugs
| in various browsers.
| criddell wrote:
| You can do quite a bit without Javascript too. A lot of
| websites don't need much more than simple menus.
|
| Steve Gibson's site is an example:
|
| https://www.grc.com/default.htm
| andybak wrote:
| It's a much nicer syntax and has a ton of useful helpers.
|
| Vanilla js for similar things just looks like someone has
| waved the ugly stick at it.
|
| There are sound arguments against jQuery but the "you can
| just use vanilla" is the least convincing.
| jaywalk wrote:
| Not having to load yet another JS library on your page if
| you don't really need it is a pretty good argument, I'd
| say.
| andybak wrote:
| Yes. You'll note that I already anticipated that in my
| original point. I was very specific in how I worded it
| for good reason.
| dgb23 wrote:
| To add: jQuery is a pretty huge library for what it does.
| Talking both bundle size and execution speed. Not that
| the latter is noticeable for most cases, but it's still a
| cost. The question is: What for?
|
| The primary use case for it has been cross browser
| compatibility plus a bit of sugar. The former is _gone_
| and the latter is easily replaced with a few lines of JS.
| Then there is an ecosystem of libraries and components
| around it. Many of them have ditched jQuery or have
| provided an API that doesn't require it.
| rtpg wrote:
| 30kb minified and gzipped! Less than most hero images.
| It's a nice API for simple stuff.
|
| I think if you strip out the AJAX support it can get
| extremely tiny.
| Rumudiez wrote:
| 30kb gzipped is still 10x larger than Preact for
| reference
| SemanticStrengh wrote:
| that doesn't make it an issue in any way, it's not a
| numbers competition unless you have a 56K
| Smaug123 wrote:
| One of the explicit goals of gov.uk is to be maximally
| accessible, and that includes for people accessing the
| Internet on a potato or who have a metered connection.
| dgb23 wrote:
| It adds tens of milliseconds to just downloading on a
| fast connection, plus it has to be parsed before what
| ever you need it to do will be functional.
|
| To compare, just roughly:
|
| For roughly the same size you can get
| declarative/reactive rendering with React, or an
| optimized FP standard library with ClojureScript, or data
| driven visualizations with d3 (roughly 2x the size).
|
| For a tenth of the size you can get stuff like htmx, or a
| json validation library (avj), or like someone said
| Preact (React alternative).
|
| But for jQuery, you're paying that for basically nothing
| the browser APIs don't already provide. It was a godsend
| 10y ago, but with legacy browsers finally fading out, the
| last one being ie11, you really don't _need_ it anymore.
| lowwave wrote:
| or use https://axios-http.com/ for ajax stuff
| mejutoco wrote:
| This is not the case anymore but I remember when Angular
| was including a version of jQuery, and having methods
| like "doSthAsInJquery" (paraphrasing) in Angular, and I
| could still hear everyday that Angular didn't have the
| overhead of including jQuery.
|
| I wish we could have standardized in the Linq-like API of
| jQuery.
| sofixa wrote:
| OP's argument is that jQuery is all you need for basic
| use cases, so that'd be the only JS library loaded.
| kijin wrote:
| Except we've become so used to loading multiple megabytes
| of JS even on a simple blog post, that a 30KB library
| probably won't make a noticeable difference. Insofar as
| file size is concerned, I'd much rather pull in jQuery
| than some random npm package that depends on god-knows-
| how-many other random packages.
|
| Even GOV.UK, an incredibly lean website by today's
| standards, only noticed a 10% difference in their
| benchmarks.
| Deukhoofd wrote:
| A 10% performance gain is quite a big deal, I wouldn't
| just shove it under the table like that.
| Dudeman112 wrote:
| Like every % comparison, it depends on the baseline.
|
| Cue all the people going on about big O for parts of the
| code that are indistinguishable from noise in actual
| benchmarks.
| [deleted]
| spicybright wrote:
| I'll admit I'm a bit out of practice with the state of
| vanilla JS, but it seems like you'll be re-inventing the
| wheel for simple stuff.
|
| Like a collapsible section that's lightly animated.
|
| I worry too about people not considering accessibility.
|
| A lot of my bugs day to day is not being able to tab into
| things like hover menus or being able to activate buttons
| because someone forgot to consider correct event callbacks.
|
| Maybe it's different now, but using a jQuery makes it more
| likely the code will cover cases like that.
| Cthulhu_ wrote:
| In 2020, a collapsible section is a matter of adding /
| removing a classname and a CSS animation; there's a few
| ways to do so, using jQuery is one, but you don't need
| thousands of lines of a JS library (network bandwidth + JS
| interpretation) to achieve that.
| have_faith wrote:
| Can CSS transitions and animations handle animating to
| auto height/widths yet?
| d1sxeyes wrote:
| I don't think so. One trick I've used to good effect is
| setting an high max-height, then translating by 100% and
| removing pointer events.
| flatcakes wrote:
| I feel like this solution feels subtly "wrong" if you're
| animating, because that high max height will be
| arbitrarily far away from where you'd normally want to
| animate to. Doubly so for easing out.
| d1sxeyes wrote:
| Yeah it's a bit weird, but haven't found a better trick
| yet.
| chipsa wrote:
| Collapsible section? https://developer.mozilla.org/en-
| US/docs/Web/HTML/Element/de...
|
| There's some CSS transition stuff you can add to that to
| make it lightly animated: https://css-tricks.com/how-to-
| animate-the-details-element/
|
| Yeah, jQuery might make some things easier, but when
| possible, using native HTML elements makes things even
| easier,
| nhinck wrote:
| Hmm, I would agree that you can do 95%+ of stuff jQuery
| used to be used for in vanilla js or html/css in a nicer
| way but animated collapsible divs still require a stupid
| amount of js to achieve.
| [deleted]
| iCarrot wrote:
| Animated collapsible div can be done with 0 line of JS.
|
| https://code-boxx.com/expand-collapse-div-css-only/
| onion2k wrote:
| _I worry too about people not considering accessibility._
|
| This isn't a complaint you can level at the gov.uk team.
| They're _obsessed_ with accessibility. Gov.uk is probably
| the best example of a well-designed, well-built, completely
| accessible website on the whole internet.
| spicybright wrote:
| I meant more for anyone building a website.
| psnehanshu wrote:
| Whilst *.GOV.IN (India) is the worst.
| pacaro wrote:
| You bring up some interesting concerns. It's a good example
| of why there isn't a one size fits all answer. The UK gov
| site has high standards for these kind of things so will do
| it right anyway, but for a small shop leaning on a
| framework makes a lot of sense
| mitchdoogle wrote:
| If you've been using jQuery for years, know it, and can
| write a good amount of code without looking at a reference,
| then by all means, keep using it. It's not going anywhere
| anytime soon.
| seydor wrote:
| i see a lot of const $ =
| document.querySelector.bind(document);
| jenscow wrote:
| Right. However, jQuery isn't just for cross-browser.
|
| It provides a clean API for manipulating the DOM, as this
| site demonstrates (which is ironic):
| https://youmightnotneedjquery.com/
|
| Personally, for simple sites, I aim for vanilla JS but use
| jQuery (cash, actually) where it makes sense - such as
| working on collections of elements.
| SemanticStrengh wrote:
| for real its superior ergonomy is painfully obvious
| duxup wrote:
| I will always think fondly of jQuery. It did a great job for
| what it was intended, saved a lot of time. jQuery's time has
| passed, and that's ok too.
| [deleted]
| philliphaydon wrote:
| I loved jquery back in the day. It made web development
| bearable in a time when it was a clusterfuck.
|
| I think a lot of people owe a lot of thanks to jquery.
|
| But in 2022 vanilla javascript is all you really need.
| dsego wrote:
| jQuery still offers a much nicer experience. The built-in dom
| apis are neither very elegant nor ergonomic.
| // jquery $(selector).on('click', fn)
| // vanilla js
| document.querySelectorAll(selector).forEach(el =>
| el.addEventListener('click', fn) )
| fleddr wrote:
| Fully agree, and your example is still relatively simple.
| Method chaining in jQuery allows for extremely expressive
| one-liners that would require a huge amount of boilerplate
| in vanilla JS.
| louissan wrote:
| or delegate...?
|
| document.addEventListener('click', function(e){ var t =
| e.target; if(t.closest('.foo') &&
| t.nodeName.toLowerCase() === 'button'){
| e.preventDefault(); // do stuff here }
| else if(t.closest('.bar') && t.nodeName.toLowerCase() ===
| 'a' && t.classList.contains('here')){
| e.preventDefault(); // do smth else here }
|
| }, false);
|
| one listener to rule them all...?
|
| elegant enough and once you get used to it...
|
| .closest can be pollyfilled too..
| Cthulhu_ wrote:
| Is it worth adding the library (download size + script
| parsing & execution) for that though?
|
| At the very least there are some jQuery alternatives that
| are modular, smaller, and have less backwards compatibility
| like iirc zepto.
| dageshi wrote:
| Yup. Because the size of the library and the execution
| time just isn't that big of a deal, it's something people
| seem to obsess over but it doesn't really matter much.
| bennyp101 wrote:
| It takes 1min to write a wrapper around that, though.
|
| Having said that, for the sake of 25kb - if you use more
| than a handful of features you might as well just include
| it.
| mkoryak wrote:
| That's the problem.
|
| It takes only 1 minute to write a wrapper, so you will
| write one, and I'll write one, and your dog will write
| one.
| tiborsaas wrote:
| Then compare it with dog's and pick the simpler one :) I
| don't know what's wrong with a utils.js file that only
| has what you need in a way that fits your project
| exactly. Woof.
| DeathArrow wrote:
| But writing that utils.js will end up rewriting jQuery.
| tiborsaas wrote:
| I've seen this argument a lot, but based on my experience
| it will take ~5 small functions to get what I need and
| how I need.
|
| It's even easier if you copy paste from here:
| https://anguscroll.com/just/
| JJMcJ wrote:
| If that is literally the only wrapper you need, sure go
| ahead.
|
| But most of the time, you find you need another wrapper,
| and then another, and the next thing you know you have
| most of jQuery, just not as uniform or as well tested.
|
| I've seen this with database ORMs also.
| muhehe wrote:
| Web development is still a clusterfuck.
| DeathArrow wrote:
| I agree if you are talking about frontend. Backend is still
| pleasant. And even frontend becomes bearable thanks to
| HTMX.
| phkahler wrote:
| >> Eh. Everyone hates on jQuery, but for most informational
| sites that's really all you need for basic interaction.
|
| The point seems to be that you don't even need _that_ any more,
| so just get rid of it. Not sure why people latch onto cruft so
| much and defend its continued use.
|
| On the performance side they cite 10 percent improvement, which
| doesn't sound like much to a lot of people. But remember that
| performance gains/regressions get compounded. Maybe there are 8
| things that each eat 10 percent - you either start improving
| _somewhere_ or you just refuse to even try. If I could improve
| 10 percent while removing a dependency I 'd be all over that.
| cies wrote:
| > Not sure why people latch onto cruft so much and defend its
| continued use.
|
| A characteristic of communities with lots of people that do
| not have a theoretical background. JS, PHP, jQuery, some
| parts of Ruby/Python -- they defend it with their life, and I
| argue it's because the rest of the world looks very scary to
| them.
| AdrianB1 wrote:
| For AJAX, jQuery is still simpler than vanilla JS.
| barbecue_sauce wrote:
| Even fetch?
| moreira wrote:
| Definitely not Fetch. I don't believe anyone can argue
| that Fetch is more complicated.
|
| I think this really seems to stem from a "I'm only used
| to jQuery, anything else is a big mental effort to learn
| and I'd rather stick with what I know".
|
| I get it. Vanilla JS, if you're not used to it, is scary.
| But if you're advocating for jQuery "for simple
| interactions", and assuming it's simpler than vanilla JS,
| at some point you should ask yourself if you're just
| letting your skills stagnate, and staying stuck in the
| past. You owe it to yourself to update your skillset. If
| you decide you still need jQuery (e.g. maybe you need a
| plugin/library that requires jQuery), then fine. But at
| least you'll be making an informed decision, not a FUD-
| driven one.
| epolanski wrote:
| As someone kinda obsessed with handcrafting all of its
| software without any dependency and is highly used to dom
| operations, I can't but thing you're making it much more
| of a deal than it is.
|
| Handcrafting JavaScript applications without jQuery is
| possible, the real question though is: is it convenient
| if you like and find productive using jQuery? Here's a
| fact: you can always remove jQuery later when the product
| is mature and standards understood and there is time
| budget for it.
| easrng wrote:
| I mean `await $.ajax("https://jquery.com/")` is shorter
| than `await(await fetch("https://jquery.com/")).text()`
| nojs wrote:
| If you just want "basic interaction" without any framework
| complexity, alpine.js is way better than jquery. It's extremely
| simple and does the basic data binding stuff that jquery lacks.
| nightski wrote:
| I don't use jQuery any more but I do use lodash because I
| appreciate that the methods are built to handle nulls. Methods
| like .forEach in the browser were for some odd reason chosen to
| be instance methods so you always have to check for
| null/undefined before calling them.
| seydor wrote:
| Pity
| jcuenod wrote:
| Everyone here seems to be talking about how great jQuery was for
| DOM interaction and that's true. But the other thing that was
| life changing about it was how easy it was to make ajax requests!
| mindcrime wrote:
| _But the other thing that was life changing about it was how
| easy it was to make ajax requests!_
|
| What's the "modern" alternative to jQuery in that regard? I
| don't do much JS development, but if I needed to make an AJAX
| request today, my first instinct would probably still be to use
| jQuery.
| osrec wrote:
| Google the Fetch API.
| psnehanshu wrote:
| Fetch API is fine, but Axios[0] gives you a lot more
| flexibility. The best thing I like is the request/response
| interceptor. You can do cool stuff like injecting tokens
| into outgoing requests, retry failed requests, centralized
| error handling. Because of adapters, it works both in
| browser environment as well as Node.js environment. Heck,
| you can even mock requests in your unit tests using a mock
| adapter[1] to avoid making actual HTTP requests. Sure there
| is a cost for adding dependency when you can just use
| native APIs, but in this case, I think it's worth it.
|
| [0] https://axios-http.com/
|
| [1] https://www.npmjs.com/package/axios-mock-adapter
| mindcrime wrote:
| Thanks!
| [deleted]
| ishjoh wrote:
| fetch: https://developer.mozilla.org/en-US/docs/Web/API/fetch
| err4nt wrote:
| jQuery never did make the migration to being packaged/delivered
| as a modern (i.e. post-2015) JavaScript module. This precludes it
| from being used in a lot of modern JavaScript workflows.
|
| No matter what the library itself provides, to use it you have to
| go back to working like how developers in 2014 and before used to
| work with JavaScript, so that's a very real consideration that
| the "I still like to use jQuery" folks never mention. Are they
| writing all of their code as pre-2015 'classic' JavasScript as
| well?
___________________________________________________________________
(page generated 2022-05-19 23:00 UTC)