diff --git a/1-js/99-js-misc/07-weakref-finalizationregistry/article.md b/1-js/99-js-misc/07-weakref-finalizationregistry/article.md
index 777bf703ce..01e7c55922 100644
--- a/1-js/99-js-misc/07-weakref-finalizationregistry/article.md
+++ b/1-js/99-js-misc/07-weakref-finalizationregistry/article.md
@@ -469,6 +469,9 @@ Of course, it is important to remember, that such behavior is not guaranteed, an
 Based on this, a completely logical question immediately arises: why do not we use an ordinary cache, where we can manage its entities ourselves, instead of relying on the garbage collector?
 That's right, in the vast majority of cases there is no need to use `WeakRef` and `FinalizationRegistry`.  
 
+We use this approach when we suspect, as in this case, that memory management might be an issue, allowing for a more flexible and adaptable implementation.
+We don’t always manage manually because we no longer program for fixed hardware; we delegate to the engine, which adjusts behavior based on available resources. 
+
 Here, we simply demonstrated an alternative implementation of similar functionality, using a non-trivial approach with interesting language features.
 Still, we cannot rely on this example, if we need a constant and predictable result.
 
@@ -480,4 +483,4 @@ You can [open this example in the sandbox](sandbox:weakref-finalizationregistry)
 This is beneficial for addressing excessive memory usage and optimizing the utilization of system resources in applications.
 
 `FinalizationRegistry` - is a tool for registering callbacks, that are executed when objects that are no longer strongly referenced, are destroyed.
-This allows releasing resources associated with the object or performing other necessary operations before deleting the object from memory.
\ No newline at end of file
+This allows releasing resources associated with the object or performing other necessary operations before deleting the object from memory.