The rewrite: 59% faster, 73% smaller, every line typed

The 1.x line was fine. It worked. It shipped features. It also accumulated a procedural-PHP debt that made every new feature take twice as long as it should.

2.0.1 is what happens when you stop adding to the heap and rewrite the foundations.

What “rewrite” means here#

Not “rename some files and call it modern”. A real, file-by-file restructuring:

Before#

gravity-tables/
├── gravity-tables.php       (2,400 lines, mixed concerns)
├── admin.php                (1,100 lines)
├── frontend.php             (1,800 lines)
├── ajax-handlers.php        (700 lines, every endpoint inline)
└── helpers.php              (everything else)

After#

gravity-tables/
├── includes/
│   ├── Bootstrap.php       , wires services
│   ├── Services/           , single-responsibility classes
│   │   ├── TableRenderer.php
│   │   ├── EntryRepository.php
│   │   ├── PermissionGate.php
│   │   ├── ExportService.php
│   │   └── …
│   ├── Repositories/       , data access only
│   ├── Exceptions/         , typed error hierarchy
│   ├── Http/               , AJAX handlers, one per file
│   └── ValueObjects/       , immutable structured data
├── templates/              , view layer, no logic
└── tests/                  , yes, actually

Every class has a constructor with typed dependencies. Every method has typed parameters and a return type. Every exception path throws a typed exception, not a generic Exception or, worse, a string-encoded array.

The performance numbers#

Before (1.9.x):

• Frontend bundle: 2,314 lines of JavaScript (jQuery + plugins)
• Initial render of a 100-row table: ~340ms
• Memory footprint: ~12MB for a complex table

After (2.0.1):

• Frontend bundle: 555 lines of vanilla JS
• Initial render of a 100-row table: ~140ms
• Memory footprint: ~3MB for the same table

That’s a 76% bundle reduction and 59% faster rendering, on a real-world dataset, in real browsers, on real client sites.

Why drop jQuery?#

Not because jQuery is bad, it’s still excellent for what it does. We dropped it because:

1. WordPress core ships jQuery, but our plugin re-loaded handlers on every AJAX response, multiplying memory
2. The features we actually used (DOM traversal, event delegation, AJAX) are 5 lines of vanilla each
3. Removing jQuery let us drop two transitive plugins and eliminate a class of “jQuery is not defined” support tickets

The vanilla rewrite uses fetch for AJAX, querySelectorAll for traversal, and delegated event listeners rooted at the table container.

Why the repository pattern?#

Because data access scattered across handlers means every new feature touches the database in subtly different ways, and you find out at 11pm on a Friday that one path forgot to apply the user permission filter.

The new EntryRepository is the only class that talks to the entries table. Every other class asks the repository, and the repository enforces the read/write rules. Tests cover the repository directly. Most bugs that would have been “permission leak in handler X” are now impossible by construction.

The trade-off#

A rewrite is debt of a different kind: users have to upgrade. We invested heavily in:

• A migration script that ran on activation
• A compatibility layer for old shortcode parameters
• A staging period of two weeks where 1.9.x and 2.0.x were both downloadable

Everyone landed safely. Two months later, 1.x was deprecated. Today nothing ships with 1.x DNA anywhere in the codebase.

What this unlocked#

Every feature shipped after 2.0.1, mobile cards, role permissions, frontend editing, bulk operations, exports, was only possible because the foundations stopped getting in the way.

The 4.1.x line you’re reading about today still rests on the architecture this release laid down. That’s the highest compliment a rewrite can earn.