react - ¿Por qué jQuery es tan ampliamente adoptado en comparación con otros frameworks de Javascript?

react vs angular (20)

¿Por qué la gente comenzó a usar máquinas de fax? En cierto punto, el beneficio aumenta exponencialmente.

Administro un grupo de programadores. Valoro la opinión de mis empleados, pero últimamente hemos estado divididos en cuanto a qué marco usar en proyectos web.

Personalmente estoy a favor de MooTools , pero algunos MooTools de mi equipo parecen querer migrar a jQuery porque es más ampliamente adoptado. Eso por sí solo no es suficiente para permitir una migración.

He usado tanto jQuery como MooTools . Este ensayo en particular tiende a reflejar cómo me siento con respecto a ambos marcos. jQuery es ideal para la manipulación de DOM, pero parece estar limitado a ayudarte a hacer eso.

En cuanto a las características, tanto jQuery como MooTools permiten una fácil selección y manipulación DOM .

// jQuery $(''#someContainer div[class~=dialog]'') .css(''border'', ''2px solid red'') .addClass(''critical''); // MooTools $(''#someContainer div[class~=dialog]'') .setStyle(''border'', ''2px solid red'') .addClass(''critical'');

Tanto jQuery como MooTools permiten AJAX fácil:

// jQuery $(''#someContainer div[class~=dialog]'') .load(''/DialogContent.html''); // MooTools (Using shorthand notation, you can also use Request.HTML) $(''#someContainer div[class~=dialog]'') .load(''/DialogContent.html'');

Tanto jQuery como MooTools permiten una fácil animación de DOM :

// jQuery $(''#someContainer div[class~=dialog]'') .animate({opacity: 1}, 500); // MooTools (Using shorthand notation, you can also use Fx.Tween). $(''#someContainer div[class~=dialog]'') .set(''tween'', {duration: 500}) .tween(''opacity'', 1);

jQuery ofrece los siguientes extras:

Gran comunidad de seguidores
Repositorio de complementos
Integración con ASP.NET y VisualStudio de Microsoft
Utilizado por Microsoft, Google y otros

MooTools ofrece los siguientes extras:

Marco orientado a objetos con emulación OOP clásica para JS
Objetos nativos extendidos
Mayor coherencia entre los navegadores para el soporte de funciones nativas.
Reutilización de código más fácil
Utilizado por The World Wide Web Consortium, Palm y otros.

Dado que, parece que MooTools hace todo lo que hace jQuery y más (algunas cosas que no puedo hacer en jQuery y puedo en MooTools ) pero jQuery tiene una curva de aprendizaje más pequeña.

Entonces, la pregunta es, ¿por qué usted o su equipo eligieron jQuery sobre otro framework de JavaScript?

Nota: Si bien sé y reconozco que jQuery es un gran marco, hay otras opciones disponibles y estoy tratando de tomar una decisión sobre por qué jQuery debería ser nuestra elección frente a lo que usamos ahora ( MooTools ).

Elijo usar jQuery como nuestra biblioteca de UI predeterminada, precisamente porque no amplía o de otra manera monipañe los objetos nativos, a diferencia de prototype.js o mootools. Comience con el ángulo de la documentación y realmente no hay dudas sobre qué marco usar.

Esa es una pregunta extraña ... me da la impresión de que ...

está muy familiarizado con los mootools y aprovecha al máximo su modelo OOP, lo que hace que su código sea más fácil de gestionar y de brindar soporte ya.
te das cuenta de que el propósito de jQuery es algo diferente y ajustado a la manipulación DOM y AJAX y que mootools hace todo lo que hace jQuery Y algo más.
suena como si no necesitaras usar mucho los complementos de terceros, lo que hace que los puntos de popularidad y soporte de jQuery sean un poco menos importantes.

En pocas palabras, ¿es el bombo? jQuery se está convirtiendo en una de estas palabras de marketing mágico como ''AJAX'', .NET y Web 2.0, que es genial para ellos, pero ¿por qué necesita justificarse con el marco que funciona tan bien para usted? También están las consideraciones comerciales que imagino cubrirán cosas como:

la longevidad del framework, o es probable que las mootools desaparezcan frente al siempre creciente jQuery, muy dudoso, dado que acaban de lanzar 1.3 beta 1 y tienen 2.0 en las tuberías para su lanzamiento a fin de año.
costo del personal y su capacitación (me imagino que encontrar programadores de mootools será más difícil que estos dar un rodeo en su currículum vítae).
tiempo (y costo) tomado para mantener y extender sus sistemas bajo cada marco dados sus recursos.

Ambos marcos son geniales, pero creo que lo mejor para ti es mantenerte con mootools.

Lo dices tú mismo:

Dado que, parece que MooTools hace todo lo que hace jQuery y más (algunas cosas que no puedo hacer en jQuery y puedo en MooTools) pero jQuery tiene una curva de aprendizaje más pequeña.

La mayoría de las cosas extra que hace MooTools son cosas que simplemente no necesitamos .

Como dices tú mismo, jQuery es más fácil de aprender, lo que en realidad es más importante para la mayoría de las personas al elegir un marco.

Lo que NO necesito en JavaScript es definitivamente OOP y algunas feas emulaciones de objetos.

La última vez que revisé MooTools (quizás hace 1,5 años :-), tenía incompatibilidades con el navegador al manipular múltiples selecciones.

Entonces jQuery se ve completamente bien para mí.

Lo que hizo que mi experiencia con los mootools fuera bastante desagradable fue la documentación y la estabilidad de la API: simplemente no pude encontrar una documentación relacionada con la versión de mootools en uso. No será un gran problema si la API definida fue estable. Pero debido a algunas funciones que desaparecieron en la versión más nueva (se encontró un ChangeLog después de horas de búsqueda) tampoco fue posible una migración. Después de eso, mootools estaba fuera de carrera para mí.

Al igual que muchos otros, no quiero introducir OOP basado en clases en manipulaciones simples de interfaz de usuario. Para eso utilizo jQuery: cosas no tan complicadas para la interfaz de usuario. Cuando tengo que crear aplicaciones ricas en el navegador, siempre cambio a las grandes soluciones (ExtJS, YUI, qooxdoo) que ofrecen una variedad de widgets listos para usar.

Los frameworks JS son muy parecidos, de todos modos. Si has estado trabajando con mootools por un tiempo, mantenlo. Conocer su marco es mucho más importante que elegir uno por esto o aquello.

En mi opinión, mootools es mejor para los programadores avanzados de javascript, mientras que jquery es mejor para los programadores que no usan JavaScript. Eso es lo que creo después de leer ambas documentaciones, fíjate, no usé ninguna de ellas. jQuery carece de soporte para el núcleo de javascript, enlace de funciones, clonación de objetos, apilamiento de hilos, por nombrar algunos.

Me he estado haciendo esta misma pregunta por un tiempo, tratando de entender bien la discusión. Y con cada debate que leo, la abrumadora respuesta ha sido "Más ampliamente adoptada, por lo tanto, mejor".

Soy uno que usa ambos ampliamente. JQuery en el trabajo (adoptado porque fue "más ampliamente adoptado") y Mootools en proyectos personales. Como resultado, constantemente me siento tullido cuando uso JQuery; Ya sea con soporte JSON, creación de elementos, manejo de eventos ... y más. En el trabajo, me encuentro escribiendo cadenas de 75 eventos de largo ... y me siento sucio como resultado.

Sin embargo, mi principal problema general con JQuery es que hay una falta de coherencia o práctica en lo que concierne a los complementos y desarrolladores de terceros. El anecdótico "Más complementos disponibles" realmente no me ayuda cuando no hay consistencia entre los complementos, estructuralmente o de otra manera. Me tomó varias semanas aprender el modelo de complemento "aceptado", e incluso entonces, he adaptado mi propio estilo pragmático, ya que encuentro errores e ineficacia en las estructuras actuales. Se puede decir que es un ''Pro'' que cualquier persona puede saltar y comenzar a JQ. Sin embargo, estoy más inclinado a llamarlo una ''Con'', ya que verá 30 maneras diferentes de lograr algo, y es difícil fijar un estándar aceptado.

Entonces, ¿qué significa "Conocer JQuery", ¿Significa que sabes cómo oscilar un poco .hide (). Show (). FadeIn (). FadeOut ()?

Cuando tengo que conseguir gangster en mi JS en el trabajo, me echo de menos algunos Mootools. Me refiero a la compatibilidad con Native JSON. Vamos......

En respuesta a la respuesta "Ampliamente adoptada", todos sabemos que OSCommerce es el carrito de compras más " Ampliamente adoptado ", y todos sabemos qué montón de mierda es esa. De ninguna manera estoy comparando JQuery con OSCommerce. Simplemente estoy señalando la falla de la respuesta "Ampliamente adoptada".

En cuanto a los complementos, la tienda de aplicaciones para Apple tiene ... ¿100k aplicaciones? 50,000 son aplicaciones de pedo. Seguro que hay muchos complementos para JQuery, pero la relación entre basura y valor es excelente.

Mootools, no funciona correctamente o no funciona en absoluto cuando se utiliza el prototipo de jquery, etc. Estoy de acuerdo en que no hay absolutamente ninguna razón para usarlos simultáneamente, pero de vez en cuando aterrizan en la misma página (por ejemplo, complementos, presentaciones de diapositivas, widgets etc.) y las cosas dejan de funcionar.

Eso en sí mismo es inaceptable. ¡Entonces todos los apoyos para jquery no crean dolores de cabeza innecesarios!

No he visto MooTools en un tiempo tampoco. Pero aquí están mis puntos para JQuery:

Modelo de programación consistente (hay una manera JQuery que funciona)
Excelente documentación . Cuando comencé JQuery tenía la mejor documentación disponible.
Extensos enchufes de terceros
Soporte de Microsoft: soy un desarrollador de asp.net, esto ayuda a aliviar las mentes de los clientes. Además, viene con mis herramientas ahora.
Muchas guías para comenzar.
El sitio web de JQuery se ve mejor que el sitio web de MooTool. Lamento que importe, pero lo hace. Recuerde, muchas de estas herramientas deben atraer tanto a los diseñadores como a los desarrolladores.

No solo es jQuery una buena biblioteca, sino que su creador, John Resig, también tiene cierta credibilidad como autor de Pro Javascript Techniques .

Tenemos 2-3 copias de este libro en nuestra oficina.

jQuery es pequeño (intencionadamente) pero puede tener funcionalidad agregada a través de complementos.

No soy partidario de imponer la orientación clásica de objetos en JavaScript. Hay tantas maneras de hacerlo que un programador de JavaScript podría estar utilizando Base2 para OO, mientras que otro usa Prototype o Moo o JS.Class o Joose. Resig decidió deliberadamente no agregar clases a jQuery, y eso ha alentado a las personas a encontrar más formas nativas de JavaScript para resolver problemas.

Como resultado, es más fácil para mí leer JavaScript que otros escritores de jQuery escriben, y escribir código jQuery que es más fácil de leer para otros. Por lo general, no trato de emular el OOP de clase en JavaScript. En cambio, creo objetos sobre la marcha y los paso, y tengo muchas matrices de objetos. ¡Es tan fácil de entender que incluso me he encontrado llevando ese pensamiento a los lenguajes OOP!

Por lo que sé, Moo puede haber alcanzado a jQuery o haberlo superado. Pero no puedo perder el tiempo rastreando las 6 o 7 geniales bibliotecas de JavaScript para ver qué caballo está adelante.

Creo que fue en gran medida una cuestión de tiempo. Cuando las masas de programadores entraron en AJAX, jQuery fue la nueva y genial cosa que resolvió sus problemas.

Otras bibliotecas han alcanzado en gran medida. YUI, ExtJS, Dojo, Moo, todos son geniales. Pero no puedo usarlos a todos.

Trabajo lo suficiente para tratar de descubrir las ramificaciones de las nuevas características de la biblioteca que uso. Por ejemplo, jQuery agregó eventos en vivo a partir de 1.3. Esto realmente me permite cortar el código de muchas páginas. ¿Moo ofrece eso ahora también, y cómo se supone que sabré que sucedió, si lo hizo?

Estoy seguro de que Moo es increíble. Me encantaría tener el tiempo para aprenderlo. ¿Pero has mirado a Dojo? Tuve que usarlo en un proyecto y descubrí que también había recogido la mayoría de las grandes ideas de jQuery. Y tiene pubsub y buen soporte para Comet.

Simpatizo contigo. Pero tus programadores hablan con sentido. Aprender jQuery es bueno para sus carreras, y hay más libros, ejemplos y otros programadores para pedir ayuda si usan jQuery.

Si decide ir jQuery después de todo, piense detenidamente antes de decidir si agregar o no una biblioteca OO. Hay algunos geniales (como JS.Class o Joose), pero dar ese paso significa aislarse del código de la mayoría de los programadores de JavaScript.

Otra razón: es más fácil vender jquery a la gerencia. Al hacer un desarrollo interno basado en asp.net en un entorno corporativo, las palabras mágicas son "es compatible con Visual Studio".

Personalmente, jQuery hace exactamente lo que necesito.

Intento hacer la mayoría de mis cosas en mi código del lado del servidor, que está bien estructurado: tiene un OOP, capas y una arquitectura MVC adecuados. Cuando necesito hacer algo con Javascript, he encontrado (hasta ahora) que jQuery tiene lo que necesito. Francamente, eso se divide en tres categorías:

Manipulación simple del DOM , por lo general mostrando / ocultando cosas sin golpear el servidor.
Ajax llama , dijo nuff.
Beneficios de UI , incluyendo pop-ups modales, animaciones, transiciones de desvanecimiento de / a ocultas / mostradas. Soy un tipo duro de codificación de back-end, y apestaba por las cosas de UI. Me gusta mucho que jQuery me permita programar cosas que se vean atractivas.

Además de eso, la biblioteca de plugins jQuery es enorme, y he encontrado bastantes bibliotecas que simplifican mi trabajo en el lado del cliente. Buen material.

MooTools presenta OO pensando, lo cual es bueno, pero no es lo que necesito. Quiero mantener mi estructuración en el back-end, y no tener que introducir ese pensamiento en mi código del lado del cliente. Para mí, el código del lado del cliente es una pequeña parte del énfasis y pensarlo desde un punto de vista de clase es demasiado exagerado, y mucho más trabajo. Siento que estaría construyendo dos aplicaciones en lugar de una si tuviera que usar lo que creo que serían las mejores prácticas para MooToools.

Creo que resume por qué es tan popular, especialmente por aquí. En general, somos personas de tipo código y back-end, y jQuery nos permite hacer una interfaz de usuario atractiva mediante programación, y nos permite concentrarnos en nuestro núcleo de back-end.

Por un lado, eso no es todo lo que hace. También hay few other features . Por otro, no todos lo usan. Pero no quiero interrumpir una buena diatriba.

Tengo que secundar muchas de las respuestas ... una gran documentación y el apoyo de la comunidad es crucial. Solía odiar la programación js y la evitaba como el plauge, pero ahora la he abrazado por completo gracias a jquery y a la rápida curva de aprendizaje.

¡No siempre se trata de quién tiene la mejor tecnología!

YAGNI.

Sí, está un poco fuera de lugar aquí, pero esa es la razón principal por la que jQuery tiene una base más grande que MooTools. Todos esos extras que MooTools trae a la mesa son agradables, pero YAGNI.

No se trata de lo mejor, se trata de satisfacer, encontrar la solución adecuada al problema en cuestión. jQuery es fácil de usar, su objetivo principal es la manipulación DOM. Dado que el 95% de las personas que recogen javascript lo hacen solo para manipular el DOM, no tiene sentido pasar por la curva de aprendizaje más larga de MooTools. MooTools simplemente no les trae nada a la mesa que jQuery no entregue con menos esfuerzo.

MooTools exige más de usted antes de usarlo, jQuery le permite juntar algo rápidamente. Si comienzas a escribir aplicaciones js grandes y pesadas, es posible que te encuentres con algunos de los inconvenientes de ese enfoque, pero de nuevo el 95% de las personas que escriben js no hacen eso, por lo que esas cosas no les importan. Usan un lenguaje del lado del servidor para el heavy-lifting y javascript para el DOM.

Para el caso, tampoco pueden importarle a su equipo. Para llevarlo a través de las listas, punto por punto (jQuery primero):

Gran comunidad de seguidores: solo ligeramente relevante para el proyecto. De mayor relevancia personal para el equipo, porque habla de la vida después de ti. Si ocurre una desgracia (por favor, Dios, no) y su empresa se ha ido, jQuery les da más trabajos que MooTools.

Repositorio de complementos: muy relevante, ya que ayuda a evitar reinventar la rueda.

Integración con ASP.NET y VisualStudio de Microsoft: muy relevante si usted es una tienda .NET. De hecho, esto solo debería ser la razón para cambiar si lo hace .NET.

Utilizado por Microsoft, Google y otros, ¿a quién le importa?

Ahora para la lista de MooTools:

Marco orientado a objetos con emulación OOP clásica para JS: irrelevante, a menos que la naturaleza de sus proyectos lo haga un plus. No sé lo que estás construyendo, pero para las tiendas web, esto rara vez es relevante. La mayoría de las tiendas web no tienen suficiente código para hacer que esto sea una ventaja.

Objetos nativos extendidos: irrelevante para la mayoría de las tiendas web

Mayor coherencia entre los navegadores para el soporte de funciones nativas. - Relevante

Reutilización de código más sencilla: esto entra en conflicto un poco con la ventaja de jQuery de un repositorio grande. Un gran repositorio en sí mismo habla de reutilizar el código. Sospecho que estás usando una definición estrecha de reutilización de código, aquí, que puede no ser relevante. He reutilizado gran parte del código jQuery que he creado, así como el código MT.

Utilizado por The World Wide Web Consortium, Palm y otros. - Irrelevante. La única relevancia sobre quién más está usando lo que es si quieres un trabajo allí. Hay más relevancia en cuántas tiendas lo usan que en cualquier tienda en particular que lo use.

No existe una forma única de acercarse a la codificación de JavaScript. Elimine su parcialidad y siéntese con su equipo y elimine también su parcialidad. Converse sobre los tipos específicos de proyectos que está emprendiendo (y desea emprender) y las fortalezas de cada biblioteca según se aplica a esos casos. (No importa cómo podrían manejar otros casos, porque esos otros casos no existen.) Debe llegar a un consenso a partir de eso.

(YAGNI = No lo va a necesitar, si necesito explicarlo)

jQuery le da acceso a métodos de programación funcionales nítidos y concisos. Desde el lanzamiento del método de encadenamiento en (LINQ) en C # 3.0, esto funciona muy bien para los programadores .NET. Por lo tanto, el flujo de un idioma a otro es fácil. Poder consultar el DOM para un objeto, o una lista de objetos, funciona mucho mejor para nosotros. Es el poder de selección de jQuery lo que lo hace tan atractivo, luego la capacidad de ampliación y, por supuesto, todas las funciones integradas que lo acompañan son agradables. Además, la comunidad que está detrás es maravillosa porque primero busco ver si alguien más hizo algo y luego intento hacerlo yo mismo si no se encuentra una solución. Y por último ... pero ciertamente no menos importante ... el hecho de que Microsoft va a incluir en Visual Studio 10 y soportarlo es genial. Moo Tools, Prototype, etc. simplemente no pueden competir con todo lo anterior.

jQuery, como cualquier marco, hace lo que hace y, si no se ajusta a sus necesidades, debe usar otra cosa. No uso jQuery para hacer una programación complicada en JavaScript, la utilizo porque hace que la manipulación de DOM y el estilo de CSS3 sean simples y el 95% del tiempo es lo que necesito.

Una mayor comunidad de usuarios y una adopción más amplia marcan una gran diferencia al comparar herramientas / bibliotecas que ofrecen funciones y conceptos similares. Una comunidad más grande significa más soporte, más ejemplos, más buenas ideas y más fragmentos de código reutilizables, lo cual es especialmente importante cuando trabajas en un escenario raro: es más probable que alguien más lo haya visto antes.

En segundo lugar, en los puntos de referencia que he visto, jQuery es más rápido que MooTools.

También me gusta mucho su énfasis en mantener un núcleo pequeño y agregar funcionalidad a través de complementos. Evita que la biblioteca central se vuelva realmente grande y difícil de manejar.

Nunca he usado MooTools personalmente, pero no tengo dudas de que es una biblioteca fantástica que ofrece un equivalente aceptable a la mayoría de las funciones o conceptos de jQuery, pero el punto n. ° 1 me quita el pastel.