The older article about jspwgen is still mostly true. You can find it here.
There were several reason to update jspwgen:
The user interface of the old version was a bit intimidating. It printed diagnostic data in plain sight which was probably confusing for the casual user.
Furthermore, the algorithm always generated exactly the number of bits that the user requested. In the different password representations, these were always used up completely. This caused a problem. For example, the entropy of the 850 english words is around 9.73 bits per word, assuming a uniform distribution. When selecting a password strength of 128 bit, there would only be about 1.49 bits left for the last word, therefore the last word was always either "a," "able," "about" or "account". Similar effects were noticeable in the other formats.
This is rather undesireable. While the passwords were not weak as such (their entropy was quite exactly equal to the selected one) they revealed where they were generated, which could be used to intercept further password generation attempts. The site uses https, but in my experience the average user just clicks "Ok" on any popup they get, even if it is about a forged certificate. Practices like this one are not helping.
The interface has been cleaned up. Technically interested visitors can still look at diagnostical output (even more than before). The algorithm now also generates enough bits to have full entropy for every character or word in each of the different formats, at the cost of "throwing away" some bits of randomness. This is not a problem, however, as long as the input entropy is high enough, i.e. there are enough random points on the canvas.
A more serious (though, in my opinion, still not security-breaking bug) was that after some tests, i found that the pbkdf2 function was not working as expected. Specifically, the test vectors (unofficial, but apparently widely agreed upon, here) did not pass. After hours of testing i found that the version of sjcl that i had originally used (from their website) differed from the documentation - the salt was assumed to be binary, while jspwgen provided a string. This was fixed by downloading the sjcl version from github, where the implementation matched the documentation and the type of the salt is checked by sjcl, and a string-salt is converted properly.
I also read up on javascript "numbers" and discovered, to my horror, that the only data type for numbers that javascript knows is double. Whenever using "binary" operations, this has to be kept in mind (the double gets converted to a 32bit integer). There was a cornercase where this could lead to loss of a few random bits while converting the pbkdf2 output to a big integer, this should now be fixed.
Finally, a startup test was added. This checks for the most basic stuff, like the "integer" arithmetic of javascript working as strangely as it should and that the pbkdf2 test vectors pass.
Have fun generating passwords - if you use the site often I would encourage you to download it, of course it works entirely offline.