Cash: A small jQuery alternative for modern browsers

Original Article ↗ Hacker News Discussion ↗

A lightweight jQuery alternative called Cash prompts a broader look at how much DOM and AJAX abstraction modern sites still need now that browsers support querySelector, Fetch and other native APIs. Commenters weigh the trade-offs between convenience and payload size, with some favoring tiny utilities or hand-rolled helpers and others arguing that larger frameworks or in-house abstractions are justified for maintainability and cross‑browser quirks. The thread also touches on HTTP semantics (like GET bodies), event handling inconsistencies, and long‑term risks of depending on both large third‑party frameworks and homegrown mini-frameworks.

Scope and purpose of Cash

  • Cash is positioned as a small, DOM-centric jQuery alternative for “modern” browsers (explicitly IE11+).
  • It omits AJAX and effects to keep size down; partial/custom builds can trim it further.
  • Some see it as a solid 80/20 solution when you just want selectors, chaining, and small utilities without full jQuery.

AJAX, Fetch, and HTTP semantics

  • Several commenters argue that fetch is now “good enough” for most AJAX needs and simpler than $.ajax.
  • Others highlight real limitations of fetch:
    • No request body on GET, despite HTTP allowing it in principle.
    • No native progress events and weaker support for some advanced features.
  • There’s debate about GET-with-body: technically permitted in HTTP/1.1, but long-standing proxy/caching behavior makes it unreliable; more recent specs strongly discourage it, and a new QUERY method is mentioned as the intended fix.
  • Libraries like Axios, SuperAgent, or a thin XHR wrapper are suggested for “full” AJAX features.

Size, performance, and dependency trade-offs

  • Skeptics question rewriting jQuery to save ~50–80KB when many sites ship megabytes of JavaScript.
  • Others push back:
    • Some teams target <50KB total JS, or ship web UIs in tiny embedded ROMs.
    • Page-speed and Lighthouse scores drive business decisions; extra HTTP requests and external CDNs can hurt scores.
    • Small dependencies accumulate; caring about size at every layer is seen as good discipline.

Native DOM APIs and micro-helpers

  • Many say modern DOM APIs (e.g., querySelector(All), closest, forEach on NodeList) make jQuery mostly unnecessary.
  • Common patterns: binding document.querySelector(All) to short aliases ($, dqs, dqsA), sometimes wrapping results in Array.from for array methods.
  • There’s debate over whether such two-line helpers should be separate modules or just copied into each project.
  • Some warn against mutating prototypes (e.g., making NodeList inherit from Array) due to “prototype pollution.”

Role of jQuery and alternatives

  • jQuery is still valued for:
    • Automatic list handling and chainable operations.
    • “Fire and forget” behavior when selectors match no elements.
  • Others would prefer stricter behavior (errors on empty selections) and show how to patch jQuery to enforce this.
  • Opinions diverge: some say “the jQuery era is over” and DOM should be derived from state via frameworks; others happily combine jQuery with tools like htmx and small PHP frameworks or use other micro-libs (Umbrella, alpine.js, Preact, etc.) for lightweight apps.