aboutsummaryrefslogtreecommitdiff
path: root/content/posts/2022-09-11-jqueries.md
blob: 343753ae8d537114af65727607911687801a6eab (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
---
slug: jqueries
title: "jQueries"
date: "2022-09-11T07:23:10-04:00"
draft: true
tables:
  sizes:
    # table columns (required)
    cols:
      - id: "build"
        name: "Build"
        tip: "jQuery build."
      - id: "minified_size"
        name: "Minified"
        tip: "Build size, minified, in kilobytes."
        align: "right"
      - id: "compressed_size"
        name: "Compressed"
        tip: "Build size, minified and compressed, in kilobytes."
        align: "right"

    # table rows (required)
    rows:
      - build: "jQuery 3.6.1 Full"
        minified_size: "90 kB"
        compressed_size: "30 kB"
      - build: "jQuery 3.6.1 Slim"
        minified_size: "73 kB"
        compressed_size: "25 kB"
---
Several of my coworkers do not like [jQuery][].  Some common arguments
against it are:

1. Modern [DOM][] APIs and cross-browser compatibility are now good
   enough that [you don't need jQuery][not needed].
2. [jQuery][] is bloated.
3. [jQuery][] is the source of security problems.

My personal opinion is a bit more nuanced.  I agree that [jQuery][]
isn't *strictly necessary* for new web applications and that the modern
[DOM][] API is usually sufficient.

But [if it ain't broke, don't fix it][fix].  It often takes less effort
to maintain [jQuery][] in an existing application than it does to remove
[jQuery][] or replace it with something else.

Also, consistency is important.  Given a team of developers working on
several applications, relying on consistent dependencies, idioms, and
formatting between disparate code bases is often more important than
using the latest technology or the best technique, because the
consistency reduces the [cognitive load][] for the entire team.

I would prefer using [jQuery][] for new applications this scenario too,
provided that [jQuery][] and other dependencies are kept up to date.

Even as someone who [cares about page size][shrinkage] and [literally
measures JavaScript size by byte][js-byte-size], I don't find the
argument that [jQuery][] is bloated particularly compelling.  The sizes
of [jQuery 3.6.1][] are as follows:

{{< table "sizes" >}}

At these sizes jQuery is relatively small compared to a single bitmap
image

[jquery]: https://jquery.com/
  "jQuery"
[not needed]: https://youmightnotneedjquery.com/
  "You might not need jQuery."
[dom]: https://en.wikipedia.org/wiki/Document_Object_Model
  "Document Object Model"
[fix]: https://idioms.thefreedictionary.com/if+it+ain%27t+broke%2c+don%27t+fix+it
  "If something is performing or functioning well enough, there's no need to change or interfere with it as you may introduce new problems as a result."
[cognitive load]: https://en.wikipedia.org/wiki/Cognitive_load
  "Measure of perceived mental effort."
[jquery 3.6.1]: https://blog.jquery.com/2022/08/26/jquery-3-6-1-maintenance-release/
  "jQuery 3.6.1, the current version of jQuery as of this writing."
[shrinkage]: {{< relref "posts/2022-01-28-media-shrinkage.md" >}}
  "Post about compressing media assets and enabling compression in Apache."
[js-byte-size]: https://git.pablotron.org/sites/pablotron.org/plain/themes/hugo-pt2021/assets/script.js
  "Comment about byte count from unminified JavaScript for this site."
[javascript]: https://en.wikipedia.org/wiki/JavaScript
  "JavaScript programming language."