Outra maneira de explicar a diferença poderia ser com exemplos do mundo real, já que a maioria de nós, mortais, usará ferramentas e estruturas existentes (Xamarin, Unity etc.) para fazer o trabalho.
Portanto, com o .NET Framework, você tem todas as ferramentas do .NET para trabalhar, mas só pode segmentar aplicativos do Windows (UWP, Winforms, ASP.NET etc.). Como o .NET Framework é de código fechado, não há muito o que fazer.
Com o .NET Core, você tem menos ferramentas, mas pode segmentar as principais plataformas de desktop (Windows, Linux, Mac). Isso é especialmente útil nos aplicativos ASP.NET Core, já que agora você pode hospedar o Asp.net no Linux (preços de hospedagem mais baratos). Agora, como o .NET Core foi aberto, é tecnicamente possível desenvolver bibliotecas para outras plataformas. Mas como não há estruturas que o suportem, não acho que seja uma boa ideia.
Com o .NET Standard, você tem ainda menos ferramentas, mas pode segmentar todas / a maioria das plataformas. Você pode segmentar os dispositivos móveis graças ao Xamarin e até os consoles de jogos graças ao Mono / Unity. Atualização: Também é possível direcionar clientes da Web com a plataforma UNO e o Blazor (embora ambos sejam um pouco experimentais no momento).
Em um aplicativo do mundo real, você pode precisar usar todos eles. Por exemplo, desenvolvi um aplicativo de ponto de venda que tinha a seguinte arquitetura:
Compartilhado servidor e cliente:
- Uma biblioteca .NET Standard que lida com os modelos do meu aplicativo.
- Uma biblioteca .NET Standard que lida com a validação de dados enviados pelos clientes.
Por ser uma biblioteca .NET Standard, pode ser usada em qualquer outro projeto (cliente e servidor).
Também é uma boa vantagem de ter a validação em uma biblioteca padrão do .NET, pois posso ter certeza de que a mesma validação é aplicada no servidor e no cliente. O servidor é obrigatório, enquanto o cliente é opcional e útil para reduzir o tráfego.
Lado do servidor (Web API):
Como isso é desenvolvido no .NET Core, eu posso hospedar o aplicativo em um servidor Linux.
Lado do cliente (MVVM com WPF + Xamarin.Forms Android / IOS):
Uma biblioteca .NET Standard que lida com a conexão da API do cliente.
Uma biblioteca .NET Standard que lida com a lógica ViewModels. Usado em todas as visualizações.
Um aplicativo .NET Framework WPF que lida com os modos de exibição WPF de um aplicativo do Windows. Atualização: os aplicativos WPF podem ser o núcleo .NET agora, embora funcionem apenas no Windows atualmente. O AvaloniaUI é uma boa alternativa para criar aplicativos Desktop GUI para outras plataformas de desktop.
Uma biblioteca .NET Standard que lida com as visualizações do Xamarin Forms.
Um projeto Xamarin Android e Xamarin IOS.
Assim, você pode ver que há uma grande vantagem aqui no lado do cliente do aplicativo, pois posso reutilizar as bibliotecas .NET Standard (Client API e ViewModels) e apenas fazer visualizações sem lógica para os aplicativos WPF, Xamarin e IOS.