Vanilla JS vs jQuery: what is the difference for modern web projects?

Vanilla JS calls native browser APIs directly and returns real Promises, while jQuery wraps DOM and network calls in its own $() object and Deferred system.

Both can manipulate the same page, but the object models differ enough to change how code reads, chains, and fits into a modern build pipeline.

When does jQuery's API still save time?

For short, self-contained scripts written by different people over time, jQuery's chaining keeps a sequence of DOM operations in one readable line without intermediate variables. That matters in codebases made of many small, loosely related snippets rather than one cohesive application, where setting up modules and a build step for each snippet adds more overhead than it removes.

When does the native approach pay off?

Once a project already uses async/await and ES modules, native code keeps the same idioms throughout instead of mixing a Promise-based fetch with a Deferred-based $.ajax call. Tree-shaking also only works on code split into modules, so a bundler can drop unused native functions in a way it cannot drop unused parts of a single jQuery object.

Which approach fits a given project?

A project built around modern tooling and async/await keeps its architecture more consistent by skipping jQuery's separate Promise-like interface entirely. A project made up of many independent scripts added over years, without a shared module system, often keeps jQuery's chaining because rewriting each one in native syntax is a larger job than the difference in outcome justifies.