2017-05-21
We use jQuery and I've stopped feeling ashamed about it
I'll start with my tweets:
A confession: I have a web site that uses jQuery. An old version of jQuery, at that. It probably always will, because it works this way.
I could spend a bunch of time (as a non-JS-expert) to make my site use current native browser APIs instead. But there's no payoff for us.
I've completely given up feeling guilty about still using jQuery and not updating our jQuery versions. Our site is a tool, not a sculpture.
One thing that I've been reading for some time is that jQuery is mostly unnecessary these days. Apparently jQuery was created back when browsers were more incompatible and less capable; these days, modern browsers have changed both aspects and for garden variety DOM manipulation you now have well supported cross-browser native APIs. Increasingly, it seems that the nebulous 'best practices' of modern JavaScript web development are to avoid jQuery unless you have a strong reason to use it.
(Typical writing about this is eg here, here, here, or this blog entry by Laurie Voss that mentions it in passing (via). Running across Laurie Voss's blog entry is what pushed me into my tweets.)
Beyond the sin of still using jQuery at all in our web app, we're also still using an old version of jQuery (specifically jQuery 1.9.0, released in early 2013 and so now more than four years old). This whole issue has been nagging at me for a while and today I reached the point where I blurted out my tweets, which perhaps isn't the conclusion you might expect.
The reasons I've wound up here are straightforwardly pragmatic. As I mentioned, there is essentially no payoff for us in updating our web app to avoid jQuery or even to use a more recent version of jQuery. Our app is a small low-usage thing and we only use JavaScript for some small enhancements that are very likely to be undemanding even in 'inefficient' jQuery code; similarly, the extra jQuery download is unlikely to be significant. Improving our JavaScript may make things more proper and perhaps if I was starting from scratch today I wouldn't use jQuery, but there is no concrete benefit to us for doing anything to the app as long as it continues to work. As I tweeted, our app is a tool that people use, not a sculpture for them to admire. People who use the app care somewhat about how it looks, but they don't care what's under the surface.
Some people would modernize our JavaScript anyway, just because the current state nags at them and they care. Perhaps I once was such a person in the past, but today I'm definitely not. I don't care that much and I have better things to do with my time (both work time and spare time). So I'm done with letting this nag at me and I'm not going to make any excuses for it.
(Perhaps I should drop in the latest 1.x jQuery and test lightly to see if everything works, just in case there's some bug fix that matters to us that we're missing. But even that is hard to sell, partly because it's still a hassle.)
A 'null MX' is also useful for blocking forged senders from non-email domains
When I first considered the use of a 'null MX', I was only thinking of it as a way of blocking email to hosts that don't get email (I had a special case that made some dedicated spammer behavior unusually irritating). However, there is another useful case, and that's domains that don't send email but do get forged on spam.
A while back I wrote about a persistent phish spammer that consistently sends email using the forged sender email address of 'codewizard@approject.com'. As it happens approject.com seems to be a parked domain, with a 'this domain may be for sale' website and nothing else visible. If this is true, the owner of approject.com could cut off much of this forgery by publishing a suitable 'null MX' record in their DNS (especially now that it's an official standard, as I found out when doing research for this entry). Other owners of other parked domains could similarly cut off spam being forged in their names, and frankly there's a lot of it; spammers seem to love forging email as from domains like 'confirmation.com', 'verification.net', 'system.com', and so on.
(Some of those are not parked domains, mind you.)
Even without the new(-ish) null MX RFC, you can sort of get there today
for some sites through a suitable DMARC policy
and SPF records, but I think that probably requires more DNS fiddling
than a simple 'MX .' entry. Plus, it only applies to people who
actually use DMARC or SPF to reject message, which is not that many
people right now (partly because turning on DMARC or especially SPF
rejection has various often unpleasant side effects). The good news is
that using DMARC probably will insure that GMail and a few other big
places will reject the spammer email that is claiming to be from you.
(The more DNS fiddling is required, especially the more fiddling
that must contain the domain name or the like, the less likely it
is that owners of parked domains and similar things will go to the
bother. One attraction of 'MX .' is that it's completely generic.)
I don't know why this use for a null MX standard didn't occur to me back then. Probably I was too close to my specific little issue and not thinking generally. Spammers have certainly been abusing generic-word domains for advance fee fraud and phish spams for years.