Cual es la mejor forma de gestionar los scripts .js

[miktrv]

Buenas,

Estoy en un proyecto bastante grande, donde en cada página se cargan diferentes .js

Usamos Jquery. Me gustaría saber cual es la mejor forma de usar los componentes .js y de que forma optimizar tantas llamadas.

Un saludo

[dashtrash]

Te cuento las líneas principales de cómo lo gestiono yo. Esto habría que adaptarlo según el backend que tengas.
Primero, una cuestión de enfoque:
- una página web es un html más un conjunto de dependencias.Estas dependencias son js, css, imágenes, etc.
Esto parece una obviedad, pero no lo es cuando se construye sobre ello:
- Una página debe *conocer* sus dependencias.Es decir, no es que simplemente se metan tags "scripts" y "link rel" en la plantilla.Eso lleva al caos en poco tiempo.
Lo que más exactamente quiere decir eso, es que la clase base "Page" tiene un método que es capaz de devolver la configuración de dependencias de la página.
- Este método es el que es usado al renderizar la plantilla, para generar el código necesario para incluir esos scripts/css.

Este código no es necesariamente tags html "<script".Puede ser una definición utilizada por require.js. Puede ser que tengas un combinado/minificado js para esa página.

Por ejemplo, supongamos que en la página index necesitas jQuery y Google Analytics.
Entonces, la clase IndexPage:

Código PHP:

function getDependencies()
    {
           return array("js"=>array("jQuery","GoogleAnalytics"));
    }
 

(En realidad, esto es una versión simplificada...)
Por cada uno de esos elementos, se busca su definición, que es única para todo el site.Digamos que está en la clase HTMLDependencyManager:

Código PHP:

function getDependencyConfig()
     {
              return array(
                    "jQuery"=>array(
                               "url"=>"....",
                               "minificable"=>true,
                               "combinable"=>true,
                               "requires"=>array()
                     ),
                     "GoogleAnalytics"=>array(
                         "url"=>"...",
                         ...
                     )
                                
              );
      }
 

Ahora la página "sabe" cuáles son sus dependencias.Lo importante es que esta información es independiente de cómo se introducen las dependencias en la plantilla.
Ejemplos de cosas que se pueden hacer:
- En deployment, generar distintos minificados por cada tipo de página, o un minificado común + uno por página.
- Paralelizar requests: si se especifica una dependencia como un path local, rotar distintos subdominios para paralelizar la carga.
- Estrategias de carga: si la página, por cada dependencia, indica si la carga es asíncrona o no, si el script se carga en respuesta a un evento, si se carga on-demand, etc.

Todo esto lleva al final al uso constante de Promises, y programación asíncrona.
Para que más o menos te hagas una idea, el código acaba siendo del tipo:

Código Javascript:

App.getModule("User").then(
          function(user){ 
               if(user.isLogged())
               {...}
          });
 

Donde App es un gestor central (la aplicación) y el módulo "User", es una de las dependencias js especificadas en la página, y el parámetro "user" es la instancia del módulo "User".
Si los ficheros necesarios para que funcione el módulo "User" están cargados o no, y, si no lo están, de dónde se descargan,etc, son transparentes al código.

En definitiva, es *parecido* a require.js, pero con más metadata, y pensando en su integración por el lado del servidor.

[miktrv]

Muchísimas gracias por tu respuesta!!!

Después de tus comentarios, sólo me queda una duda... Qué herramientas uso? Comentas que require js no es buena opción...

Saludos!!

[dashtrash]

require.js es una buena opción, pero hay 2 puntos a notar:
- Require.js es una solución por el lado del cliente.Más exactamente, se encarga de que si una función necesita x módulos, que esos x módulos se carguen, si no lo estaban ya.
Esto puede ser suficiente en tu caso, no lo sé.A mí me ha resultado útil (usado con dojo toolkit), en sistemas con muchísimo js (sistemas de backoffice, en single-page).En estos sistemas, el tiempo de carga no es esencial, es más importante mantener el desarrollo js controlado (son cientos de ficheros js).
Si el tiempo de carga es esencial, una de las cosas que echo de menos en require.js es la paralelización de carga (descargando js de varios subdominios a la vez), y una cosa importante: cuando se llama a require(), los scripts necesarios se descargarán.
Esto puede parecer algo "bueno", pero no tiene por qué serlo.Por ejemplo:

Código Javascript:

require(['module'], function(module){
    module.funct();
});
 

Lo que significa eso es: descargate el módulo, si es necesario, y ejecuta la funcion.
Sin embargo, esto:

Código Javascript:

App.get("module").then( function(module){
    module.funct();
});
 

Para mí, significa : cuando la política de carga de la página, haya cargado el módulo "module", ejecuta la función.Es decir, el módulo no se descarga instantáneamente.
El porqué, es por mantener bajo control qué se carga cuando.Hay una política de carga de javascripts (prioridades, especificadas en la configuración de dependencias de la página).

Supón que tú quieres que el módulo GoogleAnalytics tenga una alta prioridad.Al principio, todo va bien.Pero poco a poco se van añadiendo scripts.Incluso si se hace con require.js, algunos de esos scripts acaban apareciendo antes de la llamada a Analytics.Y poco a poco la llamada a Analytics se va retrasando.Si la política de carga está definida (es un simple objeto json), los módulos se cargarán cuando esa política especifique, no simplemente según su posición en la página html.
Es decir, mientras require.js es "estas son las dependencias necesarias para la función, y si no están, las cargo", la versión que uso, sólo dice "estas son las dependencias necesarias", pero cuándo se cargan, depende de la política global.
De esta forma, tienes un control muy grande sobre los tiempos de carga.

Por otro lado, require.js no resuelve aspectos de la carga como los css, minificados/combinados, etc. Esas son cosas a resolver en tiempo de deployment.
Asi que, require.js *puede* ser una muy buena opción, dependiendo del tipo de web.Pero no resuelve todo el problema.

[miktrv]

Genial,

Una explicación excelente :)

Entiendo lo que me comentas, pero entonces me quedo con la duda, qué herramientas recomendarías usar para poder establecer y controlar todos los assets tanto a nivel de css como a nivel de js?

Un saludo!

[dashtrash]

Las herramientas que uso, me las he ido desarrollando yo después de muchos proyectos y años, porque se adaptan a mi forma de programar, y, sobre todo, porque tienen que formar un conjunto "cohesivo" entre front y back.La mayor parte de las herramientas (incluidos frameworks) son o front, o back.Y yo he necesitado herramientas que vayan de un extremo al otro (y de un "momento" a otro, es decir, el momento de codificación, deployment y ejecución).
Por eso, herramientas exactas no te puedo dar..Sólo una filosofía sobre qué buscar en ellas.Todas las herramientas, frameworks, etc,etc, te venden lo que hacen bien (con preciosos grafiquitos y demos), pero si no tienes una filosofía propia de lo que quieres, acabas con un conjunto inconexo de herramientas, y teniendo que adaptarte a sus filosofías, en vez de al revés.

Pero, supongamos que comienzas analizando qué necesitarías a nivel de página, podrías acabar con algo como esto:

Código Javascript:

{
    dependencies:
    {
         css:[
              { source:'....',
                 processing:'{
                               type:'sass',
                              destination:'....'
                              },
                 combine: true
              },
              { .... }
         ],
      'js':[
            {
                modlule:'User',
                combine:false,
                 loadOn:'PAGE_LOADED',
                 fire:'USER_LOADED'
            }
         ]
    }
}
 

Es decir, simplemente, configura qué quieres, en un json.Este json, luego, es fácilmente transformable a lo que requiera cada una de las herramientas que elijas.
Insisto, no es tan importante la herramienta, sino la filosofía.La pregunta no es si "require.js" "vale" o no, sino cómo conseguir que require.js haga lo que quiero.