The lovely world of enterprise software.
By using Word as a viewer the email is broken right on delivery and users now complain "The email you sent me is broken!"
At least it's still better than Notes
IE, and now Edge, is a different business unit.
Not inexplicable at all. NIH doesn't only apply at corporate boundaries.
jQuery's strength is the CSS selector based approach, where CSS, HTML and JS all "speak the same language", but it also its greatest weakness, your JS code gets too tightly coupled with the structure of the HTML, which makes it harder to refactor.
Good code management can solve this, like using a class or class like construct (e.g. jQuery plugin) to create independent components. But jQuery misses a lot of features to be a truly component based solution. jQuery UI widget is somewhat closer but still missing features like other component based solution has, e.g. no built in template library.
One of the most common things in JS is to attach listeners to HTML elements, however the most common way when doing so in jQuery is that you have a bunch of selectors and then some listener code, but that type of statements is not self explanatory, you have no function name to describe what it is doing or any other context. You see all these registrations of event listeners scattered across the project. What do they do? Are they in use? Hard to tell because searching your source code for a CSS selector is very difficult. That is why jQuery based projects usually have tons of leftover code from the last refactor, no one dares to touch it.
Many component based libraries out there lets you register a method name on the HTML element directly. Much better. If you can't find the method/function name referenced in your code, you can delete it.
It is true that you can add event listeners inline on your HTML element, but that is not how jQeury is usually written, because it is selector based.
Just last month I decided to toss a quite arbitrary `=>` in my javascript (I still write `function (args) { code }`), and shipped it. Immediately got a _TON_ of user complaints.
Turns out, we sent a link in a newsletter, and most folks were reading those in Outlook, and that evidently just opens links internally, and that is still IE11. We don't ordinarily support IE11, but given that this is a specific info page shown there, for this we make an exception, and... => doesn't even work there.
Thus, another year goes by, and another year where I am 100% convinced it is totally not worth my time or effort to investigate newer options.
I'm honestly confused about why jQuery is considered 'bad'.
It's a dependency - yeah, 30k or so. This complaint (that it adds load time) boggles my mind; in this day and age of 10MB+ load pages, and the choice is to complain about a 30k library? Some javascript-library variant of the Total Perspective Vortex may be warranted to try to make sense of this.
A more interactive (as in, between server and browser), more stateful integrated model? Oh, yeah, totally, I can see that, but that 'formula' surely isn't the go-to strategy for every web page out there, right? Most of the pages I write work perfectly well via a 'server generates data, server throws it through a template and sends it to browser, client downloads jquery and some javascript for that page which adds interactive elements', and wouldn't be any 'nicer' if it was a much more javascript-native fully state-shared amalgamation. When I do need that live-updating stateful interaction model, sure, don't need jQuery. But that 30k is the least of my worries if that happens.