Feature Request: move off of jquery in order to decrease load time and bundle size

[steve-ross]

Feature Request: Deprecate jQuery

Since we have webpack & polyfills you could move off of requiring jQuery since it increases the bundle size by 100K (even more if you can get rid of lodash (mostly using _.get & filter?)

Comparison when removing the app.js / webpack entry that injects jQuery

bundle: 5.1K
chunk: 2.8K

With JQuery (and granted a lot of other theme files)

Steps to reproduce behavior

Some code I've created using vanilla JS:

// vanilla dom-ready event: 
export const ready = (fn) => {
  if (document.readyState !== 'loading'){
    fn();
  } else {
    document.addEventListener('DOMContentLoaded', fn);
  }
}

// vanillaPageManager.js 

import { ready } from "./global/dom-ready";
export class SimplePageManager {
  constructor(context) {
    this.context = context;
  }

  type() {
    return this.constructor.name;
  }

  onReady() {
  }

  static load(context) {
    const page = new this(context);

    ready(() => {
      page.onReady.bind(page)();
    });
  }
}

// landingPageManager

import smoothscroll from 'smoothscroll-polyfill';
import { SimplePageManager } from '../vanillaPageManager';
import { buildAccordian } from './simpleAccordion';
import { headerSmoothScroll } from './headerSmoothScroll';


export class LandingPageManager extends SimplePageManager {
  onReady() {
    smoothscroll.polyfill();
    buildAccordian();
    headerSmoothScroll();
  }
}

export default LandingPageManager;

// webpack modification
    entry: {
        main: './assets/js/app.js',
        head_async: ['lazysizes', 'bgset'],
        polyfills: './assets/js/polyfills.js',
        landingPage: './assets/js/landingPage.js'
    },

[Tiggerito]

That reduction would be great.

I also noticed that the built in Data solution for Visual Website Optimizer loads a separate copy of jquery and the rebillia code is dependent on it. In total it makes three blocking requests for JavaScript early in the head section.

I have one client that loads 4 different versions of jQuery (including the one in the bundle)!

[BC-krasnoshapka]

I think it will be huge effort to completely deprecate jQuery in Cornerstone. jQuery is not just dom ready, but also selectors, ajax calls, other events that are used across whole theme.
We definitely should reduce the number of jQuery versions loaded. Currently we're working on Cornerstone performance optimizations and will take a look on jQuery as well.
I believe we have very limited influence on what libraries partners load in their code (VWO and other).

[steve-ross]

Yeah I realize this is "pie in the sky" but, it would be great to start moving away from it, definitely think with all of the modern tech in the project it would be a lot easier.

Less of a lift would be to move off of Lodash since the number of calls to it are obvious and pretty limited to a handful of simple methods like _.includes(), _.isEmpty(), _.isNan() (which I love) but, can easily be migrated to simple or polyfilled functions.

[bc-vlad-dlogush]

We checked report.html by analyzing bundles and found out that JQuery is loaded only once. As for the rest of the downloads, we cannot control them because they are loaded by external libraries.

[sacr3dc0w]

Yeah I realize this is "pie in the sky" but, it would be great to start moving away from it, definitely think with all of the modern tech in the project it would be a lot easier.

Less of a lift would be to move off of Lodash since the number of calls to it are obvious and pretty limited to a handful of simple methods like _.includes(), _.isEmpty(), _.isNan() (which I love) but, can easily be migrated to simple or polyfilled functions.

Reduced lodash usage a little with #2256

[steve-ross]

I've heard rumors that performance is on the roadmap for '23? Curious if that means cornerstone as well.

Honestly, it seems like this would be an impossible task to modify and refit the current version of the theme.

Wondering if it would be better to approach would be to just build a simpler new theme that is more developer friendly and framework independent. Remove multiple versions, Zurb, widgets, and theme editor bits.

We're currently floating this idea and I'd love to make the project public but, not sure if the org will go for that. If we do I'll be sure to follow up. my .02c at the moment if anyone is interested 😁