It's worth the work heading to System.Text.Json - even if only to make staying up with .NET easier for yourself.

It had a bit of a rough start but it seems far more interoperable on weird edge cases than Newtonsoft now, so all the "Newtonsoft-y" things you're doing might evaporate.

I've had the opposite experience. System.Text.Json adheres extremely close to the RFC and barely handles any edge cases. Newtonsoft will happily serialize invalid json. Not that you want that but if you have a legacy system it's not worth migrating. James Newton-King is a Microsoft employee btw.

Isn't Text.json also faster at this point because it uses all the new span goodness and the like?

I'm pretty sure it's been faster for as long as it's existed.

Turns out it's easy to be fast if you don't have any features.

Even better: it has an optional source generator now! So, at compile time, C# can be generated. This can be at two levels: (1) just generate metadata so runtime reflection is not needed, or (2) also generate code that does the serialisation or deserialization itself.

Pretty cool!

> but I already have all this code relying on Newtonsoft-y things :(

Welcome to the dungeon... Our jailer is polymorphic deserialization. We've got many gigabytes of Newtonsoft JSON in prod with that $type property throughout.

Any place I can use System.Text.Json I will, but there are a few legacy usages that absolutely won't work.

At this point, I'd like to rescind any expectation/desire for Microsoft to support polymorphic deserialization in their JSON library... It was a super powerful trick to get us to the next step, but it eventually turned into a nightmare for codebase maintenance.

Until we have this monster refactored, we won't be able to move most of our types into different namespaces or assemblies.