Replacing jQuery Plugins with Vanilla JavaScript in an HTML Template

Why Removing jQuery from a Template Still Matters in 2025

jQuery 3.7 weighs roughly 87 KB minified and uncompressed. After gzip it is closer to 30 KB, but the browser still has to parse and compile the entire library on every cold load. On a mid-range Android device, that parse time sits between 80 and 120 milliseconds before a single line of your own code runs. For a Bootstrap 5 project, that cost is entirely avoidable because Bootstrap itself has used the native DOM API since version 5.0.

There is also a maintenance argument that runs parallel to the performance one. jQuery plugins are frequently abandoned. When a security advisory hits an unmaintained plugin, you face a forced upgrade or a manual patch. Vanilla JavaScript built on stable browser APIs requires no third-party maintenance at all.

If you are already working on broader Bootstrap 5 performance improvements, removing jQuery should sit near the top of your task list alongside tree-shaking unused CSS.

Running a Plugin Audit Before You Write Any Code

Open your template’s plugins.min.js or equivalent vendor bundle and list every plugin it contains. Then check each against three criteria:

1. Is it a jQuery plugin or a standalone library? Standalone libraries like Swiper, GLightbox, and Flatpickr have never depended on jQuery. You can keep them as-is.
2. Does the template’s own JS still call $.fn on it? If functions.bundle.js calls $('.selector').slick(), that initialisation code also needs replacing.
3. Is there an actively maintained vanilla alternative? For most plugins the answer is yes. For a handful of highly specific plugins you may need to write a small custom module.

Document your findings in a simple table: plugin name, size, jQuery-dependent (yes or no), vanilla alternative, estimated effort. That table becomes your migration plan.

The Most Common Plugin Replacements

Slick Carousel / OwlCarousel2 to Swiper or Splide. Both Slick and OwlCarousel2 require jQuery. Swiper (currently version 11) and Splide (version 4) are fully independent, actively maintained, and tree-shakeable.

<!-- Before: Slick initialisation -->
<script>
  $('.my-slider').slick({ dots: true, infinite: true });
</script>

<!-- After: Splide -->
<link rel="stylesheet" href="splide.min.css">
<div class="splide" id="mySlider">
  <div class="splide__track">
    <ul class="splide__list">
      <li class="splide__slide">Slide 1</li>
      <li class="splide__slide">Slide 2</li>
    </ul>
  </div>
</div>
<script type="module">
  import Splide from './splide.esm.js';
  new Splide('#mySlider').mount();
</script>

jQuery Easing / jQuery Smooth Scroll to native CSS and scroll-behavior. Add scroll-behavior: smooth to your html element and anchor links scroll smoothly with zero JavaScript. For per-element control, use element.scrollIntoView({ behavior: 'smooth' }).

jQuery AJAX to fetch. The Fetch API is supported in every modern browser and requires no polyfill for any deployment target above IE 11.

<script>
// Before
$.ajax({ url: '/api/data.json', success: function(data) { console.log(data); } });

// After
fetch('/api/data.json')
  .then(res => res.json())
  .then(data => console.log(data));
</script>

jQuery Waypoints / ScrollReveal jQuery wrapper to IntersectionObserver. The IntersectionObserver API fires callbacks when elements enter or leave the viewport. It is more performant than scroll event listeners because it runs off the main thread.

<script>
const observer = new IntersectionObserver((entries) => {
  entries.forEach(entry => {
    if (entry.isIntersecting) {
      entry.target.classList.add('is-visible');
      observer.unobserve(entry.target);
    }
  });
}, { threshold: 0.2 });

document.querySelectorAll('[data-animate]').forEach(el => observer.observe(el));
</script>

For more complex scroll-driven animations, the GSAP ScrollTrigger approach is a strong alternative that gives you timeline control without any jQuery dependency.

jQuery Validate to the Constraint Validation API. HTML5 attributes like required, minlength, pattern, and type="email" handle the majority of form validation natively. For custom messages, input.setCustomValidity() and the invalid event cover most edge cases.

Replacing jQuery Event Delegation

The pattern developers miss most after removing jQuery is $(document).on('click', '.selector', handler). The vanilla equivalent uses the native Event object to check the target:

<script>
// jQuery pattern
$(document).on('click', '.btn-dismiss', function() {
  $(this).closest('.alert').remove();
});

// Vanilla equivalent
document.addEventListener('click', (e) => {
  const btn = e.target.closest('.btn-dismiss');
  if (!btn) return;
  btn.closest('.alert').remove();
});
</script>

Element.closest() traverses upward through the DOM, so it handles clicks on child elements inside the delegate target correctly, matching the behaviour of jQuery’s event delegation.

Removing jQuery from the Bundle Safely

Once every jQuery-dependent call in your codebase has been replaced, remove jQuery from your build. If you are using a Vite-based workflow, covered in detail in the Vite setup guide, simply delete the import statement and run vite build. The bundler will confirm no remaining module imports jQuery.

For templates that still load scripts with <script> tags, remove the jQuery <script> tag from the base layout and open the browser console. Any ReferenceError: $ is not defined errors point to code you missed in the audit.

Before committing the final removal, tag the current state of your repository. A clear git strategy, such as the one described in the template customisation git guide, means you can roll back instantly if a plugin replacement reveals an edge case in production.

Test across Chrome, Firefox, Safari, and at least one mobile browser. Pay particular attention to form submissions, modal triggers, and any animation that previously relied on jQuery’s .animate() method. CSS transitions are the correct modern replacement for most of those cases.

When Keeping jQuery Is the Pragmatic Choice

There are situations where removing jQuery costs more than it saves. If your template integrates a paid plugin with no vanilla alternative and the vendor actively maintains it, the migration risk outweighs the bundle saving. Similarly, if the project ships tomorrow and jQuery is already cached on the CDN your users hit daily, the practical performance delta is small.

The goal is not jQuery removal as a badge of honour. The goal is a faster, more maintainable codebase. If removing jQuery saves you 30 KB and two unmaintained dependencies, do it. If it requires rewriting a complex data table plugin in three days before a deadline, defer it to a planned refactor sprint and document the decision.

Looking for a production-ready Bootstrap 5 HTML template? Browse Canvas Template demos and find the perfect starting point for your next project.

If you’re building with the Canvas HTML Template and want to ship production-ready Bootstrap 5 layouts faster, try Canvas Builder free — the visual builder that exports clean Canvas-ready markup in minutes.