For read-only properties/fields, the useful pattern for Newtonsoft is to just provide a parametrized constructor. There are multiple ways to implements this and

For read-only properties/fields, the useful pattern for Newtonsoft is to just provide a parametrized constructor. There are multiple ways to implements this and all of them are well documented. When it comes to performance - are you sure your code doesn't do anything that pessimizes it? Regular JsonConvert.Serialize/.Deserialize work well and are reasonably fast. Obviously, if you use a lot of custom contract revolvers with heavy uncached reflection and large allocations, it will destroy the performance but almost no library can fix bad user-provided implementations, best case is to design API in a way that will nudge towards efficient patterns but that's it. Keep in mind that assumptions, especially brought from different languages, may cause a user to unnecessarily shoot themselves in the foot, especially when they are solved by spending 15 minutes to go over suggested usage patterns in the documentation. In addition, I think it is counter-productive to judge a completely unrelated Json library in BCL by your experience on a limited scenario with Newtonsoft where its defaults were simply different from expectations. The criticism listed is applicable to software that was released about a decade ago, on a platform with features (GAC) that have long become legacy. (e.g. GAC is a very old feature, .netfw 4.6.2 was released 8 years ago, Newtonsoft 9.* - 6 years ago, etc.) I'm not saying all libraries are perfect, but experimenting with implementations in Rust, Java and Swift left me with impression that C# packages are solid and relatively easy to use even not the most popular ones, and DOM-like JObject/JToken were quite nice to use too for untyped payloads. Last but not least, during the days of .NET Framework, the fastest implementation was Utf8Json losing only to optimized binary serializers which had to perform less work, it was nowhere near as popular or as feature-rich as Newtonsoft but in performance-sensitive scenarios it was very nice due to pooling internal buffers, emitting efficient IL stubs for serialization and using many other tricks to reduce overhead as much as possible. Anyway, Utf8Json is sadly deprecated but STJ provides very good performance OOB and if you need even more, SpanJson and SimdJson can give you even better numbers, enjoying newer perf-focused features of the language and research done on JSON serialization. .NET today is much, much better and very different from .NET Framework of 10 years ago. Saying otherwise is not much different behavior from the people who keep yelling "msft bad, closed source windows only garbage!" for whatever reason.