Desde o inicio, o .NET tinha suporte de primeira classe de bibliotecas não gerenciadas. Usando um P/Inoke você pode acessar várias APIs Win32 e suporte COM abrindo aos desenvolvedores uma riqueza de aplicativos e bibliotecas de terceiros. Com os recentes avanços do Dynamic Language Runtime, scripts escritos em Python, Ruby, e JavaScript também entram no jogo.
Mas será que os desenvolvedores .NET realmente tiram vantagens disso? Clint Hill disse que não.
O trabalho foi ótimo e as ferramentas foram obtendo aperfeiçoamento constante. O .NET foi liberado e isso foi emocionante. Depois de seis anos se usa muito pouco. A cultura começou a ficar um pouco louca. Um dogma dessa cultura (eu uso dogma de forma superficial) foi que todos os componentes utilizados tinham que ser derivados dos materiais .NET. O que equivale dizer: Se você precisa de um controle de bibliotecas web tem que ser uma biblioteca C# .NET porque isso é o que você está usando para desenvolver o seu projeto. Se isso não estiver disponível, a um custo ou de graça, então desenvolva sua própria.
Existem alguns problemas por isso, o mínimo é que os projetos ficaram lentos e os prazos foram empurrados. O maior problema, entretanto é a idéia de que os desenvolvedores começaram a acreditar que outras tecnologias não eram aceitáveis. Independentemente de quão bem eles resolveram o problema. Hoje eu acho essa mentalidade muito decepcionante.
Clint fez estas declarações em resposta a um post de blog pelo popular autor Jeff Atwood. Jeff, junto do igualmente famoso Joel Spolsky, está atualmente trabalhando em um fórum conhecido como Stack Overflow. Quando se trata de otimizações HTML para seu site, Jeff empina o nariz dele para cada preexistência de bibliotecas. Seu motivo, porque eles não foram escritos em .NET.
Será que eu lamento de ter gasto uma solida semana desenvolvendo um conjunto funcionalidades de otimização HTML para o Stack Overflow? Nem um pouco. Existem muitas soluções de otimizações foras do ecossistema .NET, mas poucos preciosas para C# ou VB.NET. Eu já contribui com o código principal de volta para a comunidade, dessa forma futuros aventureiros .NET poderão usar nosso código e as sinalizações (ou sinais de aviso, dependendo do seu ponto de vista) sobre a sua própria jornada. Eles podem aprender de uma forma simples, demonstrando a rotina que nós escrevemos e continuar a usar o Stack Overflow todo dia.
Dare Obasanjo explica porque geralmente isso não é uma boa idéia:
O problema que o Jeff estava tentando resolver era como permitir a um subconjuntos de tags HTML enquanto eliminando todos o HTML restante de modo a prevenir a ataques cross site scripting (XSS). O problema da abordage do Jeff, como foi indicado nos comentários de várias pessoas incluindo Simon Willison é que usando regex para filtrar os dados de entrada do HTML desta forma assume que você receberá um HTML bem formado. O problema com esta abordagem que vários desenvolvedores aprenderam da maneira mais difícil é que você também tem que se preocupar com o HTML mal formado devido às políticas liberais de parsing de HTML de vários browsers web modernos. Assim para usar esta abordagem você tem que fazer engenharia reversa de todos os truques de parsers HTML dos browsers se você não quiser acabar armazenando HTML o que parece seguro, mas que atualmente contém uma falha de segurança. Assim para utilizar esta abordagem Jeff deveria usar um parser HTML maduro como o SgmlReader ou Beautiful Soup em vez de expressões regulares.
Este debate não é apenas sobre as otimização HTML, vai ao centro da cultura do .NET. Para desenvolvedores .NET, é apropriado não usar bibliotecas de terceiros no seu dia a da de trabalho?