When Microsoft publicly released the initial version of the .Net Framework in February of 2002 things were pretty simple. .Net was .Net and assuming you were working in Microsoft technologies, you were either doing .Net or you weren’t. Today, things are not nearly that simple. There are a number of technologies that are forms of Microsoft’s .Net Framework including, .Net Core, Mono, Xamarin and of course the original .Net. These different flavors of .Net run on a wide range of platforms and device types and have come a long way from their Windows only origin. Unfortunately, being able to support a wide range of platforms and devices comes with a cost: complexity. If you think about it makes sense; after all, mobile phones are very different from full scale desktops which are different from Linux servers.
For a time the solution to this problem was Portable Class Libraries (PCLs). A simplified way to look at PCLs is by contrasting them to traditional class libraries. Where a traditional class library would have to target just one of the .Net frameworks, a PCL can target multiple. For example, if we wanted a library that could on Xamarin for iOS and Android, we’d have a PCL that would be configured like so in Visual Studio: 
As you can see it’s more or less trivial to add additional target platforms such as UWP for Windows or Xamarin for macOS during the PCL creation process. Once you have your PCL you simply use the assembly in your .Net project and it will work fine as long as your project targets the same or a compatible version of .Net (for example 4.5) and your project targets the platforms your selecting while creating the PCL. Not bad right? We’ll, actually there are some annoying issues that crop up when working with PCLs overtime and as the .Net ecosystem has expanded.
Microsoft realized that actually what they needed was a standardized version of .Net that would just run everywhere, so they released the aptly named .Net Standard. In simple terms, .Net Standard can be thought of as the shared foundation for all flavors of .Net that platform specific APIs can rest upon. This diagram of the .Net architecture using Standard lays it out perfectly: 
As you can see, all of the target platform specific APIs rest upon the bedrock of .Net Standard. This architecture is usable today and supported by default by a number of Visual Studio templates. For example, Xamarin cross platform app development project offer .Net standard and it’s now the recommended path forward according to Microsoft. The question is what have you gained by migrating or just starting out with .Net Standard. For starters, you’re using the technology that is going to be long-term supported and that Microsoft is most enthusiastic about. Additionally, you don’t have the hassle of having to deal with keeping PCLs in sync and up to date, something that can become a bit of time waster.
That’s it! .Net Standard is a standardized flavor of .Net that is compatible with all possible target platforms. Want to learn more about awesome stuff developed in .Net? Do you like cool fighter jets? Checkout our white paper on how we developed the first iPhone rear warning radar to ever fly using Xamarin.