This has been discussed on HN before and I remember talk about using "fancy" stuff like Bloom filters but as far as I know, no library offers anything for this out of the box and this is not something you want to roll yourself.
Which is fine and well. But how does that take revocation into account?
You can store a token on the client side, in ANY format. The problem remains that you're either storing some server-side state about that token, or you aren't. If you are, then you're not really using client-side sessions. If you aren't, then you still don't have a good way to revoke. Because you can't really control the client-side after you've issued a token, and you can't revoke it from the server-side without state.
I'm sure there are good arguments to be made against the use of JWT. But their simply aren't any to be found in this thread, and no alternative client-side proposal that solves the revocation problem.
Developers would like there to be one. Unfortunately, they've chosen a terrible standard --- just really, really bad --- to run with. You are better off doing something by hand than using JWT. If you're at all familiar with my ouvre on HN: that's how bad JWT is. I think you might seriously be better off DIY.