Fireflies

Elements
41

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.

1 Like
42

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

43

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 :rofl:

44

I don’t believe it either :slight_smile: 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.