Firstly, the repeated Java Script delivery problem
The library that generates random numbers is bundled in your browser. However, the code that calls that library is delivered from network every time, e.g.
let iv = crypto.getRandomValues(new Uint8Array(blockSize));
This code depends on what the server yields for every connection. There is no audit trail to check how the program behaved in the past.
Secondly, passwords. When you're grandma-proofing your product, introducing a low entropy secret from which key is derived creates a weak link for the communications' key. Stretching the key with PBKDF2 doesn't really help because the initial entropy is so low.
Ideally you want very strong key stretching with memory hard hash functions like Argon2, and you'll want to target local encryption of strong random keys with the password, not the communications itself. This is why we want public key authentication for SSH server and no passwords. It's safer that the weak password stays on the user's device.
Lastly, encryption is about converting confidentiality problem into a key management problem. This application doesn't solve the key delivery problem, if exchanging a secret such as the password over e.g. a telephone line is what you need to do, you might as well use that line to exchange the super secret comms.
The author describes this as a hack, when in reality it's just a bad product that doesn't make it easy to automate best practices. I have much more trust in stuff like Signal that generates (and upgrades automatically) strong secrets, uses public key crypto, and allows authenticating key exchanges with values that are safe to say over even an eavesdropped channels.
There's even open source and reproducible builds. That stuff isn't grandma proof, but at least its researcher proof when there at least IS some audit trail.