¿Por qué los frameworks web no son simples, elegantes y divertidos como los lenguajes de programación? [cerrado]

Cuando pienso en casi cualquier lenguaje de programación, como C, C ++, PHP, SQL, JavaScript, Python, ActionScript, Haskell, Lua, Lisp, Java, etc., me parece increíble, me encantaría desarrollar una aplicación informática con cualquier de esos idiomas

Pero cuando pienso en los marcos web (principalmente PHP), como Cake, CI, Symfony, Laravel, Zend, Drupal, Joomla, Wordpress, Rails, Django, etc., soy como Dios no.

¿Por qué no hay marcos web que me brinden construcciones simples, divertidas y potentes como un lenguaje de programación?

También tuve esta pregunta durante años, aunque estoy del lado de Python. No tengo una sola explicación para este fenómeno, pero aquí están mis pensamientos sobre el tema:

• Los marcos web deben tratar con el lenguaje de marcado XMLish - HTML, parte de la tríada web HTML-CSS-JavaScript actual en una forma cliente-servidor. Significa tres idiomas, que interactúan entre sí, un DOM del navegador y un modelo de ejecución (y un modelo de seguridad). En efecto, cada pieza de funcionalidad (un "módulo") debe tener su código en los tres idiomas. Para agregar a esto, el idioma del selector de jQuery se está convirtiendo en un idioma más para cuidar.

• HTML + CSS carece de un modelo intuitivo y matemáticamente sólido para colocar objetos. Incluso Tcl / Tk es, en mi humilde opinión, mejor para definir gerentes de geometría. Esto evita que el programador defina la representación HTML en términos estrictos y confíe en la suerte: "tal vez este div funcione la mayor parte del tiempo en la mayoría de los navegadores". Sin embargo, hay algunos desarrollos positivos en este lado, por ejemplo, HTML5 y Twitter Bootstrap.

• La tecnología web ha crecido orgánicamente y los marcos han crecido con ella, por lo que su forma no es necesariamente elegante. Significa que el programador debe recordar las API, que son subóptimas, que serán obsoletas, etc.

• Los navegadores web aún tienen ligeras incompatibilidades, y agrega complejidad innecesaria a los marcos web

• La arquitectura general es un desastre. Es un pensamiento dividido de back-end y frontend, que están vinculados con la solicitud / respuesta en el lado del backend y el procesamiento basado en datos en el lado del front-end. El orden de ejecución no está muy bien definido (la sincronización requiere esfuerzo) y se requieren estilos para colocar los scripts en las ranuras adecuadas (casi todos los scripts js deben colocarse antes del final de la etiqueta del cuerpo, y así sucesivamente). El almacenamiento en caché es otro aspecto, que abarca desde el backend hasta el proxy (s) hasta el front-end. ¡Y ni siquiera menciono el manejo de formularios!

• Web-framework necesariamente aborda la mayoría de estas complejidades al agregar muchos conceptos y tuberías de procesamiento.

• En la industria web, la mano de obra generalmente se divide entre diseñador gráfico, diseñador web / programador web y programador de backend como un conjunto mínimo de roles. Los dos primeros no necesariamente tienen habilidades de programación, por lo que necesitan abstracciones y herramientas diferentes, y los marcos también deberían facilitarlos.

En resumen, los marcos web intentan abstraer mucha complejidad (cada vez más complejos), pero es muy difícil de lograr debido al rápido desarrollo de estándares y otras partes móviles. Los lenguajes de programación son mucho más maduros, porque generalmente no es un problema no usar nuevas funciones.

Creo que será posible crear un marco web conveniente solo después de que los estándares de la GUI estén en su lugar (cubriendo diferentes modos de operación, como dispositivos móviles) y las tecnologías subyacentes serán lo suficientemente estables.

Los marcos web carecen de construcciones simples porque no existen tales cosas en el dominio de la tecnología web. Las abstracciones de nivel inferior necesariamente se filtran a nivel superior.

Creo que mucho tiene que ver con las limitaciones de la WWW. Específicamente, no hay una forma integrada de almacenar el estado entre el servidor y el cliente. Un cliente solicita algunos datos, el servidor los proporciona y la conexión se cierra. Como tal, todas estas plataformas web tienen que armar su propio método para mantener el estado entre las llamadas del servidor.

Tuve que hacer una pequeña aplicación web una vez y en ese momento nunca había hecho ninguna programación de servidor / cliente. Me tomó algunas semanas entenderlo todo y la parte más difícil fue tratar de entender cómo estaban el cliente y el servidor.

¿Cambiará esto alguna vez? Lo dudo. Requeriría un cambio fundamental en la arquitectura de la web.

En términos generales, las causas pueden ser múltiples:

1. La brecha de abstracción es mayor en el caso marco. Un lenguaje moderno de procedimiento / OOP proporciona abstracción sobre una máquina pero mantiene algunas construcciones de máquina (como asignar una variable a algunos datos / escribir algunos datos en una unidad de memoria, o llamar a un procedimiento, etc.); la brecha no es tan grande, mientras que un marco intenta proporcionar abstracción para desarrollar una aplicación web que opera con muchos más conceptos.
2. Los marcos pueden ser más complejos desde el punto de vista del programador; Esto es como una consecuencia del primer punto. Un lenguaje de programación es bastante simple, tiene construcciones simples (si, para, variables, procedimientos, etc.). Además, la biblioteca estándar abstrae cosas simples como escribir en IO o usar colecciones. La biblioteca estándar también está muy modularizada, con poca o ninguna conexión entre el módulo y otro; no necesita saber IO para usar colecciones o viceversa. Cabe señalar que si algunas partes de la biblioteca estándar son bastante complejas, se colocan en un mini marco (por ejemplo, Java Collections Framework o Executors framework). En el caso del marco, necesita conocer todo el flujo, todas las partes para usar el marco con toda su fuerza. Además, aa framework es una aplicación ya construida;
3. No tantos recursos se ponen en un marco como en un lenguaje de programación. Creo que esto no necesita ninguna explicación.

Ah, pero ves que ese es exactamente el problema. Se supone que los marcos no están completos. Se supone que están compuestos de abstracciones más restringidas que se pueden componer juntas para realizar un conjunto específico de tareas de una manera sucinta. Por lo tanto, todos esos marcos que mencionó no son divertidos exactamente porque no proporcionan un conjunto restringido de abstracciones. Proporcionan abstracciones permeables que componen por sí mismas una máquina abstracta que es más que probable que Turing esté completa. El concepto de " máquinas extrañas " es lo más parecido en lo que estoy pensando. Todos esos marcos son "máquinas extrañas" para aplicaciones web y una "máquina extraña" es lo contrario de lo que debería ser un marco.