Ok, the idea in general isn't good because most people won't use a good password and also because now there's a single point of failure if someone sees your password.
However, it might be okay if one can provide their own hashing function. Like a JS function that takes the domain and secret key as parameters.
This is a technique that's been in use for about a decade (in GenPass and SuperGenpass). There are, in fact, flaws in an all JavaScript bookmarklet solution, as the site you're visiting can snoop your JavaScript data structures and could readily figure out your master password. This is resolved by use of a Google extension that does not share a JavaScript interpreter with the page you're visiting; and it's reportedly been fixed in the bookmarklet version of SuperGenPass though I haven't read it to see how it is resolved.
But, your suggestion of a JS function that take the domain and secret key is how the GenPass and SuperGenPass bookmarklets have worked for years (and the flaw in that method has only been fixed this year, I think).
not a huge one. Because now instead of testing just the common passwords, the cracker would just have to double the amount of work by testing their hashes.
Granted, fragmentation in this space is actually good for security, because now there are is a different hash for each password generating program.
Yes, you should not use this unless you are willing to memorize a strong secret key. There are warnings in the article, but perhaps it could have used a few more.
This is one of those "only use it if you know what you're doing" things.
However, it might be okay if one can provide their own hashing function. Like a JS function that takes the domain and secret key as parameters.