Em novembro de 2013, durante o MVP Summit no headquarters da Microsoft em Redmond, a Microsoft mostrou para um público fechado uma ideia que estava nascendo. À época, com apenas 2 semanas de vida, vimos um protótipo do que viria a ser uma revolução no .NET. Nascia, diante de nós, o que seria depois chamado de .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, 3 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 a ser 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, com suporte profissional da Microsoft nas três tecnologias.

Mudando o mindset

O novo .NET aproxima as outras plataformas do .NET. 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. A instalação no Linux é tão simples quanto rodar um “apt install”. A integração com outras ferramentas de linha de comando também não é mais dolorida. Trabalhar com Gulp, Yeoman, NPM etc. é algo muito simples.

Também não há mais a necessidade do uso do Visual Studio. Editores de texto como Sublime, TextMate, Visual Studio Code (também da Microsoft, free e open source), ou até mesmo o Vim, são excelentes escolhas para desenvolver aplicações com .NET Core e ASP.NET Core.

O Visual Studio, agora também gratuito em uma série de cenários, segue sendo a ferramenta premium para o desenvolvimento. Apesar de não ser obrigatório, 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 nesta 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, hoje qualquer um pode pegar as APIs do .NET Standard e implementar para sua plataforma, porque qualquer componente que funcione no .NET Standard também vai funcionar.

Além disso, o .NET Standard também 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 ao 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 que já estamos acostumados.

Tudo isso agora com um desempenho incrível. O .NET, no recente benchmark livre e independente da TechEmpower, se colocou entre os dez servidores mais rápidos do mundo, superando aplicações feitas com Python, Node.js, Ruby, Clojure, Rust, Haskell, entre outros (veja mais em http://bit.ly/netcorebenchmark). Isso é muito importante tanto para demandas muito grandes, como as que rodam na nuvem, onde cada ciclo de processamento reflete diretamente no custo final; como para demandas pequenas, como um Raspberry Pi, onde o desempenho pode ficar inaceitável com plataformas ineficientes.

O futuro

Em novembro de 2015 a Lambda3 começou seu primeiro projeto de ASP.NET Core, ainda no beta4, utilizando um preview do Visual Studio 2015. O projeto, trabalhado com desenvolvimento ágil e muitos testes, durou dois anos e foi um sucesso. Passamos por diversos desafios devido à instabilidade do framework ainda muito imaturo, mas superamos. De lá para cá, todo ficou mais fácil, e quase todos os nossos projetos de .NET saem com o Core.

No começo poucas bibliotecas suportavam o .NET Core. Com a aproximação do .NET Standard 2.0, esperado entre março e junho deste ano, o suporte está crescendo e novos cenários se tornam mais fáceis. A entrega final do ferramental também vai trazer estabilidade à plataforma, junto ao 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. Se você demanda projetos, vale a pena considerar não mais iniciar projetos com ASP.NET 4 ou .NET Framework, dando preferência às novas plataformas. Já passamos o momento de early adoption, é hora de entrar. Precisando de apoio, não deixe de nos contatar. Somos a única consultoria que desenvolve com .NET Core há mais de dois anos.

(Artigo publicado também na edição #21 da revista iMasters, que pode ser lida gratuitamente online.)

Giovanni Bassi

Arquiteto e desenvolvedor, agilista, escalador, provocador. É fundador e CSA da Lambda3. Programa porque gosta. Acredita que pessoas autogerenciadas funcionam melhor e por acreditar que heterarquia é mais eficiente que hierarquia. Foi reconhecido Microsoft MVP há mais de dez anos, dos mais de vinte que atua no mercado. Já palestrou sobre .NET, Rust, microsserviços, JavaScript, TypeScript, Ruby, Node.js, Frontend e Backend, Agile, etc, no Brasil, e no exterior. Liderou grupos de usuários em assuntos como arquitetura de software, Docker, e .NET.