Herramientas para trabajar en Front-end. En esta presentación hablo de los tipos de herramientas con los que contamos que nos ayudan a automatizar y a realizar mejor nuestras actividades como desarrolladores.

1. FRONT-END TOOLING
David Avellaneda

2. AGENDA
➤ about:me
➤ intro
➤ package management
➤ workflow & tasks automation
➤ bundling systems
➤ scaffolding

3. DAVID AVELLANEDA
➤ ing. sistemas
➤ co-fundador Monoku
➤ co-organizador BogotáJS
➤ co-organizador JSConf.co
➤ co-organizador char.la
➤ @davsket

4. INTRO
too many options

5. Muchas herramientas
que usamos hoy en día
no existían hace
5 años...

6. Ya que es gracias al nacimiento
de NodeJS en el 2009 (y NPM en
el 2010), que surgen nuevas
herramientas para facilitar
nuestro trabajo día a día.

7. PACKAGE MANAGEMENT
manejo de dependencias

8. ANTES
A. Necesitas una librería
B. Buscas la librería (Google)
C. Buscas donde descargarla
librería en la página
D. La descargas
E. La agregabas a tu proyecto
F. la importabas en tu HTML
G. Si necesitas otra repites el
paso A.

9. ANTES (PRINCIPALES PROBLEMAS)
A. Gastas mucho tiempo buscando el
script
B. Al descargarlo debes ordenar tus
librerías manualmente
C. Si clonaste un proyecto hay dos
opciones:
1. Las librerías están incluidas en
el repositorio (ok, no tienes
que repetir el proceso, pero el
repositorio pesa mucho más
de lo que debería)
2. No están incluidas las
librerías, pero hay
documentación de dónde
descargar cada una.

10. HOY
A. Necesitabas una librería
B. La buscabas en el gestor de
paquetes
C. La instalas con un comando
D. la importabas en tu HTML o
JS
E. Si necesitas otra repites el
paso A.

11. HOY (VENTAJAS)
A. Puedes buscar la librería
desde la terminal
B. Sólo buscas en un mismo
lugar
C. Se mantiene un registro de las
librerías requeridas para el
proyecto
D. Ya las librerías pueden estar
excluidas del repositorio
E. Todo se reinstala con un solo
comando

12. OPCIONES DE PACKAGE MANAGEMENT

13. NPM (NODE PACKAGE MANAGER)
➤ Es el primer gestor de
paquetes para JavaScript
➤ Es el gestor de paquetes por
defecto para en entorno de JS
en Node.js
➤ Tiene en la página el listado de
todos los repositorios
➤ Usa un archivo llamado
package.json
➤ Se usa tanto para instalar
dependencias como para
publicar módulos a NPM
$ npm init
$ npm install lodash --save
$ npm uninstall lodash --save
$ # new clone
$ npm install

14. BOWER
➤ Creado y mantenido por
Twitter
➤ Usa Github como fuente de
librerías
➤ Usa un archivo que se llama
bower.json (y opcionalmente
un .bowerrc)
➤ Se usa tanto para instalar
dependencias como para
exponer repositorios a Bower
➤ Está más centrado en módulos
para Front-end
$ npm install -g bower
$ bower init
$ bower install lodash --save
$ bower uninstall lodash --save
$ # new clone
$ bower install

15. YARN
➤ Es la competencia más
reciente y directa de NPM
➤ Creado y mantenido por
Facebook
➤ Es más rápido y maneja mejor
el cache
➤ Es muy reciente...$ npm install -g yarn
$ yarn init
$ yarn add lodash
$ yarn remove lodash
$ # new clone
$ yarn

16. NPM VS BOWER
➤ NPM tiene mayor
mantenimiento
➤ Bower está comenzando a perder
mantenibilidad y generación de
nuevos features
➤ NPM es estándar de Node.js
➤ NPM es más rápido y eficiente
que Bower
➤ NPM no usa repositorios como
paquetes (son muy diferentes)
➤ NPM gestiona las versiones
recursivamente, no hay
colisiones
vs

17. o por lo menos usar alguno
recomendación: usar

18. WORKFLOW & TASKS AUTOMATION
o cómo facilitar nuestro trabajo diario

19. ANTES
A. Tienes tus archivos de estilos
(probablemente con algún
preprocesador como LESS, Sass o
Stylus)
B. Tienes tus archivos JS (deseablemente
tu código en más de un solo archivo)
C. Tienes que subir una nueva versión...
D. Compilas los estilos con un comando
largo y los mandas a una carpeta
E. Compilas los scripts con otro
comando
F. Minificas/Ofuscas los generados para
que sean más livianos
G. etc..

20. ANTES (PRINCIPALES PROBLEMAS)
A. Te toca lidiar con la terminal por
montones
B. Es difícil de mantener comandos
(varían por OS)
C. Si no usas la terminal te toca estar
subiendo a algún servicio web como
Closure (Google) etc.
D. Tienes que memorizar o
documentar tu proceso, es manual y
puede fallar con facilidad
E. Si deseas agregar un paso adicional,
te toca tenerlo en cuenta en tu
proceso de trabajo
F. Probablemente termines agregando
los compilados al repositorio

21. HOY
A. Instalas una herramienta
como Grunt, Gulp o Broccoli
(etc)
B. Configuras tu flujo de trabajo
C. Ejecutas un comando en la
terminal
D. Puedes crear flujos más
complejos, como
automatización de build de
Cordova, templates,
documentación, etc.

22. HOY (VENTAJAS)
A. Lidias con JavaScript para
configurar el flujo de trabajo
B. El módulo se encarga de
hacer esto por tí
C. Puedes replicar el proceso en
otros ambientes (CLI) (OS)
D. Puedes excluir los compilados
(distribution) del repositorio

23. OPCIONES DE AUTOMATIZACIÓN

24. GRUNT
➤ Es el primer task runner
(popular)
➤ Tiene una gran cantidad de
plugins: sass, coffee script, jshint,
less, stylus, etc.
➤ Se apoya en un archivo que se
llama Gruntfile.js
➤ Instalas con npm los plugins a
usar
➤ Los agregas a la configuración
➤ Ejecutas la tarea
➤ Puedes crear flujos de tareas con
aliases
$ npm install -g grunt-cli
$ npm install grunt --save
$ grunt <task-name>

25. $ npm install --save
grunt-contrib-concat
$ npm install --save
grunt-contrib-uglify
$ grunt concat
$ grunt uglify
$ grunt
/* Gulpfile.js */
module.exports = function(grunt) {
grunt.initConfig({
concat: {
'dist/app.js': ['app/js/a.js', 'app/js/b.js']
},
uglify: {
build: {
src: 'dist/app.js',
dest: 'dist/app.min.js'
}
},
});
grunt.loadNpmTasks('grunt-contrib-uglify');
grunt.loadNpmTasks('grunt-contrib-concat');
grunt.registerTask('default', ['concat', 'uglify']);
}

26. GULP
➤ Gulp funciona bajo el concepto
de streams (unix)
➤ Usas módulos que funcionan
como tuberías
➤ Estos módulos reciben
archivos, los modifican y los
mandan como resultado
➤ Usa un archivo llamado
Gulpfile.js
➤ Ya no trabajas con un objeto
grande de configuración
➤ Al final es más fácil de
mantener
$ npm install -g gulp
$ npm install gulp --save
$ gulp <task-name>

27. $ npm install --save
gulp-concat
$ npm install --save
gulp-uglify
$ gulp dist
$ gulp
/* Gulpfile.js */
var gulp = require('gulp')
var concat = require('gulp-concat')
var uglify = require('gulp-uglify')
gulp.task('dist', function() {
return gulp.src('app/js/*.js')
.pipe(concat('app.js'))
.pipe(uglify())
.pipe(gulp.dest('dist/js/'))
})
gulp.task('default', ['dist'])

28. $ gulp watch
$ gulp
/* Gulpfile.js */
var gulp = require('gulp')
var concat = require('gulp-concat')
gulp.task('concat', function() {
return gulp.src('app/js/*.js')
.pipe(concat('app.js'))
.pipe(gulp.dest('dist/js/'))
})
gulp.task('watch', function() {
gulp.watch('app/js/*.js', ['concat'])
})
gulp.task('default', ['watch'])

29. BROCCOLI
➤ Funciona como todo un flujo
para la aplicación
➤ Es rápido
➤ Usa un archivo que se llama
Brocfile.js
➤ Es opinionado
➤ Cuenta con muchos plugins
también
➤ Es usado por Ember-cli
➤ No expone tareas, es todo el
flujo
$ npm install -g broccoli-cli
$ npm install broccoli --save
$ broccoli build dist

30. $ npm install --save
broccoli-sass
$ npm install --save
broccoli-coffee
$ npm install --save
broccoli-merge-trees
/* Brocfile.js */
var compileSass = require('broccoli-sass');
var filterCoffeeScript = require('broccoli-coffee');
var mergeTrees = require('broccoli-merge-trees');
var sassDir = 'app/scss';
var coffeeDir = 'app/coffeescript';
// Tell Broccoli how we want the assets
// to be compiled
var styles = compileSass([sassDir],
'app.scss', 'app.css');
var scripts = filterCoffeeScript(coffeeDir);
// Merge the compiled styles and scripts into
// one output directory.
module.exports = mergeTrees([styles, scripts]);

31. BROCCOLI VS GRUNT VS GULP
configuración media/compleja fácil fácil
personalización baja alta alta
mantenibilidad alta media alta
curva
alta (poca
documentación)
baja
media-alta (una
vez entiendes
streams)
ecosistema medio grande+ grande
tareas no sí sí

32. BUNDLERS
empaquetamiento de la aplicación

33. SIN BUNDLER
A. Tienes un conjunto de scripts,
estilos, imágenes, etc.
B. Necesitas mandar eso a
producción
C. Manualmente procesas cada
origen para mandarlo al
destino deseado
D. Haces el paso anterior para JS,
luego para CSS, luego para
Imágenes, etc.
E. Si tienes tiempo automatizas
esta tarea con Grunt, Gulp o
Broccoli

34. SIN BUNDLER (PROBLEMAS)
A. La actividad de agrupar
(empaquetar) estos archivos
es manual
B. Puede variar entre ambientes
y sistemas operativos
C. Debes tener cuidado con el
orden y las dependencias

35. CON BUNDLER
A. Usas un empaquetador como
webpack u otro
B. Instalas los plugins (sass,
ES6, coffee-script, etc)
C. Configuras qué empaquetar
D. El empaquetador hace el
trabajo por tí

36. CON BUNDLER (VENTAJAS)
A. Son más eficientes para el
manejo de empaquetamiento
B. Entienden del manejo de
dependencias entre diferentes
módulos
C. Pueden compilar en un solo
script TODOS los recursos si
lo deseas (css/js/img/html)
D. Si creas un nuevo módulo,
solamente lo importas como
dependencia de otro
(automágicamente)

37. TASK AUTOMATION VS BUNDLERS
A. Los bundlers generalmente
no te permiten definir tareas
B. No obstante controlan el flujo
de trabajo de tu proyecto
C. Task automators
naturalmente no saben cómo
manejar las dependencias
(con plugins sí)
D. Hay plugins de los bundlers
para los task automators (no
son excluyentes)

38. OPCIONES DE BUNDLERS

39. REQUIRE.JS + R.JS
➤ Usa AMD (w0t?)
$ npm install --save requirejs
$ # creas tu build.js
$ node build.js

40. AMD
(ASYNCHRONOUS MODULE DEFINITION)
➤ Es asíncrono
➤ Usa callbacks para invocar los
módulos cuando sus
dependencias hayan cargado
➤ Usado en web, donde los
scripts se halan por request
➤ El cb de require es ejecutado
cuando todos los scripts hayan
terminado de descargarse
/* main.js */
require(['hello'], function
(hello) {
console.log(hello)
// > hello there
})
/* hello.js */
define([], function () {
return 'hello there'
})
require([deps], cb)
define('name', [deps], cb)

41. REQUIRE.JS + R.JS
➤ Usa AMD (ok!)
➤ Funciona sin compilar todo en
paquetes (bundles)
➤ Usa R.js para compilar los
módulos según como lo
configures
➤ Te permite incluir en los
scripts: texto (cualquier
formato), imágenes, json, css,
entre otros)
➤ Te permite usar ES6, Less,
entre otros
$ npm install --save requirejs
$ # creas tu build.js
$ node r.js -o build.js

42. <script src="require.js" data-main="main.js"></script>
Full AMD
Bundling
/* build.js */
{
"appDir": "app/js/",
"mainConfigFile": "app/js/app.js",
"dir": "dist/",
"modules": [
{
"name": "app"
}
]
}
/* app.js */
requirejs.config({
baseUrl: 'lib',
paths: {
// shortcuts
}
});
$ node r.js -o build.js

43. BROWSERIFY
➤ Usa CommonJS (w0t??)
$ npm install -g browserify
$ browserify main.js > bundle.js

44. COMMONJS
➤ Por defecto disponible en
Node.js
➤ No funciona en los
navegadores
➤ Ampliamente usado en
backend
➤ No es asíncrono porque los
módulos están en disco
➤ Lo usan todos los task
automators
/* main.js */
var hello =
require('./hello.js')
console.log(hello)
// > hello there
/* hello.js */
myMod = 'hello there'
module.exports = myMod
require('modName')
module.exports = module

45. BROWSERIFY
➤ Usa CommonJS (ok!)
➤ Mira las dependencias de el archivo y
carga recursivamente las
dependencias en orden
➤ Al final todo queda en un solo archivo
➤ Este archivo puede ser usado en el
navegador
➤ Puedes usar módulos de NPM en el
navegador 💪
➤ Puede incluir en los bundle imágenes,
texto, json, css, etc., con plugins
➤ Puedes precopilar todo con plugins
➤ No require un archivo de config.
$ npm install -g browserify
$ browserify main.js > bundle.js

46. WEBPACK
➤ Soporta AMD y CommonJS (y
ES2015 modules (w0t??)
$ npm install -g web pack
$ browserify main.js > bundle.js

47. ES2015
➤ Nuevo estándar para
JavaScript
➤ No funciona en los
navegadores y servidores por
defecto
➤ No es asíncrono
➤ Es más sencillo
/* main.js */
import hello from './hello'
console.log(hello)
// > hello there
/* hello.js */
export default 'hello there'
import mod from 'mod'
export default myMod

48. WEBPACK
➤ Soporta AMD y CommonJS (y ES2015
modules (w0t??)
➤ Mira las dependencias de el archivo y
carga recursivamente las dependencias en
orden
➤ Al final todo puede quedar en un solo
archivo, o en miltiples con carga asíncrona
➤ Puedes usar módulos de NPM en el
navegador 💪
➤ Puede incluir en los bundle imágenes,
texto, json, css, etc.
➤ Cuenta con una infinidad de loaders para
preprocesar e incluir recursos.
➤ Provee un server para desarrollo (hot
loading)
➤ Puedes no usar configuración
$ npm install -g web pack
$ webpack ./app.js app.bundle.js

49. /* webpack.config.js */
module.exports = {
entry: './app/js/app.js',
output: {
path: './dist/js/',
filename: 'app.bundle.js'
},
module: {
loaders: [{
test: /.jsx?$/,
exclude: /node_modules/,
loader: 'babel-loader'
}]
}
};
$ npm install --save-dev
babel-core
babel-preset-es2015
babel-loader
$ webpack
/* babel.rc */
{ "presets": [ "es2015" ] }

50. https://webpack.github.io/docs/comparison.html

51. SCAFFOLDING
inicialización de proyectos

52. SIN HERRAMIENTA
A. Creas la estructura de todo el
proyecto (css, js, dist)
B. Instalas las dependencias
básicas que vas a usar
C. Configuras tus tareas y tu
bundler
D. Pruebas que todo esté bien
E. Agregas cualquier cosa que se
te haya pasado por alto, como
pruebas

53. CONS
A. TIEMPO

54. CON HERRAMIENTA
A. Corres un comando y ya
puedes comenzar a configurar
tu proyecto

55. CON HERRAMIENTA
A. Corres un comando y ya puedes comenzar a configurar tu
proyecto

56. YEOMAN & SLUSH
➤ Hacen prácticamente lo
mismo
➤ Yeoman es más grande y tiene
muchos generadores ya
preparados
➤ Puedes crear el tuyo
➤ Slush era la alternativa con
gulp
➤ Yeoman funciona con gulp o
grunt
$ npm install -g yo
$ npm install -g generator-webapp
$ yo webapp

58. Gracias
@davsket