Question Investigation 23 Good jQuery - herougo/SoftwareEngineerKnowledgeRepository GitHub Wiki

Question 1: Should the namespace object pattern be used?

ChatGPT Response

❌ The “Custom Namespace Object” Pattern

const Modules = {};
Modules.Utils = {};
Modules.Utils.convertString = (text) => {
    // ...
};
Problems

  1. Global coupling

    • Everything hangs off one global object.
    • Harder to tree-shake.
    • Harder to test in isolation.

  2. Manual dependency management

    • You don’t know what depends on what.
    • No explicit imports.

  3. No static tooling benefits

    • Harder for IDEs and linters.
    • No circular dependency detection.

  4. Feels modern but is pre-ES6 architecture

This was common in 2012. In 2026, we should use modules.

✅ Recommended: Use ES Modules (Native JS Modules)

Organize your project using files as modules.

Summary

If you're starting fresh in 2026:

  • ✅ Use ES modules
  • ✅ Organize by feature if possible
  • ✅ Keep modules small
  • ✅ Export only what is needed
  • ❌ Avoid global namespace objects

Question 2: Is MVC with jQuery a good idea?

Why MVC doesn’t fit jQuery well

Classic MVC assumes clear separation of responsibilities:

  • Model → data + business logic
  • View → rendering UI
  • Controller → handles input and coordinates between model and view

In practice, jQuery blurs these boundaries badly:

1) jQuery mixes View + Controller by nature

Typical jQuery code:

$('#saveBtn').click(function () {
    const name = $('#name').val();
    model.save(name);
    $('#status').text('Saved!');
});

This mixes:

  • DOM querying (View)
  • Event handling (Controller)
  • Application logic (Controller/Model coordination)

As the app grows:

  • Logic becomes scattered across event handlers
  • Behavior becomes tightly coupled to DOM structure
  • Testing becomes painful

2) jQuery encourages implicit architecture

jQuery promotes:

$(...).doStuff(...)

This leads to:

  • No clear component boundaries
  • Hard-to-trace dependencies
  • Large monolithic script files
  • Tight coupling between UI and logic

MVC requires intentional structure, which jQuery does not naturally enforce.

3) jQuery MVC implementations tend to rot

You can implement MVC manually in jQuery, but:

  • It takes constant discipline

  • The abstraction usually erodes over time

  • Eventually everything becomes:

    "Some event handler that modifies the DOM and does logic"

This is why older jQuery projects often become massive technical debt.

3: Code Review of Root-based Approach

class KanbanBoardRoot {
    constructor() {
        this.components = {
            board: new KanbanBoardBoard()
        };
        this.state = new KanbanBoardState();
    }

    init() {
        this.components.board.registerOnClicks(this);
    }
}

Big problem: registerOnClicks passing this

What about this?

init() {
    const boardDependencies = this.components.board.extractDependencies(root);
    this.components.board.registerOnClicks(boardDependencies); 
}
Pattern Who Knows About Root? Coupling Good?
Pass this Everyone Very High ❌
extractDependencies(root) Board High ⚠️
Root builds dependency object Only Root Low ✅

Personal comments

  • You should really limit the amount of dependencies KanbanBoardBoard has outside its scope, which you can do with the 3rd approach.