# Fireflies **URL:** \ **Category:** Elements\ **Created:** [December 8, 2025, 4:09pm UTC](https://forums.realmacsoftware.com/t/fireflies/53072 "2025-12-08T16:09:41Z")\ **Posts on this page:** 4\ **Page:** 3
**Author:** ![dan](https://dub1.discourse-cdn.com/flex005/user_avatar/forums.realmacsoftware.com/dan/32/28516_2.png) [@dan](https://forums.realmacsoftware.com/u/dan)\ **Post date:** [December 11, 2025, 10:26am UTC](https://forums.realmacsoftware.com/t/fireflies/53072/41 "2025-12-11T10:26:03Z")
> [@Doobox](#): > > My speculation was coarse and slightly off track re handle count. But it’s difficult to imagine why elements would monitor every file with DispatchSourceFileSystemObject at risk of running out of handles when it could use FSEvents and monitor each dev pack bundle (root folder) for changes. Monitoring with FSEvents on a directory is recursive, so on any change under that bundle could just reload the entire dev pack. 🤷‍♂️ Again, you don’t know what you’re talking about. Using FSEvents is like using a blunt instrument, while you might think it’ll work, it comes with some nasty side effects. FSEvents on the dev pack only tells you “something somewhere under here changed”. If we used FSEvent, Elements would have to: - Re-scan the entire dev pack directory tree - Re-parse all the info JSON, templates, hooks, scripts, metadata, etc. - Rebuild our in-memory structures Elements uses for that pack Dev packs can contain dozens or even hundreds of files (there can also be many components in a pack). Doing this on every tiny save is a performance disaster. When we tested it early on, the round-trip delay was about three seconds. That’s far too slow and completely breaks the live-feedback workflow. We choose the right technology for the job. Our current approach gives instant updates and scales properly as packs get more complex. In summary, this kind of armchair engineering isn’t helping. It just drags us away from supporting customers and pushing the product forward. ---
**Author:** ![MultiThemes](https://dub1.discourse-cdn.com/flex005/user_avatar/forums.realmacsoftware.com/multithemes/32/25117_2.png) [@MultiThemes](https://forums.realmacsoftware.com/u/MultiThemes)\ **Post date:** [December 11, 2025, 2:06pm UTC](https://forums.realmacsoftware.com/t/fireflies/53072/42 "2025-12-11T14:06:48Z")
The limitations apply to devPacks, and I understand that, thanks But what about custom components? I’m doing a project for a client (my first freelance job with Elements!) and I’ve created several. They’re all within the project, and everything seems to work flawlessly. When the code is in the project, there shouldn’t be any limitations. Is that correct? Thanks ---
**Author:** ![dan](https://dub1.discourse-cdn.com/flex005/user_avatar/forums.realmacsoftware.com/dan/32/28516_2.png) [@dan](https://forums.realmacsoftware.com/u/dan)\ **Post date:** [December 11, 2025, 2:23pm UTC](https://forums.realmacsoftware.com/t/fireflies/53072/43 "2025-12-11T14:23:22Z")
In-app custom components are different and even if they weren’t, I’m 100% sure you’ll never hit 1024 files in your custom components 🤣 ---
**Author:** ![MultiThemes](https://dub1.discourse-cdn.com/flex005/user_avatar/forums.realmacsoftware.com/multithemes/32/25117_2.png) [@MultiThemes](https://forums.realmacsoftware.com/u/MultiThemes)\ **Post date:** [December 11, 2025, 2:27pm UTC](https://forums.realmacsoftware.com/t/fireflies/53072/44 "2025-12-11T14:27:19Z")
> [@dan](#): > > hit 1024 files in your custom components I don’t believe it either 🙂 but from what I understand, there are no problems or limitations, and this is important because it gives me the freedom to manage all my work with maximum privacy. Google tracking codes and meta, iframe etc, checks with external services, are sensitive data that I couldn’t share in a classic component. [Previous page](https://forums.realmacsoftware.com/t/fireflies/53072.md?page=2)