Lately, I’ve been bumping into the same wall across two very different stacks—Filament and Directus. Both powerful, both promising, but both capable of becoming performance nightmares if you let reactivity run wild.
With Filament (Livewire), I thought I was being clever by making almost every field reactive. Dependent dropdowns? Reactive. Toggles updating related values? Reactive. The problem: every little interaction triggered full component rehydrations. Before I realized it, payloads had grown absurdly heavy—sometimes touching 5MB for something as trivial as changing one input. Debugging locally already felt sluggish; I could only imagine the pain for actual users.
So I decided to explore Directus, hoping the decoupled backend + custom frontend approach would give me more control. The backend part was great—it really shines there. But while building the frontend, I ended up making the same mistake in a new form. My React components were too tightly bound to global state and API responses, causing rerender loops and repeated network calls. It felt like déjà vu: different stack, same root problem.
What I’ve learned is this: reactivity is not a free pass. Just because you can make everything reactive doesn’t mean you should. The trick is being intentional—scoping updates narrowly, caching wisely, and knowing when to stop the loop instead of feeding it.
Sometimes the biggest bottleneck isn’t the framework—it’s me overusing its “magic.”
Hope this saves you from banging your head on the wall in future 😛
Best,
Anmoldeep