One of the strengths of JT65 and JT9 is that they are very sensitive, JT9 being slightly more so than JT65. However, each transmit or receive period is a minute. So it takes at least 4 minutes to complete a QSO. In many cases, the signal to noise ratio of stations is well above the minimum for a successful decode. So FT8 was designed for that, using 15 second periods rather than 1 minute. So one big advantage is that in many cases you can complete a QSO 4x faster with FT8 than JT65 or JT9.

Unfortunately, there’s a downside. Some JT65 and JT9 decoders, such as those in JTDX, are very good at decoding multiple replies to your CQ, even those on the same frequency (to the nearest Hz). It does this through multiple decoding passes where decoded stong signals are then deducted from the recorded data to expose weaker signals beneath. However, the same does not currently appear to be the case with the FT8 decoder in WSJT-X 1.8.0-rc1. So while you can see a reply on the waterfall, you often get no decode. This is particularly the case if your signal is strong at long distance and attracts multiple replies. Even with single replies, often decode fails despite a visible trace on the waterfall.

For working DX on 80m, I’ve found JT65 and JT9 is much better than FT8, being able to decode signals only just faintly visible on the waterfall. So which data mode you should use depends on what you are trying to achieve. For faster QSOs with decent strength signals where multiple repies are not the norm, then FT8 is a better choice. But for working DX with marginal signals, where your patience might be better rewarded, JT65 and JT9 might be better.