El futuro de la web está más vivo que nunca. Si quieres conocer las librerías y herramientas esenciales para crear la web del futuro, descárgate este ebook. Más información en http://bbva.info/2t1NEv7
3. 01
La web evoluciona a pasos agigantados. La tecnolo-
gía más usada en este momento puede caer en
popularidad en poco tiempo en detrimento de una
nueva librería o framework que le haga sombra.
¿Recuerdas Knockout.js, MooTools, Backbone?
Alguna de ellas se siguen empleando en la industria
pero su popularidad está por los suelos con la llegada
de Angular, Polymer o React.
En este ebook te vamos a presentar el panorama actual
del ecosistema web, las tendencias de desarrollo y qué
librerías y herramientas van a desempeñar un importante papel
en la web del futuro.
Actualmente existen tres grandes proyectos que ocupan la mayoría de las aplicaciones web. Unos son
frameworks completos como es el caso de AngularJS, y otros son librerías que resuelven problemas concre-
tos, como React para el caso del renderizado de vistas y Polymer para la creación de Web components.
Frameworks y librerías
tecnolo-
r en
de una
bra.
ne?
ndustria
a llegada
rama actual
sarrollo y quéé
n importantee papel
4. Angular es un framework del tipo
MVVM (Model-View View-Model)
o MVW (Model-View-Whatever)
de JavaScript para el Frontend
de aplicaciones web. Está desa-
rrollado y mantenido por Google
y tiene una gran comunidad. Su
nacimiento fue en 2009, pero su
popularidad llegó entre el 2013
y 2014, desbancando del trono
de los frameworks web a Backbo-
neJS, hasta el momento la refe-
rencia en desarrollo de aplicacio-
nes web.
Su popularidad ha hecho que
forme parte de un nuevo stack
para el desarrollo de software
para la web. Hasta el momento,
la mayoría de proyectos se basa-
ban en el stack LAMP (Linux +
Apache + MySQL + PHP). Con la
llegada de Node.js, un entorno
de ejecución que permite utilizar
el lenguaje JavaScript en el Bac-
kend de las aplicaciones web, se
formó el stack MEAN ( MongoDB
+ Express + AngularJS + NodeJS ).
De esta forma se utilizaba el
mismo lenguaje, JavaScript, para
todo el desarrollo web, tanto
Frontend como Backend.
AngularJS
02
FRAMEWORKS Y LIBRERÍAS
5. Angular tiene una curva de
aprendizaje un tanto peculiar.
Si bien es sencillo de aprender
al inicio, a medida que se
requiere más complejidad en el
desarrollo, su adaptación se
hace más laboriosa. Por
suerte, gracias a sus directivas
y al desarrollo open source de
proyectos de terceros, es posi-
ble adaptar casi cualquier pro-
blema de desarrollo con una
librería ya desarrollada.
Cuando desarrollamos una apli-
cación con Angular, donde el
framework se encargue de
todo (controladores, rutas,
vistas, etc), nos encontramos
ante una aplicación SPA (Sin-
gle Page Application), una
aplicación de una sola página.
De esta forma la experiencia de
usuario es muy buena, ya que
se asemeja a una aplicación
móvil, donde cambiamos de
página o vista rápidamente, sin
retardos y más fluida.
Angular posee un gran ecosis-
tema. Es tanto que aprove-
chando las ventajas de una
aplicación SAP, se han exten-
dido al mundo mobile gra-
cias a proyectos como Ionic.
Este proyecto permite que
podamos desarrollar aplicacio-
nes móviles utilizando Angular-
JS. se basa en directivas crea-
das y optimizadas para su
representación en dispositivos
móviles. Se le añade el proyec-
to Apache Cordova (Antiguo
Phonegap) para convertir el
desarrollo en una aplicación
Android e iOS. Esto ha permiti-
do el desarrollo de aplicaciones
híbridas, muy útiles para
probar nuestras aplicaciones
en los dos sistemas operativos
móviles más utilizados.
Más información:
https://angularjs.org/
http://ionicframework.com/
“AngularJS. se basa en
directivas creadas y opti-
mizadas para su repre-
sentación en dispositivos
móviles”
03
FRAMEWORKS Y LIBRERÍAS
6. Esto permite crear componentes
reutilizables que exportan APIs
de terceros, como pueden ser
integrar un video de YouTube de
manera sencilla, un mapa de
Google Maps, una pasarela de
pago con PayPal o Stripe, etc. Al
ser reutilizables, pueden desa-
rrollarse como proyectos open
source y así cualquier desarrolla-
dor puede implementarlos en
sus proyectos.
Pero Polymer ha crecido mucho.
No se trata solo de etiquetas
HTML para insertar componen-
tes en nuestra aplicación. Poly-
mer ha dividido sus compo-
nentes en varios tipos que po-
demos ver en su web:
https://elements.polymer-pro-
ject.org/
Se dividen en elementos del core
de Polymer, componentes basa-
dos en Material Design, etiquetas
para encapsular componentes de
Google, animaciones, entre otros.
Unos de los más interesantes son
los elementos Platinum, que
permiten utilizar servicios HTML
muy útiles como las funcionalida-
des Offline, Notificaciones Push,
etc.
Esto es destacable porque nos
introduce en el nuevo paradigma
de las Progressive Apps. Estas
apps tienen varios puntos.
Polymer
04
FRAMEWORKS Y LIBRERÍAS
7. Esto es ya esencial en cualquier aplicación o web. El tráfico de internet
móvil ya supera al de escritorio. Si nuestra web no se ve bien en dispositi-
vo móvil se pueden perder clientes, ventas, usuarios, etc.
Esto hasta ahora era propio de una aplicación
nativa. Era una excelente manera de conseguir
retención de usuarios en las aplicaciones. Y al igual
que el uso offline, con Service Workers de HTML5
podemos conseguirlo.
Gracias a nuevas tecnologías como los Service Workers, podemos conse-
guir que una aplicación web pueda mostrar contenido offline. Cuando
usamos una app nativa, aunque no tengamos en ese momento cone-
xión a internet, siempre podemos acceder a recursos dentro de la aplica-
ción. Esto se puede conseguir con Service Workers y es el primer paso
para una aplicación progresiva.
05
FRAMEWORKS Y LIBRERÍAS
• Mobile First
• Offline First
• Notificaciones Push
Los Service Workers, en el momento de la redac-
ción de este ebook, no son soportados aún en
todos los navegadores. Pero poco a poco se están
implementando. Funcionan perfectamente en
Google Chrome y en Android. Es de esperar que en
el resto de navegadores se vayan implementando
con el paso del tiempo. Más información:
http://webcomponents.org/
https://www.polymer-project.org/1.0/
8. No hace mucho entró en escena una nueva libre-
ría llamada React y le está poniendo las cosas
difíciles a Angular. React es una librería creada por
Facebook y utilizada en su red social y en Insta-
gram para el renderizado de vistas. No es un
framework como puede ser Angular o Backbone.
Se trata de una librería que puede ser utilizada en
conjunto con los anteriores.
06
FRAMEWORKS Y LIBRERÍAS
React
React es tan popular por su
facilidad de desarrollo. Su
curva de aprendizaje es algo
más sencilla de seguir que An-
gular y su uso es muy sencillo.
React basa su desarrollo en
componentes. En lugar de desa-
rrollar una aplicación completa
con el paradigma Modelo-Vis-
ta-Controlador, descompone la
complejidad en pequeños
componentes con sus funcio-
nalidades. Algo parecido a lo
que hace Polymer pero en lugar
de utilizar web components y
crear componentes reusables
hacia fuera de la aplicación, se
implementan componentes reu-
tilizables dentro de la propia apli-
cación.
9. React también tiene un aspecto
muy bueno y es que puedes uti-
lizar la última especificación
del estándar ECMAScript, que
es el que sigue el lenguaje JavaS-
cript. Esto hace que la librería se
adapte a las mejoras y noveda-
des que trae el lenguaje.
No se quedan ahí las bondades
de esta librería. React, al centrar-
se únicamente en la vista de una
aplicación web, puede ser utili-
zada en el Backend con Node.-
js. Esto ha abierto un nuevo
paradigma en el
desarrollo de aplicaciones web.
Si bien Angular nos trajo el stack
MEAN, React, Node.js y con
ayuda de librerías desarrolladas
por terceros nos introduce en el
concepto de aplicación Isomórfi-
ca.
¿Qué significa esto? Con una apli-
cación SPA aprovechamos las
ventajas que nos proporciona en
cuanto a rapidez y experiencia
de usuario, pero tenemos un pro-
blema. El contenido de una
SPA es inyectado con JavaS-
cript a través de lo que un servi-
dor o un API nos proporcione.
Por lo tanto el contenido no es
renderizado desde el servidor y
esto afecta al SEO de nuestra
página. Una aplicación Isomórfi-
ca permite reutilizar las vistas
que usamos en el Frontend y ser-
virlas desde el Backend. De esta
manera tenemos las ventajas
que aporta una aplicación SPA en
cuanto a velocidad y experiencia
de usuario y el SEO que una apli-
cación renderizada de servidor
nos proporciona.
FRAMEWORKS Y LIBRERÍAS
07
10. Aprovechando que React es una
librería para vistas, independien-
te del navegador, el equipo
detrás de su desarrollo ha
creado el proyecto React
Native. Esta nueva librería permi-
te que con código JavaScript y
utilizando unos componentes ya
definidos por ellos mismos,
podamos desarrollar una aplica-
ción nativa para iOS y también
para Android. Es un paso más
allá que lo que nos proporciona
Ionic. Ionic nos permite crear
una aplicación híbrida, que es
una aplicación web optimizada
pero embebida en un visor web
de la app mobile. React Native
por su parte, nos da una aplica-
ción Nativa, como si desarrolláse-
mos en Objective C, Swift o Java,
pero empleando JavaScript
como si programásemos para la
web.
Aunque lo coloquemos en
esta sección, ECMAScript6
no es un framework, pero
tiene y va a tener un papel
muy importante en la web.
El lenguaje JavaScript se
basa en los estándares
W3C y en concreto la orga-
nización ECMA. JavaScript
ha tenido varias versiones
desde su creación hace 20
años. Su primera versión
estable data de 1997. La
versión 3 es de 1999, su
revisión 3.1 llegó en 2008
y hasta hace muy poco,
desde el 2011 teníamos la
versión 5.1.
08
FRAMEWORKS Y LIBRERÍAS
ECMAScript6 (ES6 o ES2015)
11. La versión 6 fue aprobada en junio
de 2015 y poco a poco los nave-
gadores han ido implementando
sus novedades, pero aunque aún
no estén disponibles todas las me-
joras, podemos utilizar su sintaxis
desde hoy mismo por medio de
traductores de código llamados
transpilers.
La nueva versión bebe mucho de
preprocesadores de JavaScript
como CoffeeScript, con el uso de
arrow functions que reducen la
cantidad de código y mejoran la
legibilidad del mismo.
ECMAScript6 hace de JavaScript
un lenguaje muy completo, apor-
tándole clases, módulos y funcio-
nes nativas que antes solo era posi-
ble implementar por medio de
librerías de terceros, como las Pro-
mises, pedir datos vía AJAX, etc. Y
algo muy importante son los mó-
dulos. De esta forma podemos
separar el código de nuestras apli-
caciones en pequeños ficheros, sin
la necesidad de un framework o
una librería externa.
En el desarrollo software, la pata más importante son
los lenguajes que empleamos, pero también son
una parte clave las herramientas que utilizamos en el
día a día, que nos ayudan a mejorar y optimizar nues-
tros desarrollos, permitiendo que nos enfoquemos en
el código.
El campo de las herramientas JavaScript es muy
amplio, tanto o más como el de los frameworks y libre-
rías que disponemos para el Frontend web. En ocasio-
nes puede resultar agobiante tantas tecnologías. El
motivo de este ebook es mostrarte todo lo que hay
disponible para que las conozcas e implementes las
que mejor se adapten a tus gustos y necesidades.
09
FRAMEWORKS Y LIBRERÍAS
Herramientas
12. Babel es un transpilador de
ECMAScript 6 a ECMAScript 5.
¿Qué es un transpilador? Es una
herramienta que te permite escri-
bir en un lenguaje y que él lo
transforme a otro. Babel, antes
conocido como 6to5, te permite
que desarrolles tus aplicaciones
web empleando la versión más
actual del estándar de JavaScript
(ES6 incluso algunas característi-
cas de la futura ES7) y él se
encarga de transformarlo a la
versión que actualmente sopor-
tan todos los navegadores, la
versión del estándar 5.1.
De esta forma puedes desde hoy
mismo utilizar la versión del len-
guaje que se utilizará muy
pronto de forma nativa en los
navegadores.
Babel
10
FRAMEWORKS Y LIBRERÍAS
13. Browserify es una herramienta
que permite que utilicemos la
sintaxis CommonJS, utilizada
en Node.js, en el Frontend de
nuestras aplicaciones web.
Hasta el momento, si queríamos
modularizar en pequeños fiche-
ros la lógica de programación del
Frontend de nuestra webapp,
debíamos enlazar todos los
ficheros JavaScript en el HTML
por medio de tags script, o utili-
zar librerías como RequireJS que
utilizan la sintaxis AMD para
crear los módulos.
Browserify hace esto más senci-
llo, ya que nos permite progra-
mar con la sencillez que tiene
Node.js, utilizando module.ex-
port para exportar los módulos
que creamos y requiere para
importarlos, sin mucha más
complicación.
Esta herramienta se encarga de
concatenar todo el código
Javascript necesario y minifi-
carlo. Con la llegada de ES6,
parece que esta herramienta no
tendría sentido, pero se sigue
utilizando junto con el plugin
Babelify, que permite unir todo el
código ECMAScript 6 que tenga-
mos y traducirlo a la sintaxis 5.1
que actualmente entienden
todos los navegadores.
Browserify
11
FRAMEWORKS Y LIBRERÍAS
debíamos enlazar todos los
ficheros JavaScript en el HTML
por medio de tags script, o utili-
zar librerías como RequireJS quee
utilizan la sintaxis AMD parpara
crear los módulos.
Browserify hace esto mámás senci-
llo, ya que nos permitete progra-
14. Si eres un desarrollador web profe-
sional seguramente utilices prepro-
cesadores de CSS como Sass, Less
o Stylus, y también herramientas
como Browserify, Babel para tradu-
cir tu código JavaScript. Tendrás
un entorno de desarrollo y otro
de producción donde tu código
esté preparado y optimizado para
su utilización.
Para tener todo esto en orden
surgen los gestores y automati-
zadores de tareas. Se trata de un
fichero donde definiendo unas
tareas concretas, como pueden
ser el precompilado de CSS, la con-
catenación de archivos JS y su
minificado, optimización de imáge-
nes, etc. su motor se encarga de
realizarlas.
El primero en surgir, en el mundo
Frontend, fue Grunt. Definiendo un
Gruntfile, con tareas configuradas
en formato JSON y utilizando plu-
gins open source desarrollados por
terceros, podemos llevar a cabo
todas esas funciones que de ser
realizadas “manualmente”, consu-
miría mucho tiempo. Este tipo de
herramientas permite a los desa-
rrolladores enfocarse de nuevo en
su código y ahorrar tiempo.
Grunt fue muy popular y utilizado
en su momento, pero surgió un
competidor. Gulp hace lo mismo
que Grunt pero de una forma
más rápida, más legible y sus
tareas pueden definirse utilizando
JavaScript en lugar de JSON.
Gulp ha desbancado a Grunt del
trono de gestores y automatizado-
res de tareas por su sencillez y
porque todos los plugins que hay
desarrollados para Grunt los
puedes encontrar igualmente para
Gulp.
Gulp/Grunt
12
FRAMEWORKS Y LIBRERÍAS
15. Webpack
13
FRAMEWORKS Y LIBRERÍAS
Con el uso de React se hizo muy
popular esta herramienta, que se
trata de un module bundler. Diga-
mos que sustituye a Grunt/Gulp
en las tareas de construcción y pre-
paración para producción (prepro-
cesado, concatenado, minificación,
etc).
Al igual que los anteriores gestores
de tareas, Wepack posee una gran
comunidad y ya existen numero-
sos plugins que te permiten realizar
las tareas más comunes y necesa-
rias.
NPM son las siglas de Node Pac-
kage Manager, es decir, Gestor
de paquetes de Node.js. Aunque
actualmente engloba módulos y
librerías tanto para Node.js como
para el navegador, así como plu-
gins para los gestores de tareas:
Grunt, Gulp, Webpack y herra-
mientas como babel, postcss, etc.
NPM se ha convertido en un
estándar a la hora de iniciar un
proyecto web, ya se trate de una
aplicación Frontend, como de
Backend con Node.js, así como
para pequeños módulos que solu-
cionen problemas concretos.
NPM
16. Sirve como manifiesto donde
incluimos las dependencias
usadas en el proyecto con sus
números de versión, descrip-
ción, etc, así como para ejecutar
comandos a través del objeto
‘script’. Esto permite en ocasio-
nes que podamos ejecutar co-
mandos de desarrollo sin nece-
sidad de utilizar gestores como
Gulp, o directamente llamar a
estos gestores a través de los
scripts.
Paralelo a NPM tenemos a
Bower, un gestor de dependen-
cias para el navegador, donde
podíamos descargar y em-
plear en nuestros proyectos
librerías como jQuery, Angular,
Backbone, etc. Pero con la apari-
ción de proyectos como Browse-
rify, que nos permiten importar
módulos, o mejor aún con EC-
MAScript 6 que ya los implemen-
ta de forma nativa, podemos
utilizar NPM. De hecho gran
parte de los proyectos, si no
todos, se han movido de Bower
a NPM, por lo que ya no es nece-
sario tener dos ficheros de confi-
guración y dependencias (packa-
ge.json para el caso de NPM y
bower.json para el caso de
Bower), con NPM podemos
tenerlo todo agrupado en un
único gestor de módulos y fiche-
ro.
14
FRAMEWORKS Y LIBRERÍAS
11111444444444444444444444444444444444444444444444444444444444444444444444444444444444444444
17. JSPM
15
FRAMEWORKS Y LIBRERÍAS
JSPM es el acrónimo de JavaS-
cript Package Manager. Pode-
mos decir que es un NPM exten-
dido para el ecosistema JavaS-
cript. Con NPM únicamente
podemos instalar módulos y
librerías que estén en el registro
NPM. En cambio con JSPM
podemos indicar varios sitios,
NPM es uno de ellos, pero tam-
bién podemos instalar desde
GitHub o desde el propio registro
de JSPM.
Esto nos permite utilizar las últi-
mas versiones de los proyec-
tos que estén disponibles en
Github sin importar si están o no
en NPM, e incluso utilizar módu-
los privados que no tienen
porque estar en el registro de
NPM.
JSPM se basa también en el siste-
ma de carga de módulos nativo
de ECMAScript6, llamado Sys-
temJS cuya sintaxis y forma de
trabajar se parece a la librería
RequireJS, pero de forma nativa
sin tener que importar otra.
Este sistema es interesante y
dará que hablar en los próximos
meses, ya que se integra perfec-
tamente con NPM y no es nece-
sario tener ficheros adicionales
de configuración. Únicamente
un sólo package.json
de
en-
aS-
nte
y
tro en NPM, e incluso utilizarr mód
18. PostCSS
16
FRAMEWORKS Y LIBRERÍAS
No podemos olvidarnos de
PostCSS. El ecosistema de desa-
rrollo web no es sólo JavaScript, el
CSS tiene un papel también muy
importante.
Hasta ahora en lugar de utilizar
CSS plano, hemos empleado pre-
procesadores como Less, Sass o
Stylus, que nos permitían usar
variables, funciones, etc. Con ello
tratábamos a CSS como un len-
guaje de programación y nos
ayudaba a ser ágiles en nuestros
proyectos.
Uno de los problemas que tienen
los preprocesadores es que gene-
ran un CSS que no podemos
más adelante editar. Pueden
generar código que necesariamen-
te no queramos por mucho que
hayamos optimizado el código en
la sintaxis del preprocesador.
Con PostCSS podemos escribir
CSS plano, controlando en cada
momento lo que queremos escri-
bir. Y con esta herramienta (que
corre bajo Node.js) se puede modi-
ficar el resultado final por medio de
plugins, como el autoprefijador,
para no preocuparnos de escribir
todos los prefijos para cada nave-
gador concreto.
A PostCSS se le une CSSNext.
¿Esto que es? Al igual que la espe-
cificación de JavaScript avanza y
podemos usar herramientas como
Babel para usarlo en este momen-
to, con CSS pasa algo parecido. Se
están desarrollando nuevas especi-
ficaciones para por ejemplo usar
variables en CSS. Hoy en día los
navegadores aún no lo soportan,
pero con CSSNext como plugin de
PostCSS podemos escribir nues-
tro código de estilo CSS con la
sintaxis futura a la vez que lo pode-
mos ver corriendo en los navega-
dores actuales.
19. Conclusión
17
FRAMEWORKS Y LIBRERÍAS
El futuro de la web está más
vivo que nunca. Las tecnologías
que estamos usando en este
momento es posible que nos
parezcan obsoletas dentro de un
año, sin ir más lejos.
Sin duda es un momento muy
importante y conviene estar al
tanto de las novedades que van
apareciendo para conocerlas y
saber cuál es la más adecuada
según el problema que tratemos
de resolver.
La clave es tener la mente abier-
ta y tener en cuenta que las apli-
caciones web cada vez son
más grandes. Y es importante
modularizarlas en pequeños com-
ponentes con su propia lógica y
que puedan componer otros más
grandes para así, trozo a trozo,
implementar el desarrollo comple-
to, de una manera más escalable
y mantenible.
20. Regístrate
para estar al día
de las últimas
tendencias
conversa con nosotros en:
BBVA no se hace responsable de las opiniones publicadas en este documento.
wwww.bbvaopen4u.com
Comparte
este ebook