The Great .NET Client Divide: A Simple Example (Hopefully)

by Mike-EEE

TL;DR: Vote! ^

I have been getting some good feedback on writing lengthy blog articles. Right right. I try to be aware and respectful of your time.  And mine, too. At the end of the day I am just some random developer that you don’t know who happens to put their thoughts on the web — and I try to keep that in mind.  Additionally, I simply hate writing and hate writing long articles even more, so your guess is as good as mine as to why I put myself (and you, the patient reader) through so much agony. With that said, let’s see if I can keep this short.  Please vote:

What Is It Now? ^

I have been checking out some awesome logging software lately, namely Serilog and a (just as awesome) complimentary logging presentation component, Seq. I have to say that Serilog is the real deal. Just look at all these sinks, JUST YOU LOOK AT THEM! That is some serious business. You can also use an amazing configuration fluent API which just might change the way I approach all my future solutions — I’ve seen fluent, but not like this.  This means something, this is important!

So What Is the Problem? ^

Serilog is an awesome .NET logging solution.  It will work in a .NET application on the server (where you can also use in conjunction with Seq), and it will work in a WPF application or even WinForms application (again, with Seq).  It will work in a Console Application (with Seq), and there is even an effort to allow it to work in a .NET Core application (Seq TBD).


I as a .NET developer can use Serilog in all of the aforementioned application types, but if I follow Microsoft Leadership’s guidance and use a NodeJS application on top of a .NET server application, I cannot use Serilog as it does not have an official JavaScript port.  I can use an unsupported version that is “like” it (and it doesn’t even feature the same name), but it is not following the same version (or capability) cadence — and let’s not forget I want to preserve the Seq awesomeness!

Ahhhhhhh…  I get it. ^

Am I interviewing myself again?  I hate when that happens.  Anyways, to “fix” this problem, Serilog must either create a feature parity and version-synchronized JavaScript API (like a major product), or I as a developer must look for another equivalent of Serilog in the JavaScript/NodeJS ecosystem — written by a completely different developer (or developers) with a different style and approach and having to context-switch between the two (JavaScript and .NET).  In either case, this is additional (read: A LOT OF) work and the resulting solution will end up having two “Serilogs” which essentially breaks encapsulation and DRY.

Worse Yet ^

Even worse, I can choose to ditch .NET altogether and simply use a NodeJS JavaScript solution for client and server applications as this design features code reuse between the two tiers.



WHEW!  Please Vote ^

I actually got this in at a little over 550 words.  Not bad.  If you would like to see a JavaScript version of Serilog (and any .NET library, for that matter) seamlessly transpiled for any .NET project at compile time as part of a ubiquitous .NET client application development model offering, please tell the Visual Studio team you would like to see this magic happen by voting for this issue right here:

  • Ed Price aka User Ed

    Great point. I love how this is tied to the VS UserVoice feedback site. Thanks, Mike!

    • Thank you, Ed. Much appreciated!