Em novembro de 2013, durante o MVP Summit nos headquarters da Microsoft em Redmond, a empresa mostrou para um público fechado uma ideia que estava nascendo. À época, com apenas duas semanas de vida, vimos um protótipo do que viria a ser uma revolução no .NET, o .NET Core: um renascimento da plataforma .NET, mais leve, mais rápida, open source e multiplataforma.

O restante do mundo conheceu o projeto em 12 de maio de 2014, no evento TechEd. No MVP Summit, assim como no TechEd, a novidade abalou as estruturas. Mercado e comunidade de desenvolvedores pararam para admirar o que estava se desenrolando diante dos seus olhos. Tudo parecia estar mudando. E estava. Naquele momento, foram anunciadas muitas possibilidades novas, e também surgiu muita confusão. A princípio, as mudanças não estavam totalmente claras. Hoje, três anos depois, já temos um panorama. Vamos analisar o que aconteceu – um pouco de história é sempre bom – e olhar para a frente, entender o que o futuro nos reserva.

Surgimento: .NET vNext e ASP.NET vNext

No anúncio que aconteceu no TechEd, o ASP.NET Core era chamado de ASP.NET vNext. Por um tempo depois do TechEd, ele também foi chamado de ASP.NET 5, já que o ASP.NET até então era o ASP.NET 4 (e continua sendo até hoje). Teríamos então nesse novo ASP.NET uma nova versão, mas não uma continuação plena, já que várias partes, como o WebForms, não estariam presentes.

À época, havia ferramentas de linha comando (Command Line Interface – CLI) chamadas “kvm”, e “k”. O kvm permitia escolher a versão do runtime, e o “k” era o responsável por rodar as aplicações. Tivemos alguns previews rodando no Visual Studio vNext (que viria a ser o Visual Studio 2015). Os projetos tinham a extensão “.kproj”, depois evoluindo pra “.xproj”, e agora caminhando para “.csproj”, a final. De “k”, fomos para “dnx”, e então “dotnet”, que é a CLI atual. Todo esse ferramental está estável, mas ainda está em movimento. A minha expectativa é de que até a metade de 2017 toda a plataforma se consolide de uma vez por todas. Desde o começo, a plataforma rodou tanto no Linux como no Mac e no Windows. Porém, ela ainda era alpha, com graus variados de suporte, desempenho e bugs em cada plataforma. Hoje ela está estável e roda bem.

Mudando o mindset

O novo .NET aproxima as suas outras plataformas. No mundo open source, que não era o do .NET (e agora é), a linha de comando era muito presente. O .NET Core traz o terminal para a frente, tornando-o cidadão de primeira linha na experiência. Também não há mais a necessidade do uso do Visual Studio. Editores de texto como Sublime, TextMate, Visual Studio Code ou até mesmo o Vim são escolhas para desenvolver aplicações com .NET Core e ASP.NET Core. Apesar de não ser obrigatório, o Visual Studio, agora também gratuito em uma série de cenários, continua funcionando perfeitamente. Caso não queira, o desenvolvedor que prefere Visual Studio jamais precisará ir à linha de comando, podendo trabalhar exatamente como trabalhava antes. É importante ressaltar que não há “pegadinhas”. Não há nada que seja possível somente no Visual Studio que não seja nos outros ambientes. Se você quiser ficar longe dele, é uma opção totalmente viável. A ideia é cada um trabalhar onde e como preferir.

O surgimento do .NET Standard

No Release Candidate 2, na metade de 2016, aconteceu uma guinada no projeto. As mudanças que apontei se consolidaram nessa versão, surgindo a primeira versão do .NET Standard – uma standard library que cumpre basicamente a mesma função que as stdlibs de outras linguagens e plataformas, como C++, Ruby, Go etc. O .NET Standard padroniza as APIs, que devem ser disponibilizadas por qualquer plataforma que deseje rodar componentes construídos para o novo .NET. A novidade é importantíssima porque retira do .NET a responsabilidade de torná-lo verdadeiramente multiplataforma, ainda que o .NET Core continue buscando rodar em diversos sistemas operacionais.

Além disso, o .NET Standard tem suporte no .NET Framework, que nasceu em 2002 e vem evoluindo até hoje (e que não vai parar de evoluir). Assim, um componente feito para o .NET Standard poderá rodar tanto no .NET Core quanto no .NET Framework. A forma anterior de deixar componentes portáveis, as Portable Class Libraries (PCLs), tornam-se assim menos interessantes. Conforme o suporte todo migra para o .NET Standard, em tempo deixaremos de vê-las. E se você já trabalhou com PCLs, sabe que isso é muito positivo. Afinal, elas resolvem em parte o problema de portabilidade, mas não sem alguma dor.

.NET everywhere… and fast!

O .NET hoje está encaminhado para rodar muito bem em qualquer lugar, seja com Linux, Mac, Windows ou outras plataformas – como aconteceu com o recente anúncio do suporte para Tizen, que vai permitir rodar .NET em televisões Samsung ainda neste ano. Acostume-se com a ideia de passar a ver .NET em roteadores wireless, Raspberry Pis, entre outros, além dos servidores Linux, Windows, Android, iOS, Xbox, Hololens e Windows Mobile. O .NET, no recente benchmark livre e independente da TechEmpower, está entre os 10 servidores mais rápidos do mundo, superando aplicações feitas com Python, Node.js, Ruby, Clojure, Rust, Haskell, entre outros (veja mais aqui). Isso é muito importante tanto para demandas muito grandes, como as que rodam na nuvem, onde cada ciclo de processamento reflete diretamente no custo final, quanto para demandas pequenas, como um Raspberry Pi, onde o desempenho pode ficar inaceitável com plataformas ineficientes.

O futuro

Passamos por diversos desafios devido à instabilidade do framework ainda muito imaturo, mas superamos. No começo, poucas bibliotecas suportavam o .NET Core. Com a aproximação do .NET Standard 2.0, esperado para entre março e junho deste ano, novos cenários se tornam mais fáceis. A entrega final do ferramental também vai trazer estabilidade à plataforma, junto com o lançamento do Visual Studio 2017.Enxergamos que 2017 será o ano da consolidação do .NET Core e do ASP.NET Core. Se você desenvolve software, é uma boa hora pra começar a se preparar.