¿Por qué las bases de código en el desarrollo de n niveles tienen la misma cantidad, si no más, de código JavaScript ahora?

He estado haciendo programación web durante mucho tiempo y, en algún lugar, perdí la noción de por qué estamos haciendo lo que hacemos hoy (o cómo llegamos a hacer las cosas de esta manera).

Comencé con el desarrollo web ASP básico, y muy pronto, la lógica de visualización y de negocios se mezclaron en la página. El desarrollo del lado del cliente varió enormemente (VBScript, diferentes tipos de JavaScript), y tuvimos muchas advertencias sobre las validaciones del lado del servidor (y por eso me mantuve alejado de la lógica del lado del cliente).

Luego me mudé a ColdFusion por un tiempo. ColdFusion fue probablemente el primer marco de desarrollo web que separó la visualización y la lógica empresarial utilizando sus etiquetas. Me pareció muy claro, pero muy detallado, y ColdFusion no tenía una gran demanda del mercado, por lo que seguí adelante.

Luego me subí al carro de banda ASP.NET y comencé a usar su enfoque MVC. También me di cuenta de que Java parecía ser un lenguaje de torre de marfil de los sistemas empresariales, y también probé su enfoque MVC. Más tarde, ASP.NET desarrolló este patrón de diseño MVVM, y Java (precisamente, J2EE o JEE) también luchó y salió con sus enfoques MVC2.

Pero hoy, lo que he descubierto es que la programación de backend ya no es donde está la emoción y el progreso. Además, las prácticas de MVC basadas en el servidor parecen ser obsoletas (¿la gente realmente usa JSTL?). Hoy, en la mayoría de los proyectos en los que estoy, descubrí que los marcos de JavaScript y el desarrollo del lado del cliente es donde se están haciendo todos los progresos emocionantes e innovadores.

¿Por qué ha tenido lugar este movimiento del servidor al desarrollo del lado del cliente? Hice un recuento simple de líneas de uno de mis proyectos JEE, y hay más líneas de código en JavaScript que Java (excluyendo las bibliotecas de terceros). Creo que la mayoría del desarrollo de back-end que utiliza lenguajes de programación como Java o C # es simplemente para producir una interfaz similar a REST, y que se están abordando todos los esfuerzos de visualización, visualización, entrada / salida de datos, interacciones del usuario, etc. a través del marco del lado del cliente como Angular, Backbone, Ember, Knockout, etc.

Durante la era anterior a jQuery, vi muchos diagramas en los que había una línea clara y conceptual entre M, V y C en MVC en el desarrollo de n niveles. Post-jQuery, ¿dónde se dibujan estas líneas? Parece que MVC y MVVM están ahí en el código JavaScript, del lado del cliente.

Lo que quiero saber es, ¿por qué hicimos esa transición? ) y qué problemas resolvió esta transición / cambio?

Cambiar la carga informática entre el servidor y el cliente es un fenómeno cíclico, y lo ha sido durante bastante tiempo.

Cuando estaba en la universidad comunitaria, la Computadora Personal se estaba volviendo loca. Pero Ethernet todavía no se usaba ampliamente, y nadie tenía una red de área local. En aquel entonces, la universidad tenía una computadora central que manejaba los registros de los estudiantes y servía como plataforma para programar clases. La administración tenía terminales que estaban conectadas al mainframe en una base de tiempo compartido, pero los estudiantes tuvieron que perforar tarjetas para realizar sus tareas de programación, un proceso arduo. Eventualmente, pusieron en un laboratorio donde los estudiantes podían inscribirse por tiempo en una terminal, pero aún así tardó tal vez media hora más o menos para obtener su impresión de errores de media pulgada de grosor. Todo el trabajo de procesamiento se realizó en el mainframe (el servidor).

Pero los mainframes eran caros, por lo que las empresas comenzaron a instalar redes de área local, y la carga de procesamiento pasó del servidor a las máquinas de los clientes individuales, que eran lo suficientemente potentes como para ejecutar aplicaciones de procesamiento de textos, hojas de cálculo y líneas de negocios individuales, pero no lo suficientemente potentes como para compartir su poder de procesamiento con otros. El servidor era una máquina similar con capacidades similares (quizás más memoria y espacio en el disco duro), pero se usaba principalmente para compartir archivos. Esto se llamó Cliente / Servidor. La mayor parte del procesamiento se había trasladado a las computadoras del cliente.

Uno de los inconvenientes de realizar todo el procesamiento en las máquinas cliente fue que te encerraste en este ciclo perpetuo de instalación y actualizaciones de software, y todos los dolores de cabeza que eso conlleva. El modelo de programación de estas máquinas (interfaces de usuario basadas en eventos y código subyacente) fomentó la creación de programas desordenados y difíciles de mantener (grandes bolas de lodo). La mayoría de los usuarios finales no tenían las habilidades para mantener su hardware y software adecuadamente, lo que requería ejércitos de personal de mantenimiento de TI.

A medida que las computadoras se volvieron cada vez más poderosas, las divisiones de trabajo se hicieron posibles. Ahora podría tener servidores de archivos, servidores de bases de datos, servidores web, servidores de impresión, etc. Cada máquina podría estar algo optimizada para la tarea que se le proporcionó y mantenerla alguien con la experiencia necesaria. Se podían escribir programas que se ejecutaban en el navegador web, por lo que ya no se requerían instalaciones del cliente. Esto se llamó Multi-Tier o n-Tier. Los navegadores se utilizaron esencialmente como terminales tontos, al igual que en los días de mainframe, aunque el método de comunicación con el servidor era más sofisticado, menos propietario y se basaba en mecanismos de interrupción en lugar de tiempo compartido y sondeo. El procesamiento había cambiado de nuevo a los servidores.

Sin embargo, el desarrollo web vino con un nuevo conjunto de dolores de cabeza. La mayoría de las aplicaciones de línea de negocios escritas para el navegador eran formularios e informes estáticos. Había muy poca interactividad disponible en la interfaz de usuario. Javascript aún no había encontrado su segundo viento, y hubo problemas importantes con las incompatibilidades del navegador que desalentaron su adopción generalizada. Sin embargo, las cosas han mejorado mucho. HTML5 y CSS3 proporcionan nuevas capacidades sustanciales al modelo de programación del navegador, salió jQuery y ayudó a toda una generación de programadores a descubrir lo útil que podría ser Javascript. Surgieron nuevos marcos de interfaz de usuario front-end. Se hizo posible escribir UI altamente interactivas en el navegador, incluso juegos completos. El procesamiento volvió al cliente nuevamente.

Hoy en día, puede comprar potencia de procesamiento en la nube, tanto o tan poco como desee, y ejecutar programas en el servidor. Diría que ahora estamos en un lugar donde, como desarrollador de software, tiene muchas opciones sobre dónde puede ejecutar su potencia de procesamiento, tanto en el cliente como en el servidor.

Parece que estás mezclando dos conceptos muy diferentes:

1. Presentación separada y lógica de negocios (MVC) => aumentar la capacidad de mantenimiento
2. Asignación de ejecución a un nodo => aumentar la eficiencia

En el pasado, la informática cliente / servidor a menudo se confundía con la primera porque los clientes generalmente no ofrecían mucha potencia informática, en comparación con los servidores. Por lo tanto, parecía natural mover el cálculo de lógica de negocios (M) "pesado" a los servidores, mientras se mantenía el procesamiento de vista (V) "ligero" a los clientes. A su vez, tuvo que implementar algún tipo de árbitro (C) para traducir entre los dos.

Ahora que los clientes presentan fácilmente la destreza del proceso que una vez implicó un hardware de servidor costoso, las líneas se han desdibujado en cuanto a dónde ejecutar la lógica empresarial: del lado del cliente o del servidor. Realmente, la respuesta depende de su caso de uso específico y su elección de compensaciones, por ejemplo:

• latencia del cliente frente a complejidad: el procesamiento del lado del servidor mantiene los sistemas más simples porque no es necesario implementar / descargar ningún código en el cliente, sin embargo, esto tiene el costo de la latencia del lado del cliente durante el cálculo.

• complejidad versus carga del servidor: la computación del lado del cliente puede aumentar la complejidad del sistema, pero también puede ayudar a reducir la carga del servidor.

• Resistencia descentralizada de la aplicación frente a la ejecución central: en un mundo de aplicaciones móviles, puede ser importante mantener a los clientes trabajando a pesar de la desconexión de la red. Sin embargo, esto tiene el costo de administrar múltiples versiones implementadas de lógica de negocios.

Esta es una lista no exhaustiva de muchas compensaciones.

Debido a que los usuarios siempre han querido la misma funcionalidad, campanas y silbatos con sus aplicaciones web (no solo sitios web) que tenían con las aplicaciones de escritorio. Hacer que todo esto se ejecute en un navegador (en realidad, varios navegadores) no es como en los viejos tiempos cuando se podía vincular un formulario VB a una base de datos con poco código. Esto es más fácil de lograr cuando no tiene que hacer viajes de regreso al servidor.

La mayoría del desarrollo de backend que utiliza lenguajes de programación como Java o C # es simplemente para producir una interfaz similar a REST, y que todo el esfuerzo de visualización, visualización, entrada / salida de datos, interacciones del usuario, etc. marco lateral como Angular, Backbone, Ember, Knockout, etc.

Tal vez la programación / servicios de back-end parezca lo mismo de siempre, pero es el corazón de la aplicación. Las prácticas de codificación pueden ser más eficientes en estas áreas. Las herramientas, los idiomas, los navegadores y los marcos aún están evolucionando, por lo que la UI / UX es difícil de desarrollar. Son las cosas nuevas que el viejo ASP no tenía. Si pudiéramos salir con interfaces de usuario con formas simples y tablas html, tampoco habría mucho interés / entusiasmo en esas áreas, pero los usuarios quieren arrastrar y soltar, animaciones, transiciones, ventanas emergentes, etc.

Hoy, en la mayoría de los proyectos en los que estoy, descubrí que los marcos de JavaScript y el desarrollo del lado del cliente es donde se están haciendo todos los progresos emocionantes e innovadores.

¿Por qué ha tenido lugar este movimiento del servidor al desarrollo del lado del cliente?

En realidad hay dos preguntas aquí:

1. ¿Por qué es la programación del lado del cliente donde está progresando?
2. ¿Por qué las aplicaciones se escriben para ejecutarse en el cliente en lugar del servidor?

Los dos son realmente distintos.

¿Por qué es la programación del lado del cliente donde está progresando?

Debido a que el tiempo de ejecución, el medio ambiente y el ecosistema han madurado sustancialmente en los últimos tres años, y esto ha abierto nuevos nichos que los innovadores han esperado explotar.

El desarrollo front-end solía ser difícil . Debía programar para navegadores, siempre un entorno hostil, utilizando las características restringidas de ECMAScript 3, en un ecosistema que no tenía la técnica anterior ni herramientas para crear aplicaciones de cliente pesado. No hubo cargadores de módulos. No podías manejar las dependencias correctamente. Había una escasez de herramientas de linting. Los marcos eran inmaduros y la mala reputación del front-end distanciaba a los innovadores que podían resolver estos problemas.

A medida que estos factores han cambiado gradualmente, han creado una masa crítica para desarrollar aplicaciones de cliente enriquecido rápidamente y ejecutarlas de manera consistente.

En respuesta a su pregunta, entonces, no es tanto que las nuevas tecnologías front-end hayan impulsado el progreso, sino que han liberado cuellos de botella y han permitido a los clientes ponerse al día con las aspiraciones de los usuarios.

¿Por qué las aplicaciones se escriben para ejecutarse en el cliente en lugar del servidor?

Hay muchas causas próximas, pero la más distinta de los últimos años es el surgimiento de los teléfonos inteligentes.

Los teléfonos inteligentes hacen que la informática moderadamente potente sea barata, ubicua y útil. Son propiedad de miles de millones de personas en todo el planeta, y esencialmente han llevado la informática a las clases medias de las economías emergentes. Pero las redes móviles son lentas, irregulares y limitadas por problemas geográficos, de ingeniería y políticos. En este entorno, es inevitable que las aplicaciones almacenen el estado localmente y apliquen parches de datos a regañadientes y en operaciones sin estado.

¿Cómo podría ser diferente? Imagínese si su teléfono inteligente fuera solo una terminal tonta. Toda mutación estatal debería ser asíncrona y falible. Cada carga de contenido costaría centavos preciosos. Tendría que invertir en enormes granjas de servidores con un tiempo de actividad de cinco nueves. Usted incurriría directamente en los costos informáticos, por lo que una repentina oleada de popularidad podría afectar su negocio.

Las aplicaciones del lado del cliente le permiten manejar el estado perteneciente al usuario individual de manera rápida y sincrónica. Le permiten descargar sus costos informáticos a sus usuarios. Le permiten escapar con el tiempo de inactividad y la mala conectividad de la red. Hacen que el código del servidor sea tan tonto que se puede almacenar en caché en la propia infraestructura de red: archivos HTML estáticos y JS, o respuestas enlatadas para aplicaciones móviles.

Para decirlo en términos muy amplios: el desarrollo del lado del cliente explota los bajos costos de la computación personal de potencia media y evita los altos costos de la computación centralizada de alta potencia.

Hiciste varias preguntas, algunas de las cuales ya tienen buenas respuestas. Algunos aún no han tenido sus respuestas:

Lo que quiero saber es, ¿por qué hicimos tal transición (del énfasis de la programación del lado del servidor al lado del cliente, ... todo esto parece haber ocurrido simultáneamente) y qué problemas resolvió esta transición / cambio?

Robert Harvey dio una excelente respuesta.

... desde favorecer lenguajes compilados hasta lenguajes de script,

Los lenguajes de script ofrecen muchas ventajas ( también ) sobre los lenguajes compilados, por ejemplo:

• son más fáciles de aprender y usar
• eliminar el tiempo de compilación (desarrollo más rápido)
• proporcionar más funciones (control de aplicaciones de gama alta)
• permitir cambios rápidos al código en ejecución
• etc.

... desde la programación imperativa hasta la funcional,

Aquí hay una buena comparación, pero lo resumiría diciendo que en el software distribuido (piense en la computación en la nube), administrar los cambios de estado (sincronización en muchos nodos) puede ser un gran problema. En la programación funcional, la necesidad de lidiar con los cambios de estado es mucho menor.