I'm impressed with the code I've seen so far. I've said before that we needed AppBase before SMTs, so while some people thought stuff like AppBase was a source of delay, I wanted people to know it was more like a prerequisite. Not just because of scalability, but because AppBase introduced the ability to express assets better than how Dan originally envisioned.
Forgive me while I geek out for a second (you can skip to the very last paragraph if this gives you a headache):
See, before we had to use 100.000 STEEM to represent an asset. But the blockchain doesn't know what a decimal number is (aka floating point). So 100.000 had to originally be represented in a string, which isn't a big deal in and of itself. But because 100.000 was already a string, Dan decided to also just append the symbol in the string, so it became 100.000 STEEM. Very awkward from a dev perspective.
AppBase came along, and changed the same 100.000 STEEM to:
{"amount": "100000", "precision": 3, "nai": "@@000000021"}
I know this looks worse to human eyeballs. But it's way more precise to devs. AppBase made this change and switched all internally stored assets to this format way before SMTs. But this is also now the exact same way an SMT asset is expressed (each SMT has a different nai code).
The upshot is that all sorts of existing operations we already have now support SMT. There's a lot of work that went into actually making these operations accept SMTs, but the nice thing about not having to change the asset format now is that the client tools that already work with AppBase do not have to be extensively redesigned in this cycle.