javascript - attribute - getelementsbytagname

jQuery vs. javascript?

Question

Recientemente me encontré con algunos foros de javascript (por desgracia, el enlace se pierde en algún lugar del universo), donde se puede sentir odio real contra jQuery por no ser ... ¿algo bueno?

La mayoría de los argumentos parecen tener sentido en realidad.

Ahora, realmente me gusta jQuery, sobre todo por dejarme concentrarme en las cosas que quiero hacer más bien en las inconsistencias del navegador y realmente hace que AJAXing con efectos divertidos (¿o usados ​​en exceso ?).

Pero si realmente es algo podrido en el núcleo de jQuery, no quiero confiar en él de la manera en que realmente ... confío en ello.

No quiero comenzar otra discusión sobre qué marco es el mejor ... pero ... ¿Qué marco es el mejor (broma) ? Como uso de un caso, piense en la pequeña y mediana web y su administración.

Solo estoy tratando de averiguar si las cosas en algún framework o javascript puro con algunas funciones de mina realmente hacen la diferencia.

Editar:

De hecho, traté de tener una discusión objetiva normal sobre los pros y los contras de 1., usando un framework sobre javascript puro y 2., jquery y otros, ya que jQuery parece ser el más fácil de trabajar con la curva de aprendizaje más rápida. Sin embargo, algunas personas simplemente no lo entienden y piensan que estoy iniciando otra llama (lo que no soy). De hecho, estoy votando para reabrir esta pregunta.

También estoy realmente interesado en:

• ¿JQuery depende en gran medida del rastreo de navegador? ¿Podría ser un problema potencial en el futuro? ¿Por qué?
• Encontré muchos motores JS-selector, ¿hay bibliotecas AJAX y FX?
• ¿Hay alguna razón (además del rastreo del navegador y el "odio" personal contra John Resig) por qué jQuery está equivocado?

jQuery en realidad, como el más utilizado, representa otros marcos también.

Answer 1

"De hecho, traté de tener una discusión objetiva normal sobre los pros y los contras de 1., utilizando framework sobre javascript puro y 2., jquery y otros, ya que jQuery parece ser el más fácil de trabajar con la curva de aprendizaje más rápida".

Usar cualquier marco porque no quiere aprender realmente el lenguaje subyacente es absolutamente incorrecto no solo para JavaScript, sino para cualquier otro lenguaje de programación.

"¿Hay alguna razón (además del olfateo del navegador y el" odio "personal contra John Resig) por qué jQuery está equivocado ?

La mayor parte del odio se debe al exagerado fanboyismo que contamina los foros con "use jQuery" como respuesta para cada pregunta de JavaScript y el uso excesivo que produce código en el que declaraciones simples como declarar una variable se realizan mediante llamadas a la biblioteca.

Sin embargo, también hay algunos problemas técnicos legítimos, como la culpa compartida en la producción de código ilegible y sobrecarga. Por supuesto, esos dos se ven agravados por la falta de competencia del desarrollador en lugar de la biblioteca misma.

Answer 2

Jquery VS javascript, estoy completamente en contra del OP en esta pregunta. La comparación ocurre con dos cosas similares, no en tal caso.

Jquery es Javascript. Una biblioteca de JavaScript para reducir la codificación difusa, la colección de funciones de JavaScript de uso general que ha demostrado ayudar a la codificación eficiente y rápida.

Javascript es la fuente, los scripts reales a los que responde el navegador.

Answer 3

Jquery, al igual que cualquier otro buen marco de trabajo de JavaScript, le proporciona una funcionalidad independiente de la plataforma del navegador que abarca todas las complejidades, que puede que no le importe o no quiera importar.

Creo que usar un framework es mejor en lugar de usar JavaScript puro y hacer todas las cosas desde cero, a menos que tu uso sea muy limitado.

¡Definitivamente recomiendo JQuery!

Gracias

Answer 4

Personalmente, creo que deberías aprender por las malas primero. Le hará un mejor programador y podrá resolver ese problema único cuando se presente. Después de que puedas hacerlo con JavaScript puro, usar jQuery para acelerar el desarrollo es solo una ventaja adicional.

Si puedes hacerlo de la manera difícil, entonces puedes hacerlo de la manera más fácil, no funciona al revés. Eso se aplica a cualquier paradigma de programación.

Answer 5

Se trata de rendimiento y velocidad de desarrollo. Por supuesto, si usted es un buen programador y diseña algo que realmente se adapta a sus necesidades, puede lograr un mejor rendimiento que si hubiera utilizado un marco de JavaScript. ¿Pero tienes tiempo para hacerlo todo por ti mismo?

Mi opinión personal es que Javascript es increíblemente útil y usado en exceso, pero que si realmente lo necesitas, un framework es el camino a seguir.

Ahora viene la elección del marco. Para saber qué puntos de referencia valen, puede encontrar uno en http://ejohn.org/files/142/ . También depende de qué complementos estén disponibles y qué piensas hacer con ellos. Empecé a usar jQuery porque parecía mantenerse y tener una buena presentación, a pesar de que no era el más rápido en ese momento. No me arrepiento, pero no he probado nada más desde entonces.

Answer 6

• ¿JQuery depende en gran medida del rastreo de navegador? ¿Podría ser ese posible problema en el futuro? ¿Por qué?

No, está el método $ .browser, pero está en desuso y no se usa en el núcleo.

• Encontré muchos motores JS-selector, ¿hay bibliotecas AJAX y FX?

Cargas. jQuery a menudo se elige porque funciona bien con AJAX y animaciones, y es fácilmente extensible. jQuery no usa su propio motor selector, usa Sizzle , un motor de selección increíblemente rápido.

• ¿Hay alguna razón (además del rastreo del navegador y el "odio" personal contra John Resig) por qué jQuery está equivocado?

No, es rápido, relativamente pequeño y fácil de extender.

Personalmente, es bueno saber que, como los navegadores incluyen más cosas (API de la lista de clases, por ejemplo), jQuery se actualizará para incluirlo, lo que significa que mi código se ejecuta lo más rápido posible todo el tiempo.

Lea la fuente si le interesa, http://code.jquery.com/jquery-1.4.3.js : verá que las características se agregan en función del mejor caso primero y se transfiere gradualmente a los navegadores heredados para ejemplo, una sección del método parseJSON de 1.4.3:

return window.JSON && window.JSON.parse ?
window.JSON.parse( data ) :
(new Function("return " + data))();

Como puede ver, si window.JSON existe, el navegador usa el analizador nativo JSON, de lo contrario, evita el uso de eval (porque de lo contrario los minfiers no miniatizarán este bit) y configura una función que devuelve los datos. Esta idea de asumir técnicas modernas primero, luego degradar a métodos más antiguos se usa en todo sentido, lo que significa que los nuevos navegadores pueden usar todas las características de la tecnología sin sacrificar la compatibilidad heredada.