Core: System.Text.Json is a waste of time.

[sujayvsarma]

I don't get why the .NET Core Json module (System.Text.Json) is modelled after the old Xml DOM pattern with objects like JDocument, JElement and so on. Of course, the complete absence of samples ref makes it impossible to see if there is a better way around.

If I was doing this, I would simply merge the hugely popular (and only used?) Newtonsoft.Json project into .NET Core itself. That way, you don't need to redo your documentation, you don't need to write new sample code, you don't need to a heck of a lot of things. The best thing would be that millions of developers who are currently using Newtonsoft.Json don't need to do anything other than change namespaces maybe!

Why is Microsoft over-complicating things?

[Szer]

and only used?

This is hugely opinionated because problems with Newtonsoft.Json are well known and plenty.
Performance is not that good too.

On the other hand, there are a bunch of popular serializers:

• https://github.com/neuecc/Utf8Json
• https://github.com/fsharp/FSharp.Data

[sujayvsarma]

@Szer : ".NET Core" by itself is a hugely opinionated library. So yes, my post was opinionated.

Both the problems you have referenced are not even "issues". The first one is by design and the second one can be changed by a simple option flag. I use the library (Newtonsoft.Json) quite heavily across multiple projects, even enterprise and cloud-scale applications and have zero problems with it [I am vociferous getting attention to issue I face, you are free to Google for what I've said about that library!].

[karelz]

System.Text.Json is still under construction. It is high-performance (no allocation) API. If you care primarily about dev usability, keep using other more user-friendly APIs like Newtonsoft.Json, etc.

cc @joshfree @ahsonkhan @steveharter

[KamranShahid]

I don't get why the .NET Core Json module (System.Text.Json) is modelled after the old Xml DOM pattern with objects like JDocument, JElement and so on. Of course, the complete absence of samples ref makes it impossible to see if there is a better way around.

If I was doing this, I would simply merge the hugely popular (and only used?) Newtonsoft.Json project into .NET Core itself. That way, you don't need to redo your documentation, you don't need to write new sample code, you don't need to a heck of a lot of things. The best thing would be that millions of developers who are currently using Newtonsoft.Json don't need to do anything other than change namespaces maybe!

Why is Microsoft over-complicating things?

You are making opinion when the thing was under implementation and not even releases 5 months back.
When there is something available in the framework then it obviously have performance gain rather then using external api for the same functionality. .net core 3. is released less then couple of week ago. Let's see the performance gains