26 ms·

Gov.uk drops jQuery from their front end

444 points by feross 4y ago

bob1029 4y ago
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.
llIIllIIllIIl 4y ago
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?
- topspin 4y ago
  Can't answer your question. I'd like to second the question however; our contemporary tools usually generate far larger and totally obscured components that marshal dependences from every corner of the internet using fabulously complex and fragile tooling. I've done work using jQuery and several of the modern stacks and maintain much of it today. When I have to dive back into this work the jQuery stuff is usually painless. The Angular/React/etc. stuff causes an internal groan; even weeks after 'finishing' one of the latter some significant fraction of the tools and libraries are obsolete and the first thing you find yourself squandering time on is nursing it all into shape again. Years later you're also faced with either clinging to the old idioms that have been supplanted by 'better' ones or reworking a bunch of stuff. jQuery has never inflicted this problem on me. Also, I don't really buy the "you might not need it" argument. jQuery reduces cognitive load by normalizing most of what you need to do to a vanishingly small and less error prone API. There is real value in that. jQuery delivers far more than just backfilling. While I have a hard time imagining a client in 2022 that is so anemic that the cost of jQuery actually matters, it appears gov.uk has convinced itself that the removal of jQuery is a triumph for their use case. I've never had to deal with that use case. I doubt most people have or ever will. And so I take all of this with an appropriate grain of salt; if it's a choice between productivity and shaving a few points in blocking percentiles I'll take the former every day and twice on Sunday and the people that pay me are grateful that I do. I learned about htmx in the comments of this discussion. I'm definitely going to give that a spin at some point. Thank you HN.
chiefalchemist 4y ago
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.
ngcc_hk 4y ago
It is not about update but dependence of unknown or uncontrolled chain. It is a start to look at what you are really using and reduce the surface of risk.
euske 4y ago
Aside from jQuery, I'm just amazed at how good the gov.uk is. They're comprehensive and accessible. Isn't this the pinnacle of government websites? I only wish that our government site (Japan) is half as good.
- Apofis 4y ago
  Does Japan still require Internet Explorer? It's a very weird country webdev-wise.
- viraptor 4y ago
  Its infrastructure is also largely public: https://github.com/alphagov/govuk-puppet https://github.com/alphagov/govuk-puppet
bkyan 4y ago
Is there a vanilla javascript replacement for jQuery's animate() functionality?
xtalx 4y ago
My take on this is, if you are writing enough JS in your app that the “terseness” of jQuery seems appealing you maybe shouldn’t be writing jQuery or vanilla (unless you’ve built a really nice framework/library specifically for your app/use case/whatever). My point is (I think) jQuery was/is best suited for “sprinkles” of js. These days with “sprinkles” of js jQuery isn’t worth the download/parse cost. If you have more than “sprinkles” use Svelte or Preact or Solid or React or Vue or Mithril or whatever. SPRINKLES
cosmotic 4y ago
If they don't like sending those 30KB for jQuery, why are they sending 60KB of pretty plain-looking fonts?
mediumsmart 4y ago
So back in 2007 people where ok with loading this gargantuan 30kb library? That is almost as much as one nice retina ready banner webp in 2022.
- TAKEMYMONEY 4y ago
  It was about half that size in 2007
velcrovan 4y ago
Good
spicybright 4y ago
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 4y ago
  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.
  - andybak 4y ago
    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 4y ago
      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.
      - sofixa 4y ago
        OP's argument is that jQuery is all you need for basic use cases, so that'd be the only JS library loaded.
      - kijin 4y ago
        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.
seydor 4y ago
Pity
tomc1985 4y ago
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 4y ago
  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_ 4y ago
  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-experiences-with-concurrent-mode-and-suspense.html https://reactjs.org/blog/2019/11/06/building-great-user-expe...) etc.
  - tomc1985 4y ago
    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 4y ago
duxup 4y ago
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.
tbranyen 4y ago
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 4y ago
  I believe it's kind of sad that in the days of 2 TB USB sticks that 32kb matter.
  - tbranyen 4y ago
    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.
    - ThunderSizzle 4y ago
      Then, on the other side of things, every fast food android app is ~60 MB. Even Five Guy's is 45 MB. Why? They all do the same thing, and none of the data that is used is included in the app, and all the logic might as well be the same. And then on top of each restaurant app, you also have Uber Eats, Door Dash, etc., which again, basically so the same thing. There should really be a single fast food app, I select my restaurant, and it shows me the options (which is basically google maps with mobile websites that would actually work). There's no reason for every restaurant and delivery service to have their own app.
    - tomschwiha 4y ago
      Removing large chunks of unused code feels refreshing, that is true.
muglug 4y ago
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_ 4y ago
  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 4y ago
    They are missing on a lot of expert backed Jquery optimizations e.g. https://github.com/jquery/jquery/issues/3143 https://github.com/jquery/jquery/issues/3143
    - londons_explore 4y ago
      They'd be even better to just use the browsers CSS animation support... gov.uk doesn't have many animations anyway.
  - londons_explore 4y ago
    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.
jjice 4y ago
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).
- dgb23 4y ago
  I agree. Also reminds me of CSS resets, the goal of modern-normalize is to make itself obsolete.
- SemanticStrengh 4y ago
  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
  - threatofrain 4y ago
    Ad hoc manipulation of the DOM contradicts the philosophy of a lot of frameworks, as that is state which is unaccounted for.
  - pastor_bob 4y ago
    Just replace that one liner with a 15 liner.
    - LNSY 4y ago
      document.querySelector('html') And for React: https://javascript.info/custom-elements https://javascript.info/custom-elements
      - mejutoco 4y ago
        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.
mg 4y ago
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 ... }
- err4nt 4y ago
  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 })
  - d1sxeyes 4y ago
    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 4y ago
      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 4y ago
        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.
zendaven 4y ago
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();
- mrtksn 4y ago
  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.
- bern4444 4y ago
  Even easier: export const hideElementById = (elementId) => { document.getElementById(`#${elementId}`).style.display = 'none' }; Or perhaps export const toggleElementById = (elementId) => { const element = document.getElementById(`#${elementId}`); const newDisplayValue = element.style.display === 'none' ? 'block' : 'none'; element.style.display = newDisplayValue; };
- SadWebDeveloper 4y ago
  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 4y ago
    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 4y ago
seydor 4y ago
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
- zhte415 4y ago
  I'm using HTMX with Flask through revamping a site previously with server side page rendering + AJAX. It is excellent. Some of the more contrived AJAX to update parts of a page is being replaced by HTMX, some page loads are being replaced. It is working very smoothly and at a vastly higher speed (also, incremental) than redoing everything with React, the other option tabled. I'll certainly be using it more.
SemanticStrengh 4y ago
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/ 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 https://github.com/wilsonpage/fastdom
- zinekeller 4y ago
  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 4y ago
  [deleted]
- capableweb 4y ago
  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.
  - 4y ago
egberts1 4y ago
- deleted 4y ago
  [deleted]
- shadofx 4y ago
  CSS is too much as well, client XSLT to XHTML is good enough for any reasonable website.
  - egberts1 4y ago
    Agreed. So far it’s -4 karma for me. There must be a grain of truth in there … somewhere. Nah, just an inconvenient truth.
snowl 4y ago
There's almost no point talking about javascript on HN with the amount of anti JS & anti framework rhetoric that happens here
- jenscow 4y ago
  The 'H' is for Herd
- systemvoltage 4y ago
  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 4y ago
    Maybe not design but I would say it is a bastion of usability.
    - systemvoltage 4y ago
      I prefer USWDS for usability: https://designsystem.digital.gov/ 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 4y ago
        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.
AlwaysRock 4y ago
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 4y ago
  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?
err4nt 4y ago
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?
deleted 4y ago
[deleted]
d1sxeyes 4y ago
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.
SemanticStrengh 4y ago
> 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 4y ago
  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 4y ago
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!
qwerty456127 4y ago
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.
- Gigachad 4y ago
  The future will probably be that anything complicated enough to require frameworks like React will eventually move to web assembly, then you are free to use a newer language or compiler which strips out legacy mistakes and old sites can keep shipping their binary which will always work. Already a few of the complex web apps have become webasm.
- cies 4y ago
  > 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 4y ago
    AFAIK Elm can not be considered "a better JavaScript" because it not only is fundamentally different, it also is not fully self-sufficient - in many cases you have to resort to JavaScript pieces while engineering an Elm app.
    - 4y ago
kriz9 4y ago
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 4y ago
  And that place is? Not saying I disagree, this just feels like an incomplete thought.
  - kriz9 4y ago
    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 4y ago
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 https://news.ycombinator.com/item?id=30868760
legitster 4y ago
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.
lelandfe 4y ago
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"
- TAKEMYMONEY 4y ago
  Stuck out to me too, but the article is wrong, they didn't "reduce blocking time" by 11%, they reduced how long it takes to complete "JS Long Tasks" by 11% (63ms). They do claim a "reduction in JS size" on all JS apps "between 31% and 49%."
  - lelandfe 4y ago
    Ahh, nice. Thanks. Believe it or not, "long tasks" is a meaningful term: https://developer.mozilla.org/en-US/docs/Web/API/Long_Tasks_API https://developer.mozilla.org/en-US/docs/Web/API/Long_Tasks_.... They're what Time to Interactive measures.
- petepete 4y ago
  There's only a small amount of JavaScript used on GOV.UK and everything degrades gracefully.
- hinkley 4y ago
  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.
happyopossum 4y ago
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.
- zamadatix 4y ago
  "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).
- acdha 4y ago
  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.
reggieband 4y ago
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.
- Beltalowda 4y ago
  > 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™ 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).
nightski 4y ago
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.
ufo 4y ago
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?
jcuenod 4y ago
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 4y ago
  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 4y ago
    Google the Fetch API.
    - mindcrime 4y ago
      Thanks!
    - psnehanshu 4y ago
      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/ https://axios-http.com/ [1] https://www.npmjs.com/package/axios-mock-adapter https://www.npmjs.com/package/axios-mock-adapter
  - deleted 4y ago
    [deleted]
  - ishjoh 4y ago
    fetch: https://developer.mozilla.org/en-US/docs/Web/API/fetch https://developer.mozilla.org/en-US/docs/Web/API/fetch
divbzero 4y ago
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/ https://youmightnotneedjquery.com/
ei8ths 4y ago
I love jQuery. I've been trying to do vanilla when it makes sense.
DeathArrow 4y ago
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(); ?
- MaxLeiter 4y ago
  Why not use fetch?
- divbzero 4y ago
  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 })
- jefftk 4y ago
  fetch('/my/url').then(response => response.json()).then(data => handle it)
overgard 4y ago
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 4y ago
jQuery has the best API design ever, I hope Javascript can support that natively one days.
JJMcJ 4y ago
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.
account-5 4y ago
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.
- jenscow 4y ago
  > 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 4y ago
  [deleted]
- dbrueck 4y ago
  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.
- hu3 4y ago
  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 https://kit.svelte.dev or https://www.solidjs.com https://www.solidjs.com
exabrial 4y ago
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 4y ago
  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 4y ago
  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.
mkrishnan 4y ago
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.

444 points by feross 4y ago

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.

llIIllIIllIIl 4y ago

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?

topspin 4y ago
Can't answer your question. I'd like to second the question however; our contemporary tools usually generate far larger and totally obscured components that marshal dependences from every corner of the internet using fabulously complex and fragile tooling. I've done work using jQuery and several of the modern stacks and maintain much of it today. When I have to dive back into this work the jQuery stuff is usually painless. The Angular/React/etc. stuff causes an internal groan; even weeks after 'finishing' one of the latter some significant fraction of the tools and libraries are obsolete and the first thing you find yourself squandering time on is nursing it all into shape again. Years later you're also faced with either clinging to the old idioms that have been supplanted by 'better' ones or reworking a bunch of stuff. jQuery has never inflicted this problem on me. Also, I don't really buy the "you might not need it" argument. jQuery reduces cognitive load by normalizing most of what you need to do to a vanishingly small and less error prone API. There is real value in that. jQuery delivers far more than just backfilling. While I have a hard time imagining a client in 2022 that is so anemic that the cost of jQuery actually matters, it appears gov.uk has convinced itself that the removal of jQuery is a triumph for their use case. I've never had to deal with that use case. I doubt most people have or ever will. And so I take all of this with an appropriate grain of salt; if it's a choice between productivity and shaving a few points in blocking percentiles I'll take the former every day and twice on Sunday and the people that pay me are grateful that I do. I learned about htmx in the comments of this discussion. I'm definitely going to give that a spin at some point. Thank you HN.

chiefalchemist 4y ago

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.

ngcc_hk 4y ago

It is not about update but dependence of unknown or uncontrolled chain. It is a start to look at what you are really using and reduce the surface of risk.

euske 4y ago

Aside from jQuery, I'm just amazed at how good the gov.uk is. They're comprehensive and accessible. Isn't this the pinnacle of government websites? I only wish that our government site (Japan) is half as good.

Apofis 4y ago
Does Japan still require Internet Explorer? It's a very weird country webdev-wise.
viraptor 4y ago
Its infrastructure is also largely public: https://github.com/alphagov/govuk-puppet https://github.com/alphagov/govuk-puppet

bkyan 4y ago

Is there a vanilla javascript replacement for jQuery's animate() functionality?

xtalx 4y ago

My take on this is, if you are writing enough JS in your app that the “terseness” of jQuery seems appealing you maybe shouldn’t be writing jQuery or vanilla (unless you’ve built a really nice framework/library specifically for your app/use case/whatever). My point is (I think) jQuery was/is best suited for “sprinkles” of js. These days with “sprinkles” of js jQuery isn’t worth the download/parse cost. If you have more than “sprinkles” use Svelte or Preact or Solid or React or Vue or Mithril or whatever. SPRINKLES

cosmotic 4y ago

If they don't like sending those 30KB for jQuery, why are they sending 60KB of pretty plain-looking fonts?

mediumsmart 4y ago

So back in 2007 people where ok with loading this gargantuan 30kb library? That is almost as much as one nice retina ready banner webp in 2022.

TAKEMYMONEY 4y ago
It was about half that size in 2007

velcrovan 4y ago

Good

spicybright 4y ago

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 4y ago
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.
- andybak 4y ago
  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 4y ago
    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.
    - sofixa 4y ago
      OP's argument is that jQuery is all you need for basic use cases, so that'd be the only JS library loaded.
    - kijin 4y ago
      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.

seydor 4y ago

Pity

tomc1985 4y ago

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 4y ago
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_ 4y ago
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-experiences-with-concurrent-mode-and-suspense.html https://reactjs.org/blog/2019/11/06/building-great-user-expe...) etc.
- tomc1985 4y ago
  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 4y ago

duxup 4y ago

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.

tbranyen 4y ago

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 4y ago
I believe it's kind of sad that in the days of 2 TB USB sticks that 32kb matter.
- tbranyen 4y ago
  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.
  - ThunderSizzle 4y ago
    Then, on the other side of things, every fast food android app is ~60 MB. Even Five Guy's is 45 MB. Why? They all do the same thing, and none of the data that is used is included in the app, and all the logic might as well be the same. And then on top of each restaurant app, you also have Uber Eats, Door Dash, etc., which again, basically so the same thing. There should really be a single fast food app, I select my restaurant, and it shows me the options (which is basically google maps with mobile websites that would actually work). There's no reason for every restaurant and delivery service to have their own app.
  - tomschwiha 4y ago
    Removing large chunks of unused code feels refreshing, that is true.

muglug 4y ago

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_ 4y ago
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 4y ago
  They are missing on a lot of expert backed Jquery optimizations e.g. https://github.com/jquery/jquery/issues/3143 https://github.com/jquery/jquery/issues/3143
  - londons_explore 4y ago
    They'd be even better to just use the browsers CSS animation support... gov.uk doesn't have many animations anyway.
- londons_explore 4y ago
  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.

jjice 4y ago

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).

dgb23 4y ago
I agree. Also reminds me of CSS resets, the goal of modern-normalize is to make itself obsolete.
SemanticStrengh 4y ago
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
- threatofrain 4y ago
  Ad hoc manipulation of the DOM contradicts the philosophy of a lot of frameworks, as that is state which is unaccounted for.
- pastor_bob 4y ago
  Just replace that one liner with a 15 liner.
  - LNSY 4y ago
    document.querySelector('html') And for React: https://javascript.info/custom-elements https://javascript.info/custom-elements
    - mejutoco 4y ago
      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.

mg 4y ago

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 ... }

err4nt 4y ago
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 })
- d1sxeyes 4y ago
  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 4y ago
    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 4y ago
      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.

zendaven 4y ago

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();

mrtksn 4y ago
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.
bern4444 4y ago
Even easier: export const hideElementById = (elementId) => { document.getElementById(`#${elementId}`).style.display = 'none' }; Or perhaps export const toggleElementById = (elementId) => { const element = document.getElementById(`#${elementId}`); const newDisplayValue = element.style.display === 'none' ? 'block' : 'none'; element.style.display = newDisplayValue; };
SadWebDeveloper 4y ago
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 4y ago
  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 4y ago

seydor 4y ago

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

zhte415 4y ago
I'm using HTMX with Flask through revamping a site previously with server side page rendering + AJAX. It is excellent. Some of the more contrived AJAX to update parts of a page is being replaced by HTMX, some page loads are being replaced. It is working very smoothly and at a vastly higher speed (also, incremental) than redoing everything with React, the other option tabled. I'll certainly be using it more.

SemanticStrengh 4y ago

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/ 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 https://github.com/wilsonpage/fastdom

zinekeller 4y ago
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 4y ago
[deleted]
capableweb 4y ago
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.
- 4y ago

egberts1 4y ago

deleted 4y ago
[deleted]
shadofx 4y ago
CSS is too much as well, client XSLT to XHTML is good enough for any reasonable website.
- egberts1 4y ago
  Agreed. So far it’s -4 karma for me. There must be a grain of truth in there … somewhere. Nah, just an inconvenient truth.

snowl 4y ago

There's almost no point talking about javascript on HN with the amount of anti JS & anti framework rhetoric that happens here

jenscow 4y ago
The 'H' is for Herd
systemvoltage 4y ago
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 4y ago
  Maybe not design but I would say it is a bastion of usability.
  - systemvoltage 4y ago
    I prefer USWDS for usability: https://designsystem.digital.gov/ 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 4y ago
      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.

AlwaysRock 4y ago

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 4y ago
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?

err4nt 4y ago

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?

deleted 4y ago

[deleted]

d1sxeyes 4y ago

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.

SemanticStrengh 4y ago

> 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 4y ago
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 4y ago

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!

qwerty456127 4y ago

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.

Gigachad 4y ago
The future will probably be that anything complicated enough to require frameworks like React will eventually move to web assembly, then you are free to use a newer language or compiler which strips out legacy mistakes and old sites can keep shipping their binary which will always work. Already a few of the complex web apps have become webasm.
cies 4y ago
> 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 4y ago
  AFAIK Elm can not be considered "a better JavaScript" because it not only is fundamentally different, it also is not fully self-sufficient - in many cases you have to resort to JavaScript pieces while engineering an Elm app.
  - 4y ago

kriz9 4y ago

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 4y ago
And that place is? Not saying I disagree, this just feels like an incomplete thought.
- kriz9 4y ago
  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 4y ago

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 https://news.ycombinator.com/item?id=30868760

legitster 4y ago

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.

lelandfe 4y ago

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"

TAKEMYMONEY 4y ago
Stuck out to me too, but the article is wrong, they didn't "reduce blocking time" by 11%, they reduced how long it takes to complete "JS Long Tasks" by 11% (63ms). They do claim a "reduction in JS size" on all JS apps "between 31% and 49%."
- lelandfe 4y ago
  Ahh, nice. Thanks. Believe it or not, "long tasks" is a meaningful term: https://developer.mozilla.org/en-US/docs/Web/API/Long_Tasks_API https://developer.mozilla.org/en-US/docs/Web/API/Long_Tasks_.... They're what Time to Interactive measures.
petepete 4y ago
There's only a small amount of JavaScript used on GOV.UK and everything degrades gracefully.
hinkley 4y ago
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.

happyopossum 4y ago

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.

zamadatix 4y ago
"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).
acdha 4y ago
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.

reggieband 4y ago

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.

Beltalowda 4y ago
> 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™ 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).

nightski 4y ago

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.

ufo 4y ago

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?

jcuenod 4y ago

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 4y ago
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 4y ago
  Google the Fetch API.
  - mindcrime 4y ago
    Thanks!
  - psnehanshu 4y ago
    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/ https://axios-http.com/ [1] https://www.npmjs.com/package/axios-mock-adapter https://www.npmjs.com/package/axios-mock-adapter
- deleted 4y ago
  [deleted]
- ishjoh 4y ago
  fetch: https://developer.mozilla.org/en-US/docs/Web/API/fetch https://developer.mozilla.org/en-US/docs/Web/API/fetch

divbzero 4y ago

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/ https://youmightnotneedjquery.com/

ei8ths 4y ago

I love jQuery. I've been trying to do vanilla when it makes sense.

DeathArrow 4y ago

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(); ?

MaxLeiter 4y ago
Why not use fetch?
divbzero 4y ago
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 })
jefftk 4y ago
fetch('/my/url').then(response => response.json()).then(data => handle it)

overgard 4y ago

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 4y ago

jQuery has the best API design ever, I hope Javascript can support that natively one days.

JJMcJ 4y ago

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.

account-5 4y ago

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.

jenscow 4y ago
> 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 4y ago
[deleted]
dbrueck 4y ago
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.
hu3 4y ago
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 https://kit.svelte.dev or https://www.solidjs.com https://www.solidjs.com

exabrial 4y ago

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 4y ago
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 4y ago
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.

mkrishnan 4y ago

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.