¿Cuáles son los argumentos en contra de usar un Framework de JavaScript para una empresa de desarrollo de sitios web?

Question

Nuestra empresa crea sitios web y aplicaciones web. Somos una empresa pequeña y nuestro equipo de desarrolladores siempre está construyendo las funciones de JavaScript desde cero o copiando desde otros sitios web creados por nosotros. Cada vez que poner sobre la mesa la palabra de normalización y el uso de un marco JS como jQuery, Prototype o cualquier otro, estoy Marcos contadas tiene los tres puntos por debajo como argumentos en contra de ellos:

• principalmente para las personas que no lo hacen saber lo suficiente JS
• Frameworks limit Javascript developers
• Frameworks inflan el código de desarrollo real con un montón de cosas que no se utilizan.
• No utilizamos lo suficiente Javascript en nuestras aplicaciones para que nosotros necesitamos marco JS

En mi mente parece que Marcos, a nuestro equipo un buen punto de partida, la documentación, una comunidad y siempre la opción de crecer en la parte superior del marco. ¿Podrían algunos usuarios del Marco elaborar más?

EDIT 1:

Gracias a todos por sus grandes respuestas. Realmente no pensé que este iba a ser un tema tan candente. Me alegro de haber hecho la pregunta. Publiqué otra pregunta similar en el siguiente enlace por si crees que quieres agregar algo. El tema de la nueva pregunta es CSS relacionado. Gracias.

Answer 1

Argumentos en contra:

• marcos que impiden volver a inventar la rueda
• marcos de código contienen por lo general bien probado
• marcos están bien apoyados por la comunidad
• Marcos le obligan a centrarse en el problema comercial que está tratando de resolver

</sa rcasm>

• Marcos puede tener una licencia que no está de acuerdo/no se puede trabajar con

Answer 2

Por sus compañeros de trabajo punto de vista, .NET y Java son para las personas que no saben lo suficiente montaje.

Existen marcos por una razón. Te permiten enfocarte en el problema en lugar de lidiar con el código repetitivo. Le permiten tener confianza (suponiendo que utilice marcos bien probados) de que ciertas piezas de su código son confiables y están bien probadas.

Si sus compañeros de trabajo están en contra de los marcos, consideraría seriamente seguir adelante.

Answer 3

me gustó la respuesta de PB +

principalmente para las personas que no saben lo suficiente JS

Creo que es demasiado complicado para ellos, por lo que usan esta excusa.FW le permite construir aplicaciones mucho más complejas.

Marcos de limitar los desarrolladores de JavaScript

mierda

Marcos de la hinchazón del código desarrollo real con un montón de cosas que no se utilizan.

¿qué es hoy 100k-200k extra? especialmente si usa las versiones de CDN (en google, por ejemplo). Y esto es asumiendo que no uses nada en el FW.

Answer 4

Algunos aspectos positivos para los marcos de JavaScript (como JQuery).

1. Proporcionan la estandarización en elementos de ui .
2. Reduce el tiempo para desarrollar interfaces y efectos complejos .
3. Normalice los esfuerzos al proporcionar funciones que ya son compatibles con el explorador .
4. Debido a los esfuerzos en la documentación compatibilidad cruzada es más útil en un marco como se puede utilizar la API de el marco canónico como en lugar de buscar oscura soporte para varios/propietaria javascript funciones.
5. Curva de aprendizaje reducida para los nuevos desarrolladores de que los hacen productivos en su software más rápido.

Estoy completamente en desacuerdo con que un framework limita los desarrolladores de JavaScript. Todo lo contrario en realidad. La mayoría de los marcos proporcionan extensos mecanismos de complemento en los que el marco se puede extender utilizando javascript sin procesar utilizando ganchos en el marco mismo.

Answer 5

Un argumento en contra de las bibliotecas es el SOPORTE DE NAVEGADOR la ​​mayoría de las bibliotecas solo admiten un subconjunto de navegadores. Here es un ejemplo de BBC desplegando sus propios en lugar de usar algo como jquery.

Answer 6

Como nadie lo ha mencionado, un framework de Javascript se convierte rápidamente en una dependencia más del proyecto y, en términos generales, las dependencias son malas ya que representan puntos de error.

En cuanto a esto:

• principalmente para las personas que no saben lo suficiente JS

Sin entrar en detalles, voy a decir que si uno de nuestro equipo dijo algo así en mi presencia , Trataría de ignorarlo como una broma. Si pensé que estaban hablando en serio, probablemente tendría que matarlos.

Y en cuanto a esto:

• Marcos limitar Javascript desarrolladores

Que se puede traducir en "Marcos hacen que sea marginalmente más difícil de escribir código espagueti, y eso es lo que mejor hago"

No son argumentos, son excusas.

Answer 7

Hay muchas buenas razones para desconfiar de los marcos en general, equilibrado por supuesto por muchas razones por las que valen la pena.

Utilizo jquery ahora, y francamente en una hora de aprendizaje, me di cuenta de que encaja tan bien en el trabajo que, si no existiera, terminaría por volver a implementar algo muy similar, solo que no sería tan bueno o como plataforma cruzada.

No hay mucha hinchazón allí, es muy pequeña y está bien diseñada y no hace nada en absoluto que le impida escribir cualquier javascript que desee para casos específicos que no se ajustan a sus necesidades.

Answer 8

Me sorprende que nadie ha mencionado:

• Una gran cantidad de desarrolladores web por defecto a usar jQuery sin tener en cuenta las alternativas
• y terminan incluidos en una página web para hacer unos pocos tareas triviales que podría hacer fácilmente en JavaScript puro
• el resultado es que los usuarios tienen que esperar a que toda la biblioteca para descargar y se ralentiza la navegación web

también:

• Algunos desarrolladores web dejarse llevar por el diseño de páginas web, y terminan el desarrollo de páginas web innecesariamente complejas debido a la potencia de jQuery
• El hecho de que jQuery le permite crear scripts con buena compatibilidad entre navegadores no significa que el resultado final se pueda utilizar en diferentes dispositivos/interfaces
• También argumentaría la compatibilidad entre navegadores porque he visto casos de webkit que no funcionan bien con JQuery
• JQuery alienta "rápido" secuencias de comandos, pero si se apresura es probable que haya perdido algo
• Escribir en JavaScript desde cero es más lento, pero creo que terminas con una solución más completa que se aproxima más a las necesidades de los usuarios
• El uso de JQuery puede cambiar el enfoque del desarrollador web para crear sitios web altamente gráficos y visualmente atractivo, mientras que la atención debe centrarse en la funcionalidad y facilidad de uso
• jQuery no es una bala de plata para el desarrollo web

soy parcial aquí porque yo no uso jQuery, pero es porque no he Encontré una necesidad aún - quizás sea porque me enfoco más en la usabilidad y la funcionalidad en lugar de hacer que la interfaz del usuario se vea bonita (lo siento Sé que JQuery puede hacer más que eso).

Answer 9

Usaré jQuery como ejemplo, pero lo que estoy diciendo aquí podría aplicarse a la mayoría de los marcos de JavaScript.

Muchos marcos (especialmente jQuery) son demasiado monolíticos y no son lo suficientemente modulares.

Si bien el software de terceros bien probado a menudo está más que justificado, los "marcos" tienden a darle mucha más funcionalidad de la que necesita en este momento.

En muchos proyectos, me gusta mucho la conveniencia que jQuery me da para seleccionar conjuntos de elementos (usando $ (". Classname"), por ejemplo). Pero, si no estoy usando una cantidad significativa de AJAX, no necesito las utilidades AJAX provistas por jQuery.

El software debe hacer una cosa y hacerlo bien, y el software escrito en JavaScript no es una excepción. La mayoría de los marcos a los que se refiere intentan hacer todo, lo que resulta en una complejidad innecesaria.

Un lugar que esto puede morder es cuando está considerando actualizarse a la próxima versión del marco. Eso implica rastrear los registros de cambios de jQuery para los cambios incompatibles hacia atrás y buscar en su proyecto las áreas donde se usa ese código. Esto puede ser una verdadera pesadilla, especialmente si no tiene necesariamente una lista completa de las características de jQuery que utiliza y las que no.

Además, jQuery (y otros marcos) tiende a provocar que los desarrolladores comiencen dependiendo de las nuevas características de jQuery sin siquiera pensar en ello, lo que hace más difícil determinar qué características de jQuery utiliza su proyecto y cuáles no.

Si utiliza una utilidad que hace una cosa, entonces sabrá exactamente qué características de esa utilidad está utilizando. Sólo hay uno. (Si no está utilizando esa utilidad en absoluto, es fácil de determinar. Dicha determinación significaría que podría eliminarla de su proyecto de manera segura.)

Estoy a favor de utilizar un código de terceros bien probado. Pero si trata de hacer demasiado (es decir, si es un marco en lugar de una utilidad), probablemente debería buscar una alternativa. Si intenta hacer demasiado (como jQuery intenta hacer demasiado), entonces tiene algunos defectos de diseño fundamentales y serios que probablemente volverán a morderte.