Looking at your extraction pipeline, pdfjs + geometryWorker + lattice + visualGridMapper, what makes this any different from any other extraction approach for frontend only, no backend or compiled engine?

It's the right question to ask any author of a tool. So I sat down and surveyed the space honestly. What I found was more interesting than my gut answer.

The pipeline isn't different because of clever algorithms. The lattice reconstruction is the same lattice reconstruction every server-side tool uses. The KD-tree proximity is a textbook nearest-neighbor query. Y-band paragraph clustering is in a 1996 paper. The math is borrowed.

What's different is the quadrant of the design space the pipeline occupies, and the architectural commitments it took to land there.

This post maps that design space. It catalogs what's already in each cell, identifies the empty one, and explains why it stayed empty long enough for a niche to form.

1. The 2×2 grid

Two axes describe almost every PDF extraction project I've encountered:

• Approach axis: deterministic vs. ML-based.

• Output axis: visual fidelity vs. semantic structure.

Plot them and you get four cells.

                 DETERMINISTIC                 ML-BASED
                ───────────────                ────────
  SEMANTIC      pdfplumber, Tabula,            Adobe Extract API,
  STRUCTURE     Camelot, PyMuPDF               Textract, Azure DI,
  (backend)                                     transformers.js + layout
                                                models (frontend)

  VISUAL        pdf2htmlEX                     —
  FIDELITY      (frontend WASM)
  (frontend)

  TEXT-ONLY     pdfreader, pdf-extract,        tesseract.js
  STREAM        the naive getTextContent()     (OCR over rendered canvas)
                recipe

Three observations fall out of this map immediately.

Backend dominates the deterministic-structural cell. Everything serious about extracting structure from PDFs without ML lives on a server. pdfplumber, Tabula, Camelot, PyMuPDF — all Python, all backend, all decades of accumulated implementation knowledge.

Frontend is well-represented but compromised. Each frontend project gives up something significant. pdf2htmlEX reproduces visual appearance perfectly but ships zero semantic structure. tesseract.js works on scanned PDFs but throws away the native text layer that digital PDFs hand you for free. The transformers.js + layout-model approach handles weird documents but ships multi-megabyte model weights and opaque failure modes. The naive getTextContent() recipe and its Y-clustering descendants give you a flat blob and don't read the operator list at all.

There's a frontend cell that's empty. Deterministic. Structural. No ML weights. No raster step. No backend.

That empty cell is where this pipeline sits.

2. The naive 95 percent

Before we look at what fills the four occupied cells, it's worth establishing the baseline. Roughly 95 percent of frontend PDF extraction code in the wild does this:

const pdf = await pdfjsLib.getDocument(bytes).promise;
let text = '';
for (let i = 1; i <= pdf.numPages; i++) {
  const page = await pdf.getPage(i);
  const content = await page.getTextContent();
  text += content.items.map(it => it.str).join(' ') + '\n';
}

This works on a memo. It collapses on a two-column research paper. It liquefies on a table. It can't tell a heading from a paragraph. It has no concept of reading order on a complex page.

Everything beyond this baseline is a project trying harder. There are four serious such projects. None of them sits in the deterministic-structural-frontend cell.

3. The four occupied frontend cells

Cell A: pdf2htmlEX — visual fidelity, no semantics

pdf2htmlEX is a WASM port of an old C++ project. It walks the PDF and emits absolutely-positioned <div>s that visually reproduce the source.

<div style="position:absolute; top:124px; left:88px; font-size:11pt">A table cell</div>
<div style="position:absolute; top:124px; left:240px; font-size:11pt">Another</div>
<div style="position:absolute; top:124px; left:392px; font-size:11pt">Cell</div>

If you want to render the PDF in a browser and let the user select text, this is unbeatable. If you want any semantic structure (a <table>, an <h1>, a paragraph block), you're back to scraping divs by their bounding boxes — the same problem the user started with.

Cell B: tesseract.js — OCR

Render each page to canvas. Run OCR on the canvas. Get text + bounding boxes back.

This is the right answer for scanned PDFs that have no native text layer. It's the wrong answer for digital PDFs that already have perfect text. You're feeding selectable text through an image-to-text model and getting a degraded copy of what was already there. Plus a 2MB WASM payload, plus seconds-per-page latency.

Cell C: transformers.js + layout models — ML-based structural

Load a layout-aware model (DocLayout-YOLO, LayoutLM, or similar) into the browser via ONNX or transformers.js. Render each page to canvas. Run inference. Get back labeled regions: TABLE, TEXT, FIGURE.

This is where the modern industry is heading. It works on weird, varied document types. It generalizes. But:

• The model weights are megabytes (DocLayout-YOLO Nano alone is ~6MB ONNX).

• First inference takes seconds.

• Failure modes are opaque — when the model misclassifies, you have no levers.

• You're shipping an ML inference engine to do something that, for digital PDFs, can be done with pure geometry.

Cell D: pdfreader, pdf-extract, and friends — text-only Y-clustering

These libraries take getTextContent() items, cluster them by Y position, sort by X, and produce slightly more structured output than the flat-blob recipe.

The fundamental limit: they only consume the text content. They never call getOperatorList(). They cannot see vector lines. They cannot detect a table border, distinguish an underline from a horizontal rule, or recognize a chart axis. Their world is text and only text.

For prose-heavy documents, that's fine. For anything with tables, they degrade to row-smashing.

4. The empty cell, and what fills it

The deterministic-structural-frontend cell asks for a tool that:

1. Runs entirely in the browser. No server.

2. Ships no ML model weights. Determinism via geometry.

3. Reads the operator list, not just the text content. Vector-aware.

4. Outputs semantic structure: tables with topology, headings, paragraphs, lists, reading order.

To fill it, this pipeline does the following:

4.1 CTM-baked vector segments

// ctmAdapter.js (simplified)
for (let i = 0; i < fnArray.length; i++) {
  if (fnArray[i] === OPS.save)    ctmStack.push(ctm.slice());
  if (fnArray[i] === OPS.restore) ctm = ctmStack.pop();
  if (fnArray[i] === OPS.transform) ctm = mulMatrix(ctm, argsArray[i]);
  if (fnArray[i] === OPS.constructPath) {
    // Walk subpaths, transform each point through CTM × viewport.transform,
    // emit normalized H/V segment records.
  }
}

This is the move that puts the pipeline in a different category from cells B and D. We don't just consume text. We consume the operator list and reconstruct the page's vector skeleton in viewport coordinates. We can see the table borders before any text math runs.

4.2 Region-typed classification before extraction

Most pipelines run sequential passes: find tables, find paragraphs, find lists. Each pass works against the full text pool. Then you deduplicate at the end and hope the passes didn't disagree.

This pipeline does the opposite. Classify regions first, then route scoped text into each region's specialist extractor. The mechanism is a single assignedTextIndices set:

for (const lattice of lattices) {
  const tableTextIndices = [];
  for (const tm of textMeta) {
    if (assignedTextIndices.has(tm.idx)) continue; // skip consumed
    if (insideBBox(tm.vx, tm.vy, lattice.bbox, tablePad)) {
      tableTextIndices.push(tm.idx);
      assignedTextIndices.add(tm.idx); // mark as consumed
    }
  }
  regions.push({ type: TABLE, lattice, textItemIndices: tableTextIndices });
}
// later: paragraph/heading/list passes only see un-consumed text

The invariant is: a text item belongs to exactly one region. No leakage by construction. The bug class of "table text accidentally in a paragraph" is preempted, not patched.

4.3 Underline-vs-border discrimination

A naive lattice reconstructor sees every horizontal line and tries to use it as a table border. This produces phantom 1×1 tables under every underlined heading.

We classify each H-segment against the text baselines using KD-tree-style proximity:

for (const h of hSegs) {
  const hY = (h.y1 + h.y2) / 2;
  for (const tm of textMeta) {
    const yDist = hY - tm.vy;
    if (yDist >= -1 && yDist <= 5 &&
        tm.vx <= hXMax + 2 && (tm.vx + tm.vWidth) >= hXMin - 2 &&
        hLen < tm.vWidth * 2.5) {
      underlineSegIds.add(h.id);
      break;
    }
  }
}

If a horizontal line sits 0–5px below a text baseline with overlapping X-span, it's an underline. Tag it. Remove from the table-detection pool. ~99% of phantom tables disappear.

I have not seen another browser-side PDF extractor that does this. Tabula has equivalents on the backend. On the frontend, every other tool I've audited just hands all H-lines to the lattice and lives with phantom tables.

4.4 Topological cell-merge inference

Naive table extractors detect cell merges by visual whitespace heuristics ("if these two cells have no visible boundary between their text, they're merged"). This is unreliable. Tables with thin internal borders look unmerged but are; tables with wide cell padding look merged but aren't.

This pipeline asks the geometry directly:

function vLinePresent(vLines, x, yA, yB, eps) {
  return vLines.some(l =>
    Math.abs(l.x - x) <= eps &&
    l.yMin <= yA + eps &&
    l.yMax >= yB - eps
  );
}

Is there an actual merged vertical-line record at this X position spanning [yA, yB]? If yes, the cell boundary exists; the cells are separate. If no, extend the colspan. Topological, not visual.

4.5 Nearest-cell Euclidean snap

Strict point-in-box assignment drops text whose origin is 0.1px outside a cell, which is common because PDF rendering coordinates have jitter. We use Euclidean distance to the nearest cell center with a 15px snap threshold:

let bestR = -1, bestC = -1, minDist = Infinity;
for (let ri = 0; ri < numRows; ri++) {
  for (let ci = 0; ci < numCols; ci++) {
    const dx = Math.max(cols[ci] - sx, 0, sx - cols[ci+1]);
    const dy = Math.max(rows[ri] - sy, 0, sy - rows[ri+1]);
    const dist = Math.sqrt(dx*dx + dy*dy);
    if (dist < minDist) { minDist = dist; bestR = ri; bestC = ci; }
  }
}
if (minDist < 15) cells[bestR][bestC].push(...);

Magnetic, not literal. Coordinate jitter doesn't drop data.

4.6 Worker-isolated full pipeline

Most browser PDF extractors run on the main thread. The geometry pipeline here loads PDF.js as a nested worker inside the geometry worker. CTM baking, lattice reconstruction, classification, assembly — all off the main thread. The UI stays responsive on a 200-page document.

4.7 Per-page streaming

Naive extractors accumulate the whole document into one structured-clone payload at the end. That dies on large PDFs with stack-overflow errors in postMessage. We emit per-page 'page' messages from the worker, the main thread accumulates incrementally, and the UI can show progressive results.

self.postMessage({
  type: 'page',
  page: p,
  html: result.html,
  text: result.text.trim(),
  tables: result.tableCount,
});

Not algorithmic novelty. Engineering discipline that lets the architecture survive 76-page technical manuals.

4.8 VisualGridMapper as a downstream operator

The output isn't a dead <table> string. It's a live HTML table that we can immediately remap into a Cartesian array using VisualGridMapper:

const mapper = new VisualGridMapper(table);
// mapper.grid[row][col] now holds origin/spanned cell metadata.
// Transposes, merges, splits all become matrix operations.

This is the bridge into the table-formatter half of the platform. Other extractors stop at "here's a <table>." We hand the user something they can keep manipulating mathematically.

5. What's borrowed and what's new

Worth being honest about which pieces of this are original engineering versus academic standard:

Borrowed:

• The lattice algorithm itself — intersection clustering, row/column projection. Same as Tabula, Camelot, pdfplumber.

• Y-band paragraph clustering — pdfminer-style, in academic literature since the 90s.

• XY-cut column detection — known since the 80s.

• KD-tree spatial indexing — textbook.

• DOMPurify, jQuery, Monaco — off-the-shelf.

Original to this pipeline (or unusual in the niche):

• The full assembly running in a Web Worker on top of PDF.js as a nested worker.

• The non-overlapping-region invariant via assignedTextIndices.

• The underline-discrimination heuristic with the specific 0–5px / 2.5×-width thresholds.

• The coordinate-space discipline: storing both vWidth/vFont (viewport) and width/fontSize (PDF points) on every text-meta record, with explicit comments about which to use where.

• The per-page streaming pattern that survives 100+ page documents.

• The integration with VisualGridMapper for downstream mathematical manipulation.

The pipeline is a composition. The composition is the contribution.

6. Why this cell stayed empty

If the deterministic-structural-frontend cell is valuable, why hadn't anyone filled it?

Three reasons, in order of how convincing each one is.

Economics push toward backend. If you have a use case that needs structural PDF extraction, you almost certainly have a server. The serious tools live in Python and have for a decade. There's no incentive to port them unless you specifically need data to stay on the client device which is a real but niche requirement.

Existing frontend tools are anchored to other quadrants. pdf2htmlEX is committed to visual fidelity. tesseract.js is committed to OCR. The transformers.js camp is committed to ML generalization. Each is well-architected for its quadrant and would require an architectural rewrite to drift into the deterministic-structural cell. Nobody had a reason to do that work.

The pieces are scattered. PDF.js gives you the operator list but assumes you'll use it for rendering. Lattice algorithms are described in papers, not packaged as npm modules. KD-tree libraries assume preformatted data. Web Worker isolation has its own ergonomic learning curve. Climbing the staircase to assemble all of these is real engineering work, and unless you have a strong reason to be in this exact cell, the cost-benefit doesn't pencil.

We had a reason. The platform we're building is browser-native by commitment, not accident. Every other tool in our pipeline runs in the browser. Sending PDFs to a server for structural extraction would have broken the architectural model. So we climbed.

7. The lesson above the niche

There's a generalization worth saying out loud, because it applies far beyond PDF tooling.

When you wonder whether you're reinventing a wheel, do the survey. But ask the right question. The question is not "has anyone solved this problem?" — the answer to that is almost always yes, somewhere. The question is:

What set of constraints does my version satisfy that nobody else's version satisfies?

Constraints are commitments. No backend. No model weights. Worker isolation. Deterministic output. Per-page streaming. Open source. Each one is a deliberate refusal of a path other people took.

The intersection of constraints is where new niches live. The math you use inside that intersection is often the same math everyone else uses. That's fine. The originality isn't in the math. It's in the negative space — the things you said no to.

The pipeline isn't different because the algorithms are different. It's different because of where it runs and what it refuses to be.

The full pipeline is open source as part of the GINEXYS project. If you find a fifth camp I missed, or if you've built something that fills the empty quadrant differently, the issue tracker is open. I'm specifically curious whether anyone else has implemented in-browser CTM baking against pdfjs-dist's operator list — that piece felt the loneliest in my survey.

If you've ever tried to write a script to scrape a PDF, you know exactly what I mean. You run the PDF through a generic text extractor, and instead of a clean table, you get a jammed wall of text where the columns are violently shoved into a single vertical stack.

Or worse, you try to use a table extractor, and it hallucinates tables everywhere. See a bold heading with an underline? The parser thinks that's a 1x1 table. See a horizontal divider between paragraphs? Boom, phantom table.

Why does this happen? Because most PDF parsers process the document in a strict, sequential pipeline. They look at all the lines. They look at all the text. And they just smash them together.

I got tired of this. So I re-engineered the extraction pipeline in our PDF processor to stop reading the document like a machine, and start seeing it like a human.

Here is the math behind Context-Aware PDF Extraction.

1. The Blind Extraction Problem

Previously, our extraction pipeline worked like this:

1. Find all horizontal and vertical line segments (H-segs and V-segs).

2. Run them through a LatticeReconstructor to find intersecting grids.

3. Treat every grid as a table.

4. Dump all the text in the document into those grids using a strict "is this point inside this box" check.

This was a disaster for documents that mixed paragraphs with tables.

If a paragraph had a decorative underline, the LatticeReconstructor would see the H-line, panic, and try to build a table out of it. If text was slightly offset inside a table cell due to coordinate jitter, the "point-in-box" check would fail, and the text would just vanish from the output.

I needed the parser to understand context.

2. Enter the Context Classifier

To fix this, I built the contextClassifier.

Instead of treating the PDF as a bucket of shapes and text, the contextClassifier walks the document and groups every single item into spatially bounded, typed regions: TABLE, PARAGRAPH, HEADING, LIST, and IMAGE.

But how do you tell a machine the difference between a table border and a decorative underline?

You use proximity math.

// KD-tree style proximity: check if text sits exactly on top of an H-line
for (const h of hSegs) {
    const hY = (h.y1 + h.y2) / 2;
    for (const tm of textMeta) {
        const yDist = hY - tm.vy; 
        
        // Underline: line is 0–5px below the text baseline
        if (yDist >= -1 && yDist <= 5 && overlappingXSpan(tm, h)) {
            underlineSegIds.add(h.id);
            break; 
        }
    }
}

If a horizontal line is exactly 0 to 5 pixels below a text baseline, and its width roughly matches the text width, it's not a table border. It's an underline.

By tagging and removing these underlines before we run the table reconstruction, we eliminate 99% of phantom tables.

3. Scoping the Text (No More Collisions)

Once the tables are detected, we calculate the exact bounding box of the table grid.

Instead of throwing all the document's text at the table builder, the classifier scoops up only the text items that physically live inside that bounding box.

const tableTextIndices = [];
for (const tm of textMeta) {
    if (insideBBox(tm.vx, tm.vy, bbox)) {
        tableTextIndices.push(tm.idx);
        assignedTextIndices.add(tm.idx); // Mark as consumed!
    }
}

This does two things:

1. It guarantees that table text doesn't accidentally leak into paragraphs.

2. It guarantees that paragraph text doesn't get sucked into table cells.

Once a text item is claimed by a region, it's marked as consumed.

4. The Nearest-Cell Proximity Assignment

Even with scoped text, getting the text into the correct table cell was still failing due to PDF rendering quirks. A cell might be at x: 10.5, but the text was at x: 10.4. A strict bounding box check would drop the text.

I ripped out the strict containment checks and replaced them with a nearest-neighbor proximity model.

For every piece of text, we find its nearest cell center using Euclidean distance. If it's within a 15px threshold, it snaps into place. No more jitter. No more dropped data.

5. The Page Assembler

Finally, the pageAssembler takes over.

It receives an array of perfectly classified, non-overlapping regions. It sorts them top-to-bottom based on their Y-coordinates.

Then, it just iterates through them and calls the right extractor:

• If it's a TABLE, it sends the scoped text to the tableBuilder.

• If it's a HEADING, it wraps it in an <h3> or <h4>.

• If it's a LIST, it strips the bullet points and outputs clean <ul><li> tags.

• If it's a PARAGRAPH, it sends it to the textRebuilder.

The result? True document reading order.

You upload a messy, complex PDF filled with tables, paragraphs, and lists. The pipeline classifies it, scopes the data, and spits out clean, semantically correct HTML.

No backend processing. No AI hallucination. Just pure, deterministic math running directly in your browser using pdfjs-dist and vanilla JS.

The PDF is finally readable.

Check out the repo here or give it a try in Ginexys. Let us know how it did

If you haven't worked deeply with HTML tables, you might think a table is just a simple 2D array: table[row][col].

The moment an HTML table introduces a colspan or a rowspan, the visual (x, y) coordinate of a cell completely detaches from its DOM hierarchy. If row 1 has a cell with colspan="3", then the second <td> in that row is visually in column 4, but programmatically it is childNodes[1].

If you try to write a "select column" function by just iterating through tr > td:nth-child(n), your highlighting will look like abstract art the second it hits a merged cell.

I learned that the hard way.

If you work with scraped tables, PDF exports, legacy system data, or just need to clean up HTML tables before dropping them into a docs platform, this is for you.

What started as a small utility for cleaning up scraped tables eventually became TAFNE - Table Formatter and Node Editor, a browser-based table IDE for reshaping broken tabular data and exporting it into useful formats. The hardest part wasn’t rendering the table. It was teaching the browser how to understand the table the way a human does.

What Didn't Work

My first attempt was just checking .prev() and .next() and trying to keep a running tally of offset index values.

1. The Problem Space

Try to write a function that highlights an entire column when you hover over a table header.

If the table represents a perfectly flat 2D array, it’s trivial: loop through every <tr> and add a CSS class to childNodes[colIndex].

But what if you are given this table?

<table id="messy-table">
  <tr>
    <td rowspan="2">A</td>
    <td colspan="2">B</td>
  </tr>
  <tr>
    <td>C</td>
    <td>D</td>
  </tr>
</table>

Visually, this is a 2x3 grid.

• Row 1, Col 1 is A

• Row 2, Col 1 is also A (because of rowspan)

• Row 2, Col 2 is C

• Row 2, Col 3 is D

But programmatically? C is tr[1].childNodes[0]. It thinks it's in the first column, but visually it sits in the second.

My initial approach of checking .prev() and .next() and keeping a running tally of offset index values was naive. This completely breaks when a cell has both colspan and rowspan acting simultaneously, or when consecutive cells in a row have varying spans. The edge cases are endless.

I needed a topographic map of the DOM, not just a DOM tree.

2. The Solution: The VisualGridMapper

To perform complex UI actions like drag-and-drop or matrix transposition on a table, you need to translate the DOM into a strict, predictable Cartesian plane.

I built a class called the VisualGridMapper. Its sole job is to walk the table once and build a dense 2D array (grid[row][col]) that maps absolute visual coordinates back to their origin node.

Here is a simplified look at the mapping logic:

class VisualGridMapper {
    constructor($table) {
        this.grid = []; // 2D array: grid[row][col]
        this.cellMap = new Map(); // DOM Element -> visual properties
        this.mapTable($table);
    }

    mapTable($table) {
        let currentRow = 0;

        $table.find('tr').each((rIndex, tr) => {
            if (!this.grid[currentRow]) this.grid[currentRow] = [];
            let currentCol = 0;

            $(tr).find('td, th').each((cIndex, cell) => {
                const \(cell = \)(cell);
                const rSpan = parseInt($cell.attr('rowspan')) || 1;
                const cSpan = parseInt($cell.attr('colspan')) || 1;

                // EDGE CASE: Skip cells that are already occupied by 
                // a rowspan from a previous row
                while (this.grid[currentRow][currentCol]) {
                    currentCol++;
                }

                // Record the origin node
                const cellData = {
                    element: cell,
                    isOrigin: true, // This is the actual DOM node
                    startRow: currentRow,
                    startCol: currentCol,
                    rowspan: rSpan,
                    colspan: cSpan
                };
                
                this.cellMap.set(cell, cellData);

                // Fill the physical space in our 2D array
                for (let r = 0; r < rSpan; r++) {
                    for (let c = 0; c < cSpan; c++) {
                        if (!this.grid[currentRow + r]) this.grid[currentRow + r] = [];
                        
                        this.grid[currentRow + r][currentCol + c] = {
                            element: cell,
                            isOrigin: (r === 0 && c === 0)
                        };
                    }
                }
                currentCol += cSpan;
            });
            currentRow++;
        });
    }
}

Handing the "Ghost Cell" Edge Case

The while (this.grid[currentRow][currentCol]) loop is the crucial edge case handler. As the parser moves through a <tr>, it checks the map to see if the current visual column is already physically occupied by an element from a row above it stretching down. If it is, the pointer advances silently, bumping the current row's children to the right so they align with their true visual placement.

The Letdown that Became a Superpower

Building this mapping layer was tedious. But once it existed, something amazing happened: complex table mutations fell out for free.

Want to transpose a table? I didn't need to write complex DOM-shuffling logic. I just ran a standard matrix transpose on my VisualGridMapper array ([row][col] becomes [col][row]), swapped the rowspan and colspan values, merging cells, and splitting cells, all table mutations are now matrix problems. No worries about the complexities of sequentially re-rendering the DOM. Linear algebra solved the UI problem.

3 Why This Tool Exists

TAFNE was built specifically for developers, data analysts, and technical writers. For people who deal with messy tabular data and need a cleaner way to work with it

You input or load a CSV, ASCII, text, or HTML, and TAFNE takes that VisualGridMapper and generates multiple formats directly into an embedded Monaco Editor.

It currently supports exports like:

• Markdown, for GitHub READMEs and docs.

• JSON, for structured data pipelines or API work.

• HTML, for clean table output.

• SQL, which became the most useful export for me. Paste in a messy CSV, the tool can infer headers, generate a CREATE TABLE statement, and produce the corresponding INSERT INTO statements with escaped values.

You can go from a mangled PDF scrape to a populated database backend in about 8 seconds, without writing a single line of backend parsing logic.

I'm still working to include more imports and exports such as LaTeX, and Excel. You can support the development of TAFNE by checking out GitHub.

4. The Architecture Choice

The entire editor is built with Vanilla JavaScript and jQuery.

That wasn’t a nostalgic decision. It came out of the constraints of the tool itself.

I wanted the simplest possible setup: something you could open locally, run without a build step, and use without sending data to a backend. For a tool that may handle financial tables, internal reports, or scraped documents, local-first matters. The data should stay on the machine.

There was also a more practical reason: the DOM is already the thing I was trying to control.

For this kind of table manipulation, I didn’t want to constantly translate between a virtual state model and the browser’s actual structure. The table itself is the structure. So instead of forcing the problem into a framework-shaped box, I let the browser do what it was already good at, and used the mapper only when I needed to reason about the table mathematically.

That choice came with tradeoffs, of course.

Without framework lifecycles, I had to be much more disciplined about cleanup. Event handlers had to be namespaced carefully. Re-rendering meant I had to think hard about stale listeners. Undo and redo also took more manual work, because I couldn’t lean on immutable state patterns to do the bookkeeping for me.

But the tradeoff felt worth it for this project.

5. What I Learned

The biggest lesson was that HTML tables are more than markup. If you want to make them editable, mergeable, split-able, or transposable, you need to stop treating them like a flat list and start treating them like a coordinate system.

That change in perspective unlocked the whole engine.

I didn’t begin with a grand plan to build a visual table IDE. I started with a broken problem, tried a few awkward fixes, and eventually found that the cleanest solution was to map the DOM into a visual grid first, then operate on that model instead of fighting the browser directly.

That’s usually how these tools come together: not through one elegant insight, but through a series of small, stubborn corrections until the structure finally makes sense.

The SQL emitter and the VisualGridMapper are both open source on GitHub: carnworkstudios/TAFNE. I'd genuinely like feedback on the type inference logic. If you've solved similar problems differently, tell me in the comments or open an issue on the repo.