Categorías
Citas ECMAScript

El objeto this en ECMAScript

Uno de los grandes misterios de ECMAScript desvelado 🙂

We said earlier that this is not an author-time binding but a runtime binding. It is contextual based on the conditions of the function’s invocation. this binding has nothing to do with where a function is declared, but has instead everything to do with the manner in which the function is called.

When a function is invoked, an activation record, otherwise known as an execution context, is created. This record contains information about where the function was called from (the call-stack), how the function was invoked, what parameters were passed, etc. One of the properties of this record is the this reference which will be used for the duration of that function’s execution.

You Don’t Know JS: this & Object Prototypes — Leslie Zhang

Y qué decir de los libros de la serie You don’t know JS: muy recomendables.

Categorías
Citas Desarrollo web ECMAScript

DOM vs. todo lo demás

Como ya he comentado alguna vez, no estoy precisamente a la última en las nuevas tendencias de desarrollo web (¿?). Cuando empecé en esto, Netscape 4 era mayoritario, y empezaba a manifestarse una guerra de navegadores frente a Internet Explorer.
Obviamente todo ha cambiado mucho: ordenadores, navegadores, pantallas, soporte de estándares, velocidad de conexión, las librerías de javascript, los frameworks web, los móviles, y ese mundo inabarcable en el que se está convirtiendo todo lo relacionado con el desarrollo web: npm anuncia 475.000 building blocks ahora mismo.
Lo raro es no tener fatiga de desarrollo web y javascript. Lo normal es sufrir ansiedad porque es imposible estar al día.

Terminado el inciso pseudohistórico y de salud mental, y antes de la cita del 2015 que quería incluir, me gustaría dejar apuntadas algunas reflexiones no muy elaboradas, pero que merecen tenerse en cuenta:

  1. Cada bloque de código y fichero que se incluye en una página web, implica un aumento del tiempo de carga: ya sea una imagen, o una hoja de estilos. Cada kilobyte cuenta.
  2. Cada nodo que se añade al DOM, es un elemento más a tener en cuenta para el motor de renderizado del navegador.
  3. Cuando usamos una librería que trabaja con el DOM o una abstracción del mismo, implica que se incrementa el número de eventos que están a la espera aunque no se utilice. Afecta al rendimiento (tiempo de carga, uso de memoria,…). Yo desde hace años tengo la imagen mental de un frasco lleno de avispas nerviosas 🙂
  4. Cada nueva librería, plugin,… añade complejidad y posibles problemas de compatibilidad.
  5. La dependencia en el desarrollo de wadus-script junto un equipo de desarrollo con más o menos conocimiento específico, puede tener un alto coste si hay que reemplazarlo.

Claro, que también se puede ver desde el siguiente punto de vista:

  1. Hay código y ficheros de una página web, que valen su peso en oro.
  2. Algunos elementos extra de HTML, identificadores o clases pueden ser muy útiles (aunque todavía no lo sepamos).
  3. Hay librerías que simplifican mucho el tiempo y la eficiencia en el desarrollo.
  4. Al igual que en el punto anterior, hay librerías que pueden simplificar el desarrollo e incluso solucionar problemas de compatibiliad (como html5shiv o es5-shim).
  5. El uso del wadus-script de turno por un equipo competente, puede tener resultados brillantes.

Por lo tanto, depende es una palabra clave ante estas cuestiones. Al final el factor determinante debería ser el proyecto a desarrollar y el rendimiento (en tiempo de carga, tiempo hasta que se puede interactuar, tiempo de desarrollo, calidad de código y facilidad de mantenimiento,…).

La teoría, en ocasiones es sencilla 🙂

Y ahora, la cita en cuestión.

The DOM Is Just Fine

It puzzles me that developers seem to create themselves a problem and then they point the finger around to search and blame the cause: no, the DOM is not your problem, the fact you brought an over-engineered abstraction on top of a deadly simple task, like a table that needs some quick update, is the real problem you don’t want to see.
It scares me that developers behind frameworks seem to be often incapable of getting some fresh air and think out of the cell they put themselves in: learning and using only that framework, ignoring everything else … sometimes forgetting even common sense, probably shadowed by the framework approach.
Let’s do ourselves a favor, let’s stop being religious about any sort of framework and learn what the native world has to offer, what other frameworks have to offer too, and what’s the best solution for that specific problem, which is never every problem we have!
Every framework was born to solve a very specific problem … have you asked yourself if that is really the same problem you have and the one you need to solve?
Moreover, there will always be a faster, ad-hoc, way to do this or that and your framework cannot cover all the cases … it’s actually the opposite: the more cases it will cover, the slower it will be. So let’s please stop moaning about the DOM and start doing things in a different way … shall we?
We’ll be those with most benefits, after all, so please think about it.

The DOM Is NOT Slow, Your Abstraction Is Andrea Giammarchi