7 days of WordPress plugins, themes & templates - for free!* Unlimited asset downloads! Start 7-Day Free Trial
Advertisement
  1. Code
  2. Editorials

Por qué muchos desarrolladores odian ASP.NET... y por qué se equivocan

Scroll to top
Read Time: 19 mins

Spanish (Español) translation by Steven (you can also view the original English article)

Pocas plataformas atraen la misma cantidad de ira que ASP.NET (o .NET en general) de la comunidad de desarrollo. Si bien ciertamente hay críticas válidas a la plataforma (¿qué plataforma no las tiene?), la mayoría de la negatividad proviene de aquellos que no han pasado ningún tiempo con .NET. Esos desarrolladores generalmente se basan en conceptos erróneos o en el odio absoluto para basar su opinión, y no hacen ningún favor a otros que buscan aprender una nueva tecnología y a la plataforma en sí. Por lo tanto, examinemos estas excusas y agreguemos una dosis de realidad sobre por qué no deberías escuchar a la chusma y darle una oportunidad a ASP.NET.


Está hecho por Microsoft

Esta es probablemente la razón #1 de todo el odio hacia ASP.NET.

Microsoft es una corporación de software masiva y, como todas las demás corporaciones, están en el negocio para ganar dinero. Es claro, ¿verdad? Desafortunadamente, esta es probablemente la razón número uno de todo el odio de ASP.NET: es una tecnología de Microsoft, y la mancha "malvada" aún persiste sobre el gigante en la mente de muchas personas. Siempre me ha parecido interesante esto porque las otras grandes empresas de tecnología, como Google y Apple, son tan "malvadas" como Microsoft, pero los fanáticos de esas otras compañías generalmente hacen la vista gorda (o niegan) esos "males". Personalmente, creo que la mayoría de las personas son personas de mentalidad normal. Realmente no les importa quién fabrica un producto siempre que ese producto funcione bien.

Pero no estoy hablando de gente normal, ¿verdad? La gente normal no ve un título que contenga "ASP.NET" y tiene la necesidad automática de hacer un comentario estúpido. En cambio, estoy hablando de los desarrolladores (y geeks) que tratan la tecnología, y/o la empresa que la crea, como una religión. No estoy bromeando, encuentra cualquier artículo o tutorial en la plataforma X, y es muy probable que encuentres comentarios que digan "¡X apesta! ¡Reglas de Y! "

Es como si estas personas estuvieran en una cruzada extraña para defender a su empresa/tecnología elegida hasta la empuñadura y golpear a la competencia en un intento de atraer a las masas sucias a su redil.

Es triste que exista la mentalidad tecnología = religión. La tecnología es una herramienta justa, y un desarrollador real probará varias herramientas para encontrar la adecuada para el trabajo. Eso no quiere decir que a alguien no le pueda desagradar una tecnología, pero, haciendo eco a nuestros padres, "no sabes que no te gusta hasta que la pruebes". Para que a alguien realmente le disguste algo, esa persona tiene que intentarlo. Así que no escuches a la chusma: No lo han intentado y no se han formado una opinión informada. Si decides que quieres probarlo, intentarán disuadirte diciendo que cuesta demasiado.


Concepto erróneo: Es caro

Encuentra cualquier artículo que compare ASP.NET con cualquier otra plataforma, y leerás, ya sea en el artículo o en los comentarios, "ASP.NET cuesta más que [inserta cualquier otra tecnología del lado del servidor que no sea ColdFusion aquí]". Antes de discutir el costo real de algo, es importante poner el término "caro" en contexto, ya que lo que es caro para uso personal puede considerarse barato en un entorno empresarial. En los negocios, hay muchos factores que componen el "costo" de un producto. El precio inicial obviamente debe tenerse en cuenta, pero el beneficio del producto también se tiene en cuenta en el costo total.

Si un producto cuesta $10,000 dólares, pero le ahorra a la compañía $1,000 dólares al mes, la decisión de compra es una obviedad. Pero a nivel personal, es más que probable que sea difícil justificar el costo inicial de $10,000 dólares.

Entonces, cuando se habla de costos, es importante mantener las cosas en perspectiva de acuerdo con el contexto en el que se incurrirá. Para simplificar las cosas, voy a suponer que si estás leyendo esto, estás más preocupado por el costo personal que por el costo comercial (si me equivoco con esa suposición, te lo haré muy fácil: Si tienes un entorno Windows, ASP.NET es barato).

En realidad, no necesitas Windows para desarrollar aplicaciones ASP.NET, gracias al proyecto Mono.

Eliminemos el mayor costo: El sistema operativo Windows. En realidad, no necesitas Windows para desarrollar aplicaciones ASP.NET, gracias al proyecto Mono (más sobre esto más adelante), pero Mono típicamente está por detrás del Framework .NET oficial que sale de los hornos de Microsoft. Por lo tanto, si deseas todas las funciones más recientes y las bondades de .NET, necesitarás Windows. La mayoría de los OEM (empresas como Dell, HP, Acer, etc.) envían sus computadoras con Windows ya instalado; por lo tanto, si compras tu computadora en una cadena de tiendas de electrónica como Best Buy, es muy probable que la computadora tenga Windows. Si eres más un usuario avanzado y construyes tus propias computadoras o planeas ejecutar Windows en una máquina virtual, tendrás que comprar una copia de Windows. Una versión OEM de Windows te costará entre $99 dólares y $189 dólares, dependiendo de la versión de Windows que compres. No necesitas tener Professional ($139 dólares OEM) o Ultimate ($189 dólares OEM), pero si eres un usuario avanzado, lo más probable es que desees optar por una de esas dos versiones (las versiones OEM son más baratas que las versiones minoristas, pero están vinculadas al hardware en el que las activas).

Costos de desarrollo

Con eso fuera del camino, revisemos los costos de desarrollo. Se cree que el desarrollo en ASP.NET es caro por dos razones:

  1. Es Microsoft. Supuestamente no dan nada gratis, pero eso es exactamente lo que hacen. Todo lo que necesitas para desarrollar aplicaciones en ASP.NET (o aplicaciones .NET en general) se puede obtener sin gastar un centavo.

    Principiantes: Primero, Microsoft regala WebMatrix, un entorno de desarrollo dirigido a principiantes. Combina un entorno de desarrollo integrado (IDE) con un servidor web integrado (IIS Express) y un motor de base de datos (SQL Compact Edition). También tiene herramientas para ayudar a los usuarios a implementar sus sitios web en un host remoto.

    Usuarios avanzados: Para desarrolladores más avanzados, Microsoft pone a disposición las ediciones Express de Visual Studio. Al igual que WebMatrix, estas versiones reducidas de Visual Studio son gratuitas, pero ofrecen algunas de las características y capacidades que se encuentran en las versiones completas de Visual Studio. El producto Express centrado en la web es Visual Web Developer Express (VWD) y también tiene un servidor web integrado. No tiene un motor de base de datos integrado, pero Microsoft regala SQL Server Express, una versión reducida de SQL Server, que puedes usar para el desarrollo (e incluso en algunas situaciones de implementación). Si luego decides que te gusta Visual Studio y deseas comprar la versión completa, los proyectos que desarrollaste con VWD se pueden abrir con Visual Studio.

    Estudiantes: Y si eres estudiante, puedes obtener una gran cantidad de software de Microsoft (Visual Studio Pro, Sistemas Operativos de Windows Server y Expression Studio, por nombrar solo algunos) de forma gratuita a través del programa DreamSpark.

  2. En segundo lugar, se cree que el alojamiento basado en Windows es mucho más caro. Hace diez años, ese argumento tenía algo de peso. Sin embargo, hoy en día no puedes encontrar escasez de alojamiento a precios razonables para ASP.NET. DailyRazor (la compañía que uso) comienza con planes a $2 dólares por mes, y puedes encontrar otros proveedores de alojamiento que vendan sus servicios a precios bajos.

Por lo tanto, el costo no es realmente un problema, pero los detractores dirán que ASP.NET solo es adecuado para sitios web de clase empresarial en lugar de sus sitios personales.


Concepto erróneo: Es horrible para sitios web pequeños y personales

Uno sólo tiene que mirar la biblioteca de clases del Framework .NET para tener la sensación de que "esto es para empresas".

En realidad, es fácil tener la mentalidad de que ASP.NET no es adecuado para nada más que sitios a gran escala. Microsoft es una empresa de plataformas, después de todo, y sus productos se centran principalmente en soluciones empresariales. .NET no es realmente diferente en ese sentido; es enorme en los entornos empresariales y su presencia continúa creciendo a medida que Microsoft expande productos nuevos y revitalizados como Azure (la plataforma en la nube de Microsoft) y Windows Phone, respectivamente. Uno sólo tiene que mirar la biblioteca de clases del Framework .NET para tener la sensación de que "esto es para empresas". Es casi como si el framework guiara a los desarrolladores a una mentalidad de que las aplicaciones .NET (ASP) deben ser obras maestras altamente estructuradas de diseño orientado a objetos. Gran parte de .NET es complejo y hacer cosas simples no siempre es tan simple como debería ser. Parece que estoy defendiendo el caso del detractor, ¿no es así? En cierto modo lo hago, pero hay dos cosas a considerar.

Simplicidad

Primero, Microsoft quiere que desarrolles en su plataforma, y han reconocido que necesitas algo (quizás mucha) simplificación para crecer. Después de todo, PHP es tan popular como lo es específicamente debido a su simplicidad, y esa es la razón principal por la que Microsoft lanzó WebMatrix: Ofrecer a los nuevos desarrolladores (ya sea para el desarrollo .NET o el desarrollo web en general) un enfoque simplificado para escribir sitios con ASP.NET.

El IDE todo en uno no solo es fácil de usar, sino que Microsoft creó una API simplificada para hacer que el desarrollo de ASP.NET sea más fácil y menos complejo.

Enfoques múltiples

También puedes crear sitios con el mismo tipo de mentalidad de "scripting" que prospera en PHP.

En segundo lugar, no tienes que caer en la mentalidad de "altamente estructurado o morir". Hay muchos enfoques para el desarrollo de ASP.NET. Si deseas crear obras maestras altamente estructuradas de diseño orientado a objetos, puedes hacerlo. Pero también puedes crear sitios con el mismo tipo de mentalidad de "scripting" que prospera en PHP. El punto es que el desarrollo de ASP.NET es lo suficientemente flexible para adaptarse a tus necesidades, y puedes elegir el enfoque de desarrollo que mejor te beneficie.

Por extraño que parezca, existe una idea algo frecuente de que ASP.NET no es adecuado para sitios web de clase empresarial. o.0


Concepto erróneo: Es horrible para sitios web grandes de clase empresarial

Honestamente, no tengo idea de dónde viene esto porque, como se mencionó anteriormente, ASP.NET sobresale en el espacio empresarial. Pero no te limites a creer en mi palabra; examinemos un sitio web del mundo real (bueno, una red de sitios web) que se ejecuta en ASP.NET.

¿Alguna vez has oído hablar de StackOverflow.com? Probablemente sí, y si no es así, es un sitio web de preguntas y respuestas para desarrolladores (independientemente de la tecnología). Es un recurso invaluable, y me encuentro visitándolo con bastante frecuencia.

StackOverflow es miembro de Stack Exchange Network, una red de sitios web de preguntas y respuestas sobre una variedad de temas: servidores, bases de datos, legos, ciencia ficción, automóviles, etc. Actualmente hay 71 sitios en la red y continúa creciendo.

La gente de Stack Exchange Network es bastante abierta sobre su red. Gran parte del código que se ejecuta en el sitio es de código abierto y, a menudo, proporciona información sobre la red en general. En una publicación de blog de marzo de 2011, Kyle Brandt proporcionó una descripción general de la tecnología que impulsa la red Stack Exchange Network, así como el tráfico que recibe la red. Ten en cuenta que esta información se refiere a toda la red Stack Exchange. Obtiene 95 millones de páginas vistas al mes y maneja 800 solicitudes HTTP por segundo, y esas solicitudes son manejadas por doce (sí, solo doce) servidores web Windows, dos servidores MS SQL Server, dos balanceadores de carga Linux y dos servidores de almacenamiento en caché Linux (las fallas del hardware no están incluidas en ese recuento).

Vuelve a leer esas estadísticas, esperaré. Fenomenal, ¿verdad? Es sorprendente que solo doce servidores, que prestan servicios a muchos sitios web diferentes, manejen esa cantidad de tráfico. Es un testimonio de lo buena que es la arquitectura de aplicaciones y servidores de Microsoft.


Está escrito estáticamente

Los lenguajes dinámicos gobiernan la web. Ya sea en el lado del servidor, donde viven lenguajes como PHP, Ruby, Python y Perl, o en el navegador con JavaScript, los lenguajes dinámicos son la columna vertebral de la web. No es que estos lenguajes sean mejores, pero se adoptan rápidamente porque los lenguajes dinámicos suelen ser más fáciles de aprender y comprender que los lenguajes de escritura estática.

Por lo tanto, esencialmente terminamos en una comunidad masiva de desarrolladores que solo han usado lenguajes dinámicos, y esa comunidad casi que tiene aversión a los lenguajes estáticos.

Entiendo completamente la mentalidad. Yo solía ser una de esas personas y comprendo el deseo de permanecer dentro de la zona de confort. Después de todo, los lenguajes dinámicos son indulgentes y hay algo de consuelo en esa indulgencia.

Los lenguajes estáticos tienen un sistema de tipos estricto.

Pero hay un lado malo en esa indulgencia; es muy fácil introducir errores en tu aplicación si no tienes cuidado. Por lo general, no encontrarás ese error hasta el tiempo de ejecución, y una causa común de errores es la asignación de un tipo de valor diferente e involuntario a una variable crítica. Aquí es donde entra en juego el beneficio principal de los lenguajes estáticos: seguridad en los tipos de variable. Los lenguajes estáticos tienen un sistema de tipos estricto, en el que una variable solo puede contener un tipo de valor (por ejemplo: una variable declarada como un número entero solo puede contener valores enteros; no puede contener una cadena o números de coma flotante). Si asignas por error una cadena a una variable numérica, sabrás inmediatamente del error cuando compiles el código porque el compilador se detiene y te alerta sobre el error.

La seguridad de tipos también puede aliviar la verificación de tipos que necesitas realizar en lenguajes dinámicos. Por ejemplo, ¿cuántas veces has escrito código como el siguiente para asegurarte de que los datos que acepta una función sean del tipo esperado?

Esta es una función PHP simple que suma dos números. Para garantizar resultados predecibles, es imperativo verificar si los valores proporcionados son del tipo apropiado (es cierto, la verificación de tipos aquí no está completa; hay tipos numéricos distintos de los enteros); de lo contrario, tu aplicación podría fallar en momentos inesperados. Por el contrario, veamos el código equivalente de C#:

Este código define un método add(). C# es el lenguaje .NET más popular y está puramente orientado a objetos. No hay funciones; solo métodos de una clase. Este método acepta dos valores enteros (indicados por la palabra clave int antes de los identificadores a y b), y devuelve un valor entero como lo indica el int antes de add. Debido a que C# es un lenguaje estático, la verificación de tipos la realiza el compilador, no tú. Por lo tanto, si llamas a este método, pasas una cadena como uno de los argumentos, como add("hola", 123), e intentas compilar el código, el compilador detendrá el proceso de compilación y te avisará del error. Sin embargo, es probable que ni siquiera intentes compilar el código porque Visual Studio realiza su propia verificación de tipo y sintaxis; el IDE te advertirá de los errores incluso antes de que intentes compilar (consulta la captura de pantalla de Visual Studio 2010 a continuación).

También considera que Microsoft actualiza y mejora continuamente el lenguaje C#. En las dos primeras versiones del lenguaje, tenías que identificar el tipo de una variable al declararla así:

Este código crea una instancia de la clase XmlDocument declarando su tipo antes del nombre de la variable. Es cierto que esta sintaxis es bastante engorrosa y agrega mucha más escritura, pero a partir de C# 3.0, sin embargo, puedes simplemente usar la palabra clave var para definir una variable, como esta:

Hay versiones de PHP, Ruby, Python y PERL habilitadas para .NET.

El compilador es lo suficientemente inteligente como para inferir que la variable document es un XmlDocument. Esta sintaxis difumina la línea entre lenguajes dinámicos y estáticos. Obtienes declaraciones de variables simples y sin tipo con los beneficios de la seguridad de tipos... un beneficio mutuo en mi libro.

Pero si aún no puedo persuadirte de que pruebes C#, los sitios ASP.NET no tienen que estar escritos en C# (o incluso VB.NET... pero ¿quién querría hacer eso?). Hay versiones de PHP, Ruby, Python y PERL habilitadas para .NET (y otras) con las que puedes escribir sitios ASP.NET, y son tan dinámicas como de costumbre gracias al Dynamic Language Runtime, una característica de .NET 4. Entonces, si bien recomiendo a cualquiera que elija ASP.NET para aprender C#, no tienes que abandonar tu zona de confort si no lo deseas (pero si lo haces, los beneficios valen la pena).


Es compilado

Los mismos lenguajes dinámicos que gobiernan la web también se interpretan, y hay un cierto beneficio que viene con los lenguajes interpretados. A diferencia de los entornos compilados como ASP.NET, donde normalmente escribes tu código, lo compilas y lo cargas, los entornos interpretados te permiten simplemente escribir tu código y cargarlo. La idea común es que los entornos compilados requieren un paso adicional en el desarrollo y eso es una pérdida de tiempo. Pero realmente no es así. El compilador nos brinda muchos beneficios que simplemente no puedes obtener en un entorno de lenguaje interpretado.

Primero, el compilador verifica el código y puede darte advertencias. Las advertencias son solo eso: Una advertencia. Es algo que has hecho que puede ser un error, pero no impedirá que el compilador compile tu código. Veamos el siguiente código que causaría una advertencia:

Este código define un método llamado DoSomething(). Su cuerpo crea dos objetos de tipo string, foo y bar, y foo se devuelve a quien lo llama. La variable bar no se usa, por lo que el compilador emitiría una advertencia indicando que bar está asignada pero su valor nunca se ha usado. Puede ser que creé bar y me olvidé de ella, o que terminé por no necesitarla. Pero podría ser la fuente de un error si olvidé que bar ya existía y la usé en otra parte del método. El compilador me llama la atención para que pueda solucionarlo y evitar errores en el futuro. Aquí hay una captura de pantalla de lo que me dice Visual Studio:

¿Quieres otro ejemplo? Aquí lo tienes:

En esta definición del método, una variable booleana, foo, y definida como true. Luego se usa en una instrucción if, donde se le asigna un valor de false. Eso puede ser exactamente lo que pretendía (aunque diría que nunca deberías hacer eso), pero es probable que me refiera a foo == false (sí, el operador lógico ! no estuviera mejor aquí... pero no funciona para mi ejemplo). Sin embargo, no es un error, por lo que el compilador hará su trabajo. Sin embargo, emitirá una advertencia preguntando si quise decir == en lugar de =. Estos son problemas que he encontrado en un entorno interpretado, pero habría tenido que ejecutar la aplicación y probarla para encontrar esos errores.

En segundo lugar, el compilador comprueba si hay errores en el código. Naturalmente, un compilador no puede detectar errores lógicos, pero puede escribir 'check' y verificar la sintaxis del código. Aunque, un IDE decente hará estas cosas por ti sin necesidad de un compilador, y Visual Studio lo hace.

Por último, obtienes un aumento de rendimiento. El código compilado se ejecuta más rápido de lo que se interpreta. Es cierto que .NET no es un entorno verdaderamente compilado. Nuestro código se compila en un lenguaje intermedio (IL), que luego es compilado justo a tiempo por el tiempo de ejecución de .NET. Sin embargo, IL está optimizado y el tiempo de ejecución de .NET lo ejecuta. Pero sigue siendo muy rápido.

De hecho, el rendimiento bruto de ASP.NET es más rápido que el de PHP.


Concepto erróneo: Es cerrado

Microsoft hace que el código fuente del Framework .NET esté disponible de forma gratuita.

Microsoft es una empresa que vende software y, naturalmente, protege mucho el código fuente de sus productos. Entonces, uno podría pensar que ASP.NET (y .NET en general) es de código cerrado, pero ese no es el caso. Microsoft hace que el código fuente para el Framework .NET esté disponible de forma gratuita y tú puedes ingresar al código mientras depuras tus propias aplicaciones. Incluso puedes crear tu propia versión personal del Framework .NET.

Microsoft también te brinda acceso al código fuente de las versiones ASP.NET, como WebForms y MVC, a través de CodePlex; dándote la posibilidad de probar nuevas funciones y proporcionar comentarios al equipo de ASP.NET. Animo a todos los desarrolladores que utilizan .NET a descargar estos recursos gratuitos y estudiarlos. Obtendrás una mayor comprensión de cómo funciona bajo el capó y podrás aplicar ese mismo conocimiento al escribir tu propio código.


Disponible sólo para Windows

La apertura de Microsoft con el Framework .NET es lo que ayudó a crear el proyecto Mono, una versión multiplataforma del Framework .NET. Si bien Mono no cuenta con el respaldo oficial de Microsoft, el proyecto ha sido reconocido públicamente por Microsoft. Mono no va a desaparecer; de hecho, está creciendo en popularidad independientemente de cuál sea tu plataforma favorita, probablemente puedas usar el Framework .NET y C# para escribir aplicaciones (¡incluso puedes escribir aplicaciones en iOS con Mono!).


No tiene demanda

Por último, a menudo se defiende que ASP.NET no tiene demanda, y eso simplemente no es cierto. La demanda es algo subjetiva porque diferentes áreas del mundo y en el país donde vives tienen diferentes mercados laborales. A todos los efectos, .NET ha sido la plataforma de desarrollo para entornos de Microsoft Windows (tanto para el escritorio como para la web) durante los últimos diez años.

La mayor parte del software desarrollado para Windows utiliza el Framework .NET, por lo que existe una gran oportunidad para que los nuevos desarrolladores de .NET encuentren trabajo.

El proyecto Mono también influye en la demanda. Mono es enorme y la comunidad es cada vez más grande. Con su amplia gama de compatibilidad con sistemas operativos, puedes escribir aplicaciones para cualquiera de los grandes sistemas operativos, incluidos los dispositivos móviles. ¡Hay muchas oportunidades, independientemente del sistema operativo!


Conclusión

Entonces, ¿dónde nos deja esto? Bueno, los que odian y los detractores están equivocados, y ASP.NET es una tecnología que debes probar y conocer. Después de todo, los desarrolladores exitosos son políglotas, capaces de escribir aplicaciones en diferentes lenguajes para diferentes plataformas. Así que prueba ASP.NET. ¿Qué dices?

Advertisement
Did you find this post useful?
Want a weekly email summary?
Subscribe below and we’ll send you a weekly email summary of all new Code tutorials. Never miss out on learning about the next big thing.
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.