Por qué no me gusta trabajar con marcos, a pesar de que tienen sentido en algunas situaciones
Los marcos, como jQuery, son algunos de los asistentes más populares y más extendidos que se utilizan en los sitios web. El marco le permite acceder y manipular elementos HTML de forma rápida y sencilla, así como aplicarles estilo a través de CSS. Personalmente, no soy fanático de estos marcos y trato de evitarlos siempre que sea posible. Esto no siempre funciona, pero se puede hacer sin problemas con bastante frecuencia.
jQuery and Co. y su gran sello
Especialmente jQuery se ha convertido en una herramienta integral para JavaScript en los últimos dos años. El marco proporciona una amplia gama de métodos, elementos y eventos, la mayoría de los cuales no serán utilizados por la mayoría de los usuarios.
Aunque la versión comprimida actual de jQuery solo pesa alrededor de 85 kilobytes, la mayoría del marco permanecería sin usar en mis proyectos. Podrías llamarme quisquilloso por preocuparme tanto por los 85 kilobytes. Pero como desarrollador web, un código delgado que solo contenga lo que realmente necesito es importante para mí.
jQuery se ha convertido en un estándar en el desarrollo web. Por lo tanto, se desarrollaron muchos otros marcos como complementos para jQuery. Entonces, si quisiera usarlos, también tendría que usar jQuery. Aquí, las desventajas de estos marcos se hacen evidentes.
Después de todo, solo necesitaría jQuery para usar ese complemento. Para mí, 85 kilobytes son demasiado para justificar eso.
Redundante: a menudo, JavaScript puede hacer exactamente lo que hace jQuery
Con la introducción de HTML5, JavaScript también dio un gran paso adelante. Muchas funciones que antes eran exclusivas de jQuery también están disponibles como métodos nativos de JavaScript.
Por ejemplo, esto se aplica a agregar y eliminar clases de JavaScript. La API «classList» le permite darse cuenta de esto de una manera muy similar a jQuery.
Una de las funciones más importantes de jQuery es la opción de acceder a cualquier elemento deseado a través de «$ ()», siguiendo los selectores de CSS. Hasta ahora, incluso esta característica única se ha implementado en JavaScript a través del método «querySelector ()».
document.querySelector("ol li").classList.add("new");En el ejemplo, la clase «nuevo» se asigna a todos los elementos «
- «. En jQuery, una invocación correspondiente es apenas más corta, pero no menos complicada.
$("ol li").addClass("new");Entonces, en muchos casos, ni siquiera necesito jQuery, ya que puedo trabajar de una manera igualmente simple usando JavaScript.
Rendimiento frente a simplicidad
jQuery y sus colegas menos populares definitivamente simplifican el trabajo con JavaScript en muchos casos. Sin embargo, la forma más fácil no siempre es la mejor, especialmente cuando se trata de rendimiento.
Tanto el método jQuery «$ ()» como el método JavaScript «querySelector ()» salen peor que los métodos «getElementsByTagName ()» o «getElementsByID ()» cuando se trata de rendimiento. Con «$ ()» y «querySelector ()», se busca primero en todo el árbol DOM de un documento, respectivamente, los elementos que encajen.
Los dos métodos “getElementsByTagName ()” o “getElementsByID ()” logran el objetivo significativamente más rápido. Por supuesto, los últimos métodos están relacionados con un mayor esfuerzo para los desarrolladores. Incluso aquí, la ligera diferencia de rendimiento puede ser insignificante. Pero definitivamente deberías ser consciente de ello.
Ventaja: compatibilidad coherente con el navegador
Por supuesto, no quiero actuar como si jQuery fuera completamente redundante. Después de todo, hay una razón por la que sigue siendo muy popular y exitoso. Evidentemente, una ventaja es su sencilla aplicación.
Además, estos marcos tienen la clara ventaja de una amplia compatibilidad con navegadores. Si bien los métodos nativos siempre requieren que verifique qué navegador admite qué versión, jQuery hace las cosas un poco más fáciles.
Sé qué navegadores y versiones admiten cada versión de jQuery. Especialmente aquellos que desarrollan versiones anteriores de Internet Explorer sabrán con certeza que jQuery lo admite desde la versión 9 en adelante.
Aquellos que quieran admitir navegadores más antiguos pueden simplemente volver a versiones anteriores de jQuery. Esto facilita el desarrollo de sitios web, ya que sabrá de antemano qué navegadores hay a bordo.
Marcos para cosas particulares
Entonces, soy alguien que renuncia a los marcos siempre que es posible y tiene sentido. De hecho, casi siempre es posible. Generalmente, todo se puede programar en JavaScript. Pero, por supuesto, no siempre tiene sentido hacerlo.
Obviamente, hay situaciones en las que el esfuerzo de desarrollar una codificación JavaScript compleja usted mismo no tiene relación con el resultado. Si, por ejemplo, desea crear animaciones 3D con JavaScript, puede crear su propio marco 3D.
Aquí, sin embargo, tiene mucho más sentido confiar en un marco estable y ligero. En estos casos, me aseguro de que el marco no se base en otros marcos como jQuery, por lo que se puede utilizar de forma libre e independiente.
Conclusión
La cuestión de si utiliza marcos o no es ideológica. En muchos casos, la ganancia de velocidad es marginal. Pero, como desarrolladores, no debemos confiar en jQuery and Co. por conveniencia.
A menudo, un JavaScript nativo puede cubrir todo lo que puede hacer jQuery. Especialmente cuando se desarrolla para navegadores contemporáneos con una compatibilidad retroactiva limitada, lo hará bien sin este marco.
#Por #qué #gusta #trabajar #con #marcos #pesar #tienen #sentido #algunas #situaciones
![El declive de los directorios de guiones: los dinosaurios de los tiempos modernos [IMHO]](https://xn--diseopaginaswebya-ixb.es/wp-content/uploads/2022/02/El-declive-de-los-directorios-de-guiones-los-dinosaurios-de.png)
