I followed a lot of tutorials about the exploitation of UAF vulnerabilities, but there was never explained how to find and detect UAF vulnerabilities in JavaScript or HTML (i.e. with a static analysis).
My question is: how to reverse engineer JavaScript functions to see if an object was freed, by this function, and with which function I can use it again (after it was freed) to provoke a use after free issue?
Although JavaScript and HTML as languages are free from use-after-frees by design (due to the lack of low-level memory access), they can still be used to exploit UAF in the engines that interpret and run JavaScript/HTML.
This is how you find UAF vulnerabilities:
To get started, you can study public bug reports (e.g. Chrome's medium/high/critical severity bugs (severity guidelines), Firefox's high/critical bugs (severity guidelines), any CVE). JavaScript is a highly dynamic language, sometimes you can do things that the designers/implementers of a certain feature did not intend or expect, resulting in security vulnerabilities (e.g. a JSON serializer that did not account for the fact that custom callbacks can modify the input). Most of the bugs are not in the JavaScript engine itself, but in the implementation of the available APIs (e.g. DOM is not part of JavaScript).
If available, use AddressSanitizer because it makes it easier to detect and classify the type of memory bug. You can either build it from source, or use the pre-built binaries (see e.g. Firefox or Chrome).
Note: Finding the UAF is the easiest step, actually exploiting it is much more difficult. Modern programs use all sorts of preventive measures to counter vulnerabilities (e.g. ASLR, non-executable stacks, stack/heap protectors, and more).
Your question is incorrect on many levels.
First, JavaScript is memory managed language. That is, a developer never actually frees memory. Instead, the JavaScript interpreter manages all of that. So, if the JavaScript interpreter is written correctly, there can be no use-after-free vulnerabilities. As such, static analysis of JavaScript will never find a use-after-free vulnerability.
HTML doesn't really have a concept of memory management to even discuss use-after-free.
As far as reverse engineering JavaScript functions, that doesn't really make sense. JavaScript is not compiled so you always have the source available. Perhaps the JavaScript was obfuscated, but you still have the code, it's just hard to read.
