Hasta ahora, uno de los mayores impedimentos para la adopción de AMP (Accelerated Mobile Pages) ha sido la imposibilidad de usar cualquier código JavaScript que no sea el proporcionado por la propia plataforma AMP.
Esta restricción tiene sentido si tenemos en cuenta que JavaScript puede ralentizar mucho una página web en teléfonos móviles, especialmente si la fuerza a recalcular fotogramas continuamente.
Parece que el fin de esta restricción podría estar próximo. Pronto dispondremos de un nuevo componente AMP, amp-script, en el que podremos incluir básicamente cualquier JavaScript que necesitemos.
JavaScript en AMP hasta ahora
Hasta ahora, AMP ofrecía mecanismos para paliar esta carencia:
- Para los casos de uso más comunes, AMP ofrece componentes «precocinados», como
amp-sidebar,amp-social-share,amp-analytics,amp-lightbox, y un largo etcétera. - El componente
amp-bindpermite añadir interactividad mediante el enlazado de datos y expresiones. Vale que es Turing-completo, pero no siempre es fácil adaptarlo a un caso de uso concreto (por no hablar de convertir a AMP páginas preexistentes). - Por último,
amp-iframees el único componente que permitía ejecutar JavaScript arbitrario, pero, eso sí, «encarcelado» en un frame independiente.
Presentamos amp-script
Una de las novedades que incorporará AMP próximamente es el componente amp-script, que permitirá ejecutar JavaScript en un entorno restringido y seguro.
Para esto, el componente hará uso de un web worker cuyas vías de comunicación con el hilo principal estarán establecidas de antemano.
Dentro de estas restricciones, sin embargo, la libertad será casi total. Se prevé dar acceso a las API del navegador más usadas, como los objetos document, window, etc.
Para preservar la velocidad de carga de la página, la etiqueta <amp-script> podrá contener código HTML estático que será mostrado inmediatamente durante la carga (y posteriormente mutado a través de las instrucciones de mutación del DOM que resulten de la ejecución del JavaScript).
En cuanto al código JavaScript en sí mismo, deberá estar incluido en un elemento <script type="javascript/worker"> o, si es un recurso externo, deberá ser servido vía HTTPS (en este caso, podrá ser almacenado en una caché AMP).
<script async custom-element="amp-script"
src="https://cdn.ampproject.org/v0/amp-script-0.1.js"></script>
<amp-script src=”https://dominio.com/mi_codigo.js” layout=responsive>
<!-- HTML estático a mostrar en la primera carga -->
<div>...</div>
</amp-script>Estatus
El componente <a href="https://github.com/ampproject/amphtml/tree/master/extensions/amp-script">amp-script</a> y la biblioteca en la que se basa, worker-dom, están aún en pleno desarrollo. Ya están disponibles para experimentar, pero todavía no están listos para su uso en producción.
Se puede consultar su estado en la hoja de ruta del proyecto AMP. El primer paso será liberarlo como componente experimental. La viabilidad de su uso en producción… se irá viendo.
Conclusión
En mi opinión esto podría ser un gran éxito para AMP, que ya de por sí era una solución bastante madura. Quienes estamos aún rezagados en esta tecnología haríamos bien en irle echando un buen vistazo.
¿Tú que opinas? ¿Te parece una buena idea? ¿Le ves futuro a esta incorporación a AMP?
Muchsgracis me sirvió de mucho la información, aunque no he podido hacer funcionar los formulario de hubspot en AMP si me e podido hacer funcionar otras cosas
Excelente nota, desde hace varios meses dejamos de utilizar un chat en nuestro sitio: vivecancun.com por cuestiones de javascript, hoy ya lo tenemos como experimento, han pasado 7 días sin problema, el analizar AMP no presentó error alguno, con el tiempo y liberación de la aplicación esperemos no nos afecte, gracias por la información, saludos.