¿Qué beneficios hay para el desarrollo nativo de JavaScript? [cerrado]


33

Dado lo mucho más simple que es el desarrollo de jQuery, en comparación con JavaScript nativo, ¿qué hace que las personas renuncien a bibliotecas como jQuery?

¿Es esto porque jQuery tiene limitaciones o es lento? Quiero decir, si jQuery es tan fácil en comparación con JavaScript nativo, ¿qué razones tiene la gente para seguir usando JavaScript puro?


1
jQuery es solo una biblioteca: escribir JS nativo que usa jQuery sigue escribiendo JS nativo. Eso es como preguntar: "¿Qué beneficios hay para el desarrollo nativo de C ++?" cuando estás hablando del "desarrollo C ++ sin Boost".
Zach


1
El objetivo principal de jQuery y otras bibliotecas antiguas era hacer una fachada sobre diferentes navegadores con diferentes interfaces js (por ejemplo , XMLHttpRequestvs ActiveXObject, o addEventListenervs attachEvent, o css selectorsvs xpath selectorsvs no selector support, etc.) En los navegadores recientes, la mayoría de estos problemas no existen, porque siguen los mismos estándares.
inf3rno

Respuestas:


89

Hablemos de autos.

Oh, espera, ya lo hicimos, ¿recuerdas esa vez que nos conocimos, hace algún tiempo? Hablamos de autos. De hecho, parecía ser un experto en automóviles. Pudiste explicar, en detalle, todo lo que está bien, lo que está mal y lo emocionante de la última carrera de Fórmula 1. Sabías de memoria todos los modelos de Lamborghini, incluido su precio y disponibilidad. Incluso pensaste en comprar tu propio Ferrari 599 GTB Fiorano y estabas ahorrando (apuesto a que la cena de bistec no ayudó mucho).

Mientras explicaba las fallas de Toyota con una gran voz emocionada, de repente saltaste de tu silla y gritaste en el aire, agitando los puños sobre: ​​"¡Maldita sea, soy un magnífico experto en todo lo relacionado con los autos! ¡Voy a ser mecánico de automóviles! "

Y así fuiste. Tuviste una entrevista, el Jefe estaba tan impresionado como yo con tu conocimiento, y fuiste contratado. Entró el primer cliente. Su embrague estaba roto. Lo inspeccionaste y no sabías qué hacer. De hecho, no tenías ni idea de cómo seguir los consejos que te dio el Jefe. Fuiste despedido.

¿Pero cómo podría ser eso? ¡Sabes todo sobre autos! Excepto por ... todo sobre autos. Puede saber muy bien que el automóvil de sus sueños tiene un motor V12, pero no sabe lo que realmente significa.

Entonces, en realidad no eres mecánico de automóviles, eres un entusiasta de los automóviles. Y hasta que aprenda cómo funcionan los automóviles , seguirá siendo un entusiasta.

Ahora déjame preguntarte. Como $.fn.textfunciona ¿Y de qué $.fn? ¿Qué quieren decir realmente? ¿Cómo $(something)devuelve una cosita gigantesca que contiene cosas, y qué es exactamente esa cosita? ¿Puedes replicar su funcionalidad, al menos un poco, incluso en teoría? ¿Se puede hacer frente sin jQuery?

Decir que "JavaScript nativo es difícil" es simplemente ... falso. En primer lugar, porque JavaScript como lenguaje no tiene nada que ver con el DOM , que es principalmente lo que jQuery resume. Segundo, porque una vez que aprendes un poco sobre el DOM, ya puedes navegar a través de los errores más comunes entre navegadores. Pero solo un pequeño secreto: todo es difícil al principio. La división larga fue una perra en quinto grado.

Como segunda analogía para esta respuesta: jQuery es JavaScript-DOM (no JavaScript, el idioma, solo el DOM) como Array.prototype.forEaches for. Funciona, para el 99% de los casos. Y funciona bien. Pero para ese 1% que no está cubierto, debe saber cómo usar el forbucle, aunque solo sea práctico. Toda esta respuesta se basa en el lado "más puro" de la pregunta, y ni siquiera en el lado técnico (el tamaño de la biblioteca, por ejemplo, y varias otras cosas como se explica en la respuesta de Michael Dorrant). Porque me encanta JavaScript y cuando la gente parece tirarlo a un lado casualmente diciendo "pah, esos javascriptianos tontos" y agitando elegantes guantes blancos, todo se reduce a la moralidad.

Si puede aceptar el hecho de que siempre será un entusiasta de JavaScript, ¿quién soy yo para detenerlo? Pero si quieres ser un programador de JavaScript, primero debes tener el conocimiento para al menos elegir entre usar jQuery (o cualquier otra biblioteca) y no usar una biblioteca. Aprende el DOM. Aprenda como usarlo. Escriba su propia biblioteca pequeña o simplemente una colección de funciones auxiliares. Y una vez que conoces el DOM, y eliges usar jQuery - Godspeed. La pereza se otorga a aquellos que trabajaron duro.


15
¡La división larga sigue siendo difícil!
Raynos

13
@anonymousDownvoter Por favor, explique. ¿Es porque eres vegetariano? Puedo cambiar el bistec en una hamburguesa de tofu, pero honestamente no puedo decir que existe una "gran hamburguesa de tofu"
Zirak

10
+1 "¿Cómo $ (algo) devuelve una cosa gigantesca que contiene cosas, y qué es exactamente esta cosa?" Ja!
ThinkingStiff

3
Además, @Mike es criminal, esto nunca recibió un estado de respuesta porque es puro! @ # $ Ing genio.
Erik Reppen

55
"gran filete" en la publicación es un error tipográfico voluntario, no intentes editarlo. Si es necesario, refiérase a esta meta discusión al respecto
mosquito

12

Razones que sé:

  1. Cuando la necesidad es extremadamente mínima, diga 1 onclick.

  2. Cuando la velocidad de descarga es crítica y la biblioteca jQuery es demasiado grande Y NO tiene que escribir mucho código (personalizado) para reemplazarla.

  3. Al integrarse con otras tecnologías, a veces, js sin formato es mejor.

  4. Cuando se trabaja en un sistema heredado (también conocido como 'producción') ya escrito en js con patrones establecidos.


13
Me pregunto con qué frecuencia # 2 resulta ser cierto. Guarda una descarga potencialmente almacenada en caché de 92K, pero termina escribiendo mucho más código JS repetitivo.
Adam Rackis

44
No se sobre eso. Puede mantener el JS a lo que necesita , en lugar de incluir toda la biblioteca para un subconjunto de la funcionalidad.
Ryan Kinal

44
@Ryan Kinal: Adam Rackis tiene un buen punto, y si usa la API de Google para cargar Jquery, puede cargarlo desde el mismo lugar donde el usuario probablemente ya lo haya recuperado.
Ben DeMott

No estoy de acuerdo con el n. ° 4. Si el código heredado es horrible y todos en el equipo están de acuerdo y es una buena idea agregar jQuery y usarlo en el código futuro.
ThiefMaster

7

jQuery es simplemente un marco: un conjunto de herramientas escritas en JavaScript. Al usar ese conjunto de herramientas, todavía estás usando JavaScript. Algunas personas prefieren escribir JavaScript utilizando las herramientas que proporciona jQuery, algunas eligen no hacerlo, otras eligen otros conjuntos de herramientas.

Algunas razones por las que puede querer escribir JavaScript "puro" sin jQuery:

  • Las páginas se cargan más rápido sin incluir archivos jQuery adicionales
  • Algunos marcos pueden ser incompatibles con jQuery
  • El código que se escribe no hace nada con lo que jQuery ayude
  • El código se está escribiendo para que otros lo usen, y requerir jQuery como dependencia haría que compartir sea más difícil
  • El autor del código quiere más control del que jQuery proporciona

5

jQuery, como cualquier biblioteca o marco, agrega otra capa de errores . Me encanta, pero también he perdido un día buscando un error que resultó estar en jQuery core y no en mi código (una ocasión rara, pero no tan rara).

Aparte de eso, no encuentro ninguna otra razón para no usarlo:

  • La sobrecarga es mínima, especialmente si va con la versión alojada de Google ,
  • Ayuda a los desarrolladores de JavaScript menos experimentados a escribir código más limpio y eficiente,
  • En su mayoría es multiplataforma, lo que puede salvar vidas cuando tiene que lidiar con navegadores antiguos,
  • La gran galería de complementos me ayuda a escribir prototipos en muy poco tiempo,
  • El DOM tiene sentido,
  • bla, bla, bla...

PERO nunca debe usarse como un sustituto del conocimiento de Javascript. Si no sabe cómo hacerlo en Javascript puro, inicialmente puede salirse con la suya con una biblioteca, pero a la larga lo pagará.

Y, por supuesto, todos nosotros hemos estado encerrados en un combate mortal con IE6 durante bastantes años, y no renunciaremos fácilmente a nuestros trucos de la vieja escuela en favor de un juguete nuevo y brillante.


2
¿Usas complementos de jQuery? ¿No son la mayoría de ellos horriblemente con errores y llenos de código lento y malo?
Raynos

@Raynos The huge gallery of plugins help me write prototypes in very short times... Solo prototipos, los evito en el código de producción cuando es posible. Hay algunos plugins con código excelente, por supuesto, pero hay que buscar mucho para ellos ...
Yannis

prototipos generalmente significa "debería haber sido descartable pero ahora es un código de producción". Si los usa en prototipos descartables, entonces está bien.
Raynos

@Raynos Prototyping no se trata solo de prototipos descartables. La creación de prototipos evolutivos es un proceso central del desarrollo web ... - cómo es eso, para una respuesta tardía: P
yannis

El "prototipo evolutivo" se llama "cortar enormes esquinas ahora y espero que ganemos más al hacerlo que el costo de toda esa deuda de código que vamos a obtener". Lo cual, por supuesto, solo es válido si cortar las esquinas te lleva a esa ventana mágica de tiempo que necesitas para que tu negocio se convierta en un éxito. Es un prestamo.
Raynos

5

En el entorno del navegador, necesita una herramienta de normalización de navegador cruzado. Tal herramienta viene en dos sabores

  • envuelve objetos host con nuevos objetos que se comportan de la misma manera en todos los navegadores
  • extender objetos host para implementar la API DOM.

En general, puede usar estas utilidades de una de las tres maneras

  • use funciones pequeñas como addClasso en setTexttodo su código cuando y donde las necesite
  • escriba su propia biblioteca de normalización de navegador cruzado
  • use uno existente.

Necesita algún mecanismo de normalización; de lo contrario, obtendrá cero compatibilidad con el navegador cruzado.

En cuanto a usar uno existente, está bien. Simplemente no usaría jQuery. Personalmente, actualmente estoy escribiendo mi propia biblioteca ( DOM-shim repara los navegadores sin exponer una API propietaria extranjera. Convierte sus navegadores en un único navegador estandarizado y bien comportado).


3

Si no necesita abstracción DOM, compatibilidad con navegadores cruzados y navegadores antiguos, puede prescindir fácilmente de jQuery.

Este es el caso cuando está desarrollando extensiones de navegador, scripts de greasemonkey (a veces), cosas para descifrar números, desarrollo para Node.js u otros entornos que no son del navegador.


2

Junto con las otras respuestas aquí, especialmente las de Michael Durrant , vi que la velocidad es una razón importante para que ocasionalmente elija usar JavaScript sin formato.

Últimamente he estado trabajando en muchas animaciones u otras tareas intensivas de CPU y, algunas veces, JavaScript sin procesar es mucho, mucho más rápido que si paso por jQuery.

Un ejemplo es donde quería cambiar la opacidad de un position: fixedelemento en relación con qué tan abajo en una página se ha desplazado un usuario. El efecto fue demasiado lento cuando utilicé jQuery para esto, lo que hizo que el desplazamiento fuera desigual y el efecto de desvanecimiento se arruinó. Cambié a usar JavaScript directo y todo fue sedoso en todos, excepto IE <= 8.


2

Necesito presentar mi respuesta con cierta honestidad. Amo a jQuery. Me facilita enormemente la vida y hace que el código JavaScript sea más declarativo, que es la forma en que creo que las cosas deberían funcionar.

jQuery hace muchas cosas ...

, puede agregar complementos
, puede extender los selectores
, simplifica la animación

pero jQuery no hace todo

¿Alguna vez has intentado trabajar en contextos de ventanas múltiples con jQuery? jQuery apesta al tratar con diferentes contextos de ventana porque retiene el original windowy el documentcontexto de la ventana en la que se llamó.

He escrito un código aquí y allá para hacer popouts *, y jQuery simplemente puede interferir con lo que estoy tratando de lograr. Agregar una nueva referencia a jQuery en la ventana secundaria a menudo puede empeorar las cosas al hacer que sea más difícil saber qué contexto jQuery se está utilizando.

* Piense en la ventana emergente de Gmail para redactar un correo electrónico en una nueva ventana, no en publicidad spam

Úselo cuando simplifica el código

El momento de usar jQuery es cuando puede hacer que su código sea más simple, más corto, más legible y más rápido.

El momento de no usar jQuery es cuando no hará que su código sea más simple, más corto, más legible o más rápido. Si necesita ajustar los tiempos de carga, es posible que no desee usar jQuery debido a la sobrecarga del evento.


2

Como sabrán, jQuery es un marco de uso general que proporciona muchos métodos que muchos de nosotros no usamos en nuestros proyectos. (Algunos de ellos no los he usado en absoluto).

Hay dos razones principales para no usar jQuery o cualquier otro marco bien establecido.

1. El proyecto no es lo suficientemente grande o complejo como para usar dicho marco: en este caso, el codificador toma una decisión informada basada en su experiencia y conocimiento en JavaScript. Esto lo ayudará a reducir el peso de la página y también más control sobre el código.

2. El codificador desarrolla su propio marco. He visto un proyecto en mi empresa que tiene su propio marco JavaScript. La razón por la que citan es que si están usando jQuery y hay algún error que solucionar, tienen que esperar hasta la próxima versión. Además, si hay que agregar una función, deben solicitarla al equipo de jQuery o agregar un complemento, aunque convertirlo en un complemento no será una buena idea (dieron el ejemplo de haber usado algo .livesimilar en su marco incluso antes de que se agregara oficialmente a JQuery). Tener su propio marco le da más control al código. La desventaja es que necesita reinventar la rueda con respecto a los problemas de compatibilidad del navegador, etc. Además, si el proceso de desarrollo no es bueno, su marco se hinchará y solo aumentará el tiempo para mantenerlo.


0

Micro

Creo que las personas se protegen contra el uso de algunas bibliotecas debido a la dependencia de esa solución de infraestructura / biblioteca para realizar alguna tarea.

Pero tengamos cuidado de recordar que los idiomas van y vienen como bibliotecas a largo plazo.

Entonces, tal vez sea de alcance temporal. Tal vez las personas duden en invertir en una biblioteca que tal vez no esté allí, o que tengan tanto impulso a la larga.

¿Mí mismo? No tengo ninguna objeción a usar JQuery en particular. También miro, por ejemplo, Box2d.js o three.js y preferiría adoptarlos incluso si tienen una vida útil a corto plazo que perderse las frutas que tienen para ofrecer.

La conclusión de Mike es que existe un riesgo en la vida útil de una biblioteca que elijas, y creo que algunos en la comunidad de JavaScript pueden haber experimentado pérdidas debido a que una biblioteca o proyecto está llegando a su fin, y pueden haber dicho, nunca más.


0

Diría que el problema principal es que cada vez más personas (¿la gran mayoría?) Ya no saben cómo codificar en JavaScript. Si jQuery no puede hacer algo, no pueden hacerlo.

Está llegando al punto en que los ejemplos simples de JavaScript se están volviendo difíciles de encontrar. Nada en contra de jQuery; Es un gran marco. Obtuve muchas buenas ideas, pero la gente debería aprender JavaScript primero y luego aprender un marco. Personalmente, considero que mi propio marco es más flexible y se adapta mejor a mis necesidades, y sí, a veces reinvento la rueda, pero el control total y el control sobre las correcciones de errores es una gran ventaja siempre que esté dispuesto a poner el trabajo en aprender JavaScript.

No solo eso. Conocer JavaScript vainilla hace que sea mucho más divertido jugar y experimentar con las funciones más nuevas en lugar de esperar una implementación basada en el marco. Además, no culpo a jQuery por esto, ya que es principalmente una biblioteca DOM , pero puede ser difícil de escalar con grandes proyectos. Otros marcos hacen un mejor trabajo en esto; El prototipo me viene a la mente.

En resumen, es un gran marco, pero no todo es lo que la gente dice.


2
Su respuesta sería más fuerte si fuera menos despotricar y se enfocara más en detalles.

esta publicación es bastante difícil de leer (muro de texto). ¿Te importaría editarlo en una mejor forma?
mosquito

0

Puedo agregar dos razones más que no se mencionaron:

  1. Cuando elijo tecnología completamente nueva, muchas veces, comenzaría con construcciones de nivel inferior antes de pasar a las de nivel superior. Principalmente soy un desarrollador de C ++ / C #, pero hace un tiempo, cuando comencé a jugar con HTML / CSS / JavaScript, decidí no usar ningún marco porque primero quería entender la tecnología (es decir, el JavaScript lenguaje en sí) sobre el que se construyen esos marcos.

    • Dicho esto, desde entonces descubrí jQuery y nunca quisiera volver a codificar a mano lo que jQuery puede hacer por usted en 1-2 líneas de código.
  2. No sé qué tan común es esto, pero para mí parece que hay muchas personas que cuando ven el próximo marco / tecnología / lenguaje, su primera respuesta es "¡no otra API para que yo aprenda!" No les importa lo fácil que es jQuery, pero simplemente lo ven como un obstáculo entre ellos y entregando trabajo usando sus métodos "verdaderos y probados". Esta es la misma categoría de personas que se niegan a usar la biblioteca Boost o cualquiera de STL y continúan usando malloc para casi todo. Usted preguntó por qué eligen JavaScript puro sobre jQuery y, en realidad, nunca lo hicieron porque la mayoría de las veces se negaron a evaluar jQuery en primer lugar y están perfectamente contentos con su ritmo de desarrollo actual, no importa cuán lento sea.


1
La gente elige JavaScript puro sobre jQuery porque jQuery es una capa de abstracción horrible que no es necesaria.
Raynos

Por supuesto que lo es, oculta las diferencias entre los navegadores y eso es una gran cosa en sí mismo
Kos

@Raynos: No soy realmente un experto en tecnología web y apenas soy un aficionado, por lo que realmente no puedo defender jQuery. Pero por lo poco que he visto, ha sido muy bueno para mí. jQuery agrega otra herramienta a su caja de herramientas. Puedes usarlo tanto o tan poco como quieras. Nunca te impidió escribir Javascript puro cuando era necesario. Al mismo tiempo, hay cosas que puede lograr con pocas líneas de código que le tomarán días escribir, por lo que si funciona, use esas 2 líneas. Si no es así, tira el tuyo. Decir que todo es horrible es como comprar un destornillador y luego quejarse de que es un ...
DXM

... horrible herramienta para clavar clavos porque el mango no tiene suficiente peso
DXM

1
No necesitas jQuery . Los navegadores tienen esta API llamada DOM que le permite hacer todo lo que quiera. Los problemas de navegador cruzado se pueden resolver usando polyfills. jQuery es una biblioteca mediocre y una solución mediocre para el soporte de navegador heredado.
Raynos

-1

jQuery es una biblioteca escrita en y para JavaScript. La idea es que simplifica todas las cosas difíciles / tediosas de JavaScript, lo que acelera el tiempo de desarrollo y hace que sus scripts sean mucho más propensos a funcionar en varios navegadores.

Lo que hace que sea preferible usar jQuery:

  • Rápido
  • Biblioteca ligera de JavaScript
  • CSS 3 compatible
  • Soporta muchos navegadores.
  • El marco jQuery es extensible y maneja manipulaciones DOM, CSS, Ajax , eventos y animaciones.

JavaScript es un lenguaje, mientras que jQuery es una biblioteca escrita con JavaScript.

Aquí hay razones que hacen que sea preferible usar JavaScript en lugar de jQuery:

  1. Carga toda la biblioteca de scripts jQuery cada vez con la página. Es un inconveniente para el sitio web de procesamiento de consultas rápidas / peed.
  2. A veces, el colapso / conflicto del marco jQuery con otros marcos.
  3. Si está escribiendo un código simple para seleccionar un elemento y mostrar alter, entonces JavaScript nativo es mucho mejor.
  4. Si las operaciones son pequeñas y se realizan dentro de una línea de código de JavaScript, entonces no es bueno usar jQuery.

Debido a estas razones, me gusta usar JavaScript para evitar el marco jQuery. Es mucho mejor aprender JavaScript en lugar de depender de dicha biblioteca ...

Incluso si desea extenderlos, debe escribir código en JavaScript. Lo cual también es una gran charla. Los desarrolladores dependen de estas bibliotecas, por lo que para tener control sobre los proyectos, JavaScript es mejor que usar frameworks.


1
"maneja muy bien las manipulaciones DOM" Lol ¿QUÉ?
Incógnito

gracias @Incognito por informarme sobre esto ... Pero es mucho mejor que otras bibliotecas. keyframesandcode.com/resources/javascript/deconstructed
Niranjan Singh

1
El enlace es completamente incorrecto. jQuery que admite selectores psudo-css a través de sizzle no tiene nada que ver con el DOM.
Incógnito

así que está bien .. Incluso he aprendido de usted acerca de estas cosas .. que me puede dar cualquier enlace o información sobre estas cosas .. He actualizado la respuesta ..
Niranjan Singh

yuiblog.com/blog/2006/10/20/video-crockford-domtheory es un buen comienzo, luego lea la especificación w3c en el DOM.
Incógnito

-4

Creo que las personas usan jQuery porque es más simple, más fácil y más poderoso, y porque les ayuda a olvidarse de IE. Además, para funcionalidades personalizadas, las personas usan JavaScript. Intente referir el DOC para más detalles.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.