The WebViewer obsession

2026 · Vibe coding FileMaker widgets · ChatGPT, Gemini, Claude, FileMaker WebViewer

In April 2026 I wrote this in a project log: “This has been an obssession project for me as once I started I keep thinking about it and running through rounds and rounds of batch processing.”

The project was a file-processing engine built inside a FileMaker web viewer, FileMaker’s built-in browser, over about six weeks. FileMaker developers have always had the web viewer. Writing serious JavaScript for it was another matter. AI made that economical, and once it did, I couldn’t stop.

How the web viewer took over

It started small: an image viewer, a Markdown preview, a two-column layout for some data. Then it grew. A calendar with two-way communication with FileMaker. A product catalogue with popups, desktop and mobile layouts, a preloader and keyboard controls. Dashboards. List views. By January 2026 most of my new interface work was HTML, CSS and JavaScript running inside FileMaker, on the same data and business logic FileMaker has always been good at.

Late in 2025 I described it like this: “It runs inside native FileMaker, works with WebDirect, and the speed is honestly wild — stuff that normally takes days can be done in hours.”

The engine that wouldn’t keep up

The obsession project was a batch processor: point it at a set of records with images and PDFs, and it generates thumbnails for every one of them in the background.

The JavaScript worked. The FileMaker loop calling it worked. Together, they didn’t. FileMaker would move to the next record before the JavaScript had finished rendering the last one. That’s a race condition: two processes running at their own speed, neither waiting for the other.

The debugging got creative. We built a small diagnostic console inside the web viewer, and a visual “handshake” that flashed each time FileMaker and JavaScript passed data back and forth, so I could see where the hand-off dropped. We moved the processing into an off-screen window so the web viewer’s memory wouldn’t get wiped mid-batch. I’d wanted to get rid of FileMaker’s timer scripts entirely and let JavaScript run the queue.

In the end the fix was mine, and it was old-fashioned. “so u know what did the trick…install script on timmer to run the process batch single script nad on the save and continue script adding a halt on last record step.” A timer script, and a Halt step on the last record. FileMaker waits its turn, and the race is over.

The next bug was mine too. A “corrupt image” error turned out to be a FileMaker script step passing the name of a variable instead of the variable itself. The AI helped narrow it down. The fix took one look at the script.

Escaping, and other small hells

Not every lesson was that dramatic. Plenty of hours went into quote marks. Passing a block of HTML from a FileMaker calculation into JavaScript means every double quote has to survive two languages. One wrong escape and the whole widget is a blank rectangle. The answer that stuck was to stop building strings by hand: wrap the data with FileMaker’s JSON functions and pass it as a parameter.

Version control, FileMaker style

When you vibe-code a widget, the code changes constantly, and some changes are worse than the last. Before I used git, I solved this inside FileMaker. Each widget’s HTML lives as a record in a table, and every iteration is kept in a history table. Rolling back means duplicating the last version that worked. It’s homemade version control, and it got me through a lot of bad afternoons.

What stuck

  • AI made the web viewer practical. The capability was always there. Writing the JavaScript was the cost, and that cost collapsed.
  • Keep the data in FileMaker, the interface in the browser. Records, scripts and business rules stay native. The web viewer does what native layouts can’t.
  • Async code needs a handshake. If two systems run at different speeds, decide who waits, and make it visible while you debug.
  • Version everything you vibe-code. Somewhere, somehow, before you need it.

If you’re starting here today

  • Start with a one-way widget: FileMaker sends data, the web viewer displays it. Add the return trip once that works.
  • Pass data as JSON, not as strings you’ve escaped by hand.
  • Build a tiny on-screen log into anything asynchronous. Seeing the hand-off beats guessing at it.
  • Store widget code in records with history, or in git. Rolling back should take seconds.

Related: FileMaker WebViewer widgets with AI · The function that doesn’t exist · Copy, paste, FTP: what’s old is new

Back to AI Journey Chronicles