¿Por qué no hay muchas estructuras / bibliotecas de back-end modernas en C ++ para el desarrollo web?

La principal ventaja de C ++ es la velocidad de ejecución. Para el 99% de los casos de uso en los que está procesando solicitudes HTTP, usar C ++ o algo más lento, como Java o incluso Python, no hará una diferencia significativa. Si hay un cuello de botella, es probable que esté en alguna parte de la aplicación que esté lejos de las cosas HTTP reales. Por ejemplo, muchas aplicaciones web basadas en Python usan mucho C ++ bajo el capó. Por lo tanto, escriba un buen código de Python ahora, use bibliotecas C ++ rápidas (ya escritas y mantenidas por otra persona si tiene suerte) para las partes donde importa y reescriba en C ++ cuando crezca al tamaño que importa.

He escrito mucho C ++, pero no con C ++ moderno. Teniendo en cuenta todos los pasos para probar, depurar, completar las compilaciones, mantener API, etc., creo que requiere al menos tres veces más recursos para mantener un sistema de tamaño decente escrito en C ++ que uno escrito en Python. Quizás cinco u ocho veces. Cuando cruzas la línea cuando un equipo de 5–7 desarrolladores ya no puede mantener el sistema, rápidamente creces a 30 o 50 desarrolladores. (No voy a entrar en las razones técnicas y psicológicas para eso). Eso sucede mucho antes con C ++ que con Python en mi experiencia, aunque ciertamente es posible hacer un desastre en cualquier lenguaje, es muy difícil de evitar con C ++ .

Quizás el C ++ moderno es mucho mejor que el C ++ tradicional que mi razonamiento no es válido, pero si ese fuera el caso, pensarías que las herramientas que te faltan existirían …

Mis pensamientos al respecto son así …

Si estructura sus sitios web correctamente, tiene 3 secciones perfectamente compartimentadas

1 la base de datos, aquí es donde está todo su código SQL. No en el front end, y solo en el backend por gracia de la capa de datos. Los tipos de bases de datos trabajan aquí, no ‘necesitan’ saber nada sobre el desarrollo de aplicaciones, etc. Se preocupan por datos limpios, informes y velocidad.

2 el back-end, aquí es donde están sus programadores de back-end, no les importa demasiado cómo se ve la aplicación, les importa que funcione y que haga el trabajo para el que está diseñada. La velocidad es una preocupación para estos tipos, pero no demasiado

3 front end, aquí es donde ve todos los marcos … pero estos chicos deberían preocuparse por el aspecto de la aplicación y cómo los usuarios interactúan con ella …

Ahora veamos cómo funcionan la realidad y los negocios. Tener 3 desarrolladores es costoso. Lo que el trabajo realmente quiere son informes y páginas flash.

Así que vamos a deshacernos del desarrollador final. Ahora, el desarrollador front-end no tiene idea de cómo hacer correctamente las cosas de back-end (en este escenario), todo lo que les importa es HTML y css, oh y JavaScript para hacer algunas cosas llamativas.

Pero espera, una chispa brillante ha descubierto cómo hacer algunas cosas funky para hacer que JavaScript sea aún mejor … no tengo idea de cómo funciona … ¡pero si conecto esto a esto! Voila!

Y ahí es donde muchos lugares lo han dejado. Algunos incluso se han librado de los chicos sql y tienen todo en la parte delantera … porque pueden hacer que las cosas funcionen.

Todo eso está bien, pero tiene JavaScript hinchado porque la mayoría de los desarrolladores front-end que conozco son increíbles en el código plug and play, pero no tienen idea del costo de eficiencia, por lo que hacen que sus jefes sonríen, pero cuando todo funciona, cava lento, están atrapados

Ahora volvamos a por qué no hay muchos marcos de back-end … no es necesario que lo haya. El back-end tiene que ver con procesos y datos únicos para resolver un problema. No es que no haya marcos de back-end, pero cuando su proceso varía tanto de una compañía a otra y le importa el rendimiento … ¿cómo estandariza las cosas y las entrega a la comunidad en general? Lo mejor que puedes hacer es tener controles autocontenidos personalizados, etc.