Esta pregunta se centra en extraer las ventajas y desventajas de usar Frameworks basados ​​en la Web : como Cake PHP, Zend, jQuery, ASP.NET). Esta pregunta es completamente independiente del lenguaje . Permítanme comenzar con la noción de "pararse sobre los hombros de gigantes ".

Ventajas:

• Empodera a los desarrolladores : al tomar características que anteriormente habrían tomado cientos de líneas de código y comprimirlas en una simple llamada a la función, se les permite a los desarrolladores integrar características más complejas en sus sitios web.
• Permita un desarrollo más rápido de las aplicaciones: esto es muy relevante para las personas que necesitan sitios web creados en una ventana muy pequeña (¿alguien tiene algún ejemplo de esto?)
• Costos más bajos : permite a los programadores transferir los ahorros de costos al cliente, se generó una gama completamente nueva de clientes que querían un sitio web pero que anteriormente no podían pagar los costos de desarrollo más altos.

Desventajas

• Pérdida de comprensión : al confiar en las características de un marco, un desarrollador corre el riesgo de perder la comprensión de cómo funcionan las cosas (debajo del capó).
• El acantilado de la configuración: una vez que va más allá de la configuración de su marco, su productividad cae de inmediato, puede ser difícil implementar características fuera de la configuración de un marco.
• Tranvías para desarrolladores : usted (el desarrollador) tiene que hacer las cosas de la manera que el desarrollador quiere que haga las cosas.

Me pregunto qué piensa la gente de mis puntos y si alguien no está de acuerdo con ellos. Además, si la gente tiene puntos adicionales, estaría agradecido.

Aquí está el resultado final: puede ser difícil implementar características fuera de la configuración de marcos.

Veamos esta suposición por suposición.

Pérdida de comprensión: al confiar en las características de un marco, un desarrollador corre el riesgo de perder la comprensión de cómo funcionan las cosas (debajo del capó).

Falso. Nunca perderá la comprensión de cómo funcionan las cosas. Los marcos no son mágicos. Son solo códigos útiles que no tiene que escribir usted mismo.

Lo creas o no, cometerás errores al usar el marco. Tendrá que depurar hasta los niveles más bajos de HTTP para comprender lo que hizo mal.

Nunca perderá de vista lo que sucede debajo del capó. A menos que, por supuesto, su marco sea tan épico y perfecto que nunca tenga un problema.

El acantilado de la configuración: una vez que va más allá de la configuración de su marco, su productividad cae de inmediato, puede ser difícil implementar características fuera de la configuración de un marco.

Esto tiene muy poco sentido.

Primero. Construir sin un marco puede hacer un trabajo trivial en una gran tarea de programación que incluye pruebas unitarias, depuración, diagnóstico, control de configuración y todo ese otro trabajo sin valor reinventando cosas que están en el marco. ¿Cómo es esa "productividad"?

Segundo. Implementar cosas fuera del marco siempre es mucho trabajo porque, ejem, implementar cualquier cosa fuera del marco siempre es mucho trabajo. No tiene nada que ver con el tiempo dedicado a aprender y configurar el marco. Implementar cualquier cosa fuera del marco es inherentemente difícil.

Tramlines para desarrolladores: usted (el desarrollador) tiene que hacer las cosas de la manera en que el desarrollador [framework] quiere que haga las cosas.

Correcto. Y esto a menudo es algo bueno. Hacer las cosas de una manera consistente es más valioso que hacerlo de acuerdo con sus preferencias personales. Puede requerir "aprendizaje" y "comprensión", pero estos tienen valor.

Problemas de seguridad: dar a las personas estas herramientas para desarrollar sitios web de aspecto profesional rápidamente es un riesgo potencial, las personas pueden crear rápidamente sitios web de aspecto profesional para empresas fraudulentas.

¿Qué? Esto no tiene nada que ver con el marco. El fraude es fraude, independientemente de las herramientas utilizadas.

Con: eventual posible caída de apoyo / pérdida de popularidad

• Si hay dos marcos web que hacen básicamente lo mismo, y el suyo no gana, existe la posibilidad de que el proyecto muera. En esta situación, debe mantener el marco usted mismo (código abierto), reescribir la aplicación o continuar sin actualizaciones (código cerrado).
• Dependiendo del marco, puede verse obligado a actualizar su aplicación con el calendario de lanzamiento del marco. Retrasarte demasiado podría hacerte inelegible para recibir apoyo. Sin marco, puede trabajar en su horario. (Esto depende de si necesita / quiere apoyo o no).

Pro: Código para el negocio

• Frameworks le permite no preocuparse por el trabajo pesado y centrarse en el código que aporta valor directamente a la empresa.
• A veces, las actualizaciones de framework que (solo funcionan) le permiten ofrecer nuevas funciones a sus usuarios prácticamente "gratis". Especialmente con los marcos que vienen con controles personalizados (como una cuadrícula que la nueva versión puede ofrecer algún tipo de búsqueda / filtro).

Ventajas

• Tiempo de desarrollo más rápido.
• Menos errores
• Desarrollo compartido más rápido
• Soporte de la biblioteca
• Fácil interacción con la base de datos

Desventajas

• "Encajonado" en el marco
• A menudo inflexible cuando se quiere extender o modificar el comportamiento central
• "Errores de fatalidad": errores que surgen del núcleo o de la arquitectura subyacente sin un buen rastreo de donde se originaron. Un ejemplo perfecto son los errores de Spring al usar Grails.

Abogo por el uso de marcos para todos menos los proyectos más simples. Si necesita agregar un formulario de contacto con nosotros a un sitio HTML existente, puede usar un archivo PHP en lugar de pasar a un marco.

Un par de cosas que vienen a la mente son ...

Ventajas

• Reutilización de código: mediante el uso de un marco, está reutilizando código probado y verdadero.
• Desarrollo rápido / creación de prototipos.
• (a menudo) validación de entrada integrada que se puede suponer segura (dado que el desarrollador la está utilizando correctamente)

Desventajas

• Pérdida de apoyo. Aquí viene a la mente Symfony 1.4. Me imagino que Symfony admitirá 1.4 durante bastante tiempo, pero sabiendo que 2.0 no es compatible con versiones anteriores, 1.4 parece un callejón sin salida de soporte en los próximos años.
• Gastos generales; Al usar un marco, está ejecutando miles de líneas que pueden no aplicarse a su aplicación específica, pero sí a otras. Algunos consideran que esto es una compensación razonable, y otros optan por escribir su código desde cero para el rendimiento.
• Usar el marco incorrecto para sus necesidades específicas. No todos los marcos se crean por igual.

Todo depende del marco que uses.

Si está utilizando ASP.NET, está en desventaja: es una abstracción permeable en el mejor de los casos , y en el peor difícil hacer cosas triviales en otros marcos que no ocultan el hecho de que trabajando en la web.

ASP.NET MVC busca solucionar ese problema, y ​​lo hace muy bien.

Existen marcos para que podamos pasar más tiempo haciendo el trabajo y menos tiempo construyendo andamios. En ese sentido, no veo ninguna desventaja, a menos que realmente quiera pasar tiempo construyendo andamios.

Quisiera agregar algunos puntos.

• Uno de los mayores problemas con los marcos que encuentro es que las personas se detienen a pensar. Solo quieren usar el marco porque es genial o porque siempre usan el marco. No se detienen a pensar si el uso está justificado.
• Licencias, las personas simplemente parecen usar marcos sin realmente mirar las licencias. Esto podría tener implicaciones de las que no están al tanto. O piense en lo que sucede cuando cambia la licencia.
• Utilizando gran parte del mismo tipo de marcos. A veces puede haber muchos marcos que realmente hacen más o menos lo mismo. Como empresa, usted toma decisiones educadas y no tiene un marco diferente para cada proyecto.
• Mantenerse al día con las nuevas versiones puede ser un desafío

Sin embargo, creo que poner un poco más de esfuerzo para evaluar los frameworks, evaluar las licencias, mantener una lista limpia de frameworks por uso y tener una estrategia de versiones inteligente valen la pena cuando se consideran las ventajas.

Ventajas:

• cuando usa marcos de manera consistente, el tiempo de aprendizaje para los proyectos disminuye para las personas que ya trabajaron en sus proyectos.
• su propio desarrollo más rápido
• sus propios desarrolladores de empoderamiento

Hablo por experiencia personal en los últimos 13 años. En mi empresa utilizamos puntales, después de una curva corta fue genial. En el siguiente, utilizamos una arquitectura que era en su mayoría opaca, algo puntal, pero crecida, pudimos extenderla, pero el código central era solo frascos. Y así. En los últimos 3 años hemos estado trabajando en una pequeña empresa (número de desarrolladores <30) y eran todos nuestros propios jsps, servlets y ejbs. Mirando a nuestros múltiples clientes y la repetición de jsps, en 2012 fue hacer un filtro j2ee que imitaba el 20% de struts2. ¿Por qué no usar stuts 2? Ojalá lo hubiéramos hecho, pero: no podía pasarlo nuestro arquitecto jefe; No hay suficiente experiencia o tiempo.

Así que tuvimos interceptores algunos jsps comunes que usó nuestro mini framework. Ahora, cuando he tenido tiempo de leer un libro de struts 2, ¡veo que nos hemos perdido tanto!

Utilizamos algunos buenos algoritmos y cachés y la interfaz de usuario, pero hemos perdido muchas horas y cargado con una gran cantidad de código que tenemos un plan de 3 años para retirar.