Cómo aprovechar las máquinas: ser productivo con los ejecutores de tareas

 

 

 

  • Patrones de diseño de interfaces inteligentes, vídeo de 10h + formación UX
  • Clase magistral de diseño para una interfaz de usuario compleja, con Vitaly Friedman

  • Índice
    1. Una nota sobre la línea de comando
  • Gruñido
    1. Un ejemplo
  • Gulp: bloques LEGO para su sistema de construcción
    1. Un ejemplo
  • paquete web
    1. Un ejemplo
    2. Extensión
  • scripts npm
    1. Un ejemplo
  • Desglose de los ejecutores de tareas cubiertos aquí
  • Algunas victorias fáciles
    1. ¡Guiones envolventes!
    2. Espolvoree en un pequeño paquete web
    3. Utilice PostCSS fácilmente con scripts npm
  • Conclusión
    1. Otras lecturas
  • En este artículo, Adam Simpson cubrirá los scripts Grunt, Gulp, Webpack y npm, proporcionando algunos ejemplos de cada uno para que pueda iniciarse en los ejecutores de tareas. Los corredores de tareas pueden resolver problemas reales. Adam los ha utilizado para compilar diferentes compilaciones de una aplicación JavaScript, dependiendo de si el objetivo era producción o desarrollo local, o para compilar plantillas de manillar. Los ejecutores de tareas evolucionan y cambian constantemente, y en este artículo Adam intentará cubrir los más utilizados en el espíritu de la época actual. ¡Feliz tarea en marcha!

     

    Los corredores de tareas son los héroes (o villanos, según su punto de vista) que trabajan silenciosamente detrás de la mayoría de las aplicaciones web y móviles. Los ejecutores de tareas aportan valor a través de la automatización de numerosas tareas de desarrollo, como concatenar archivos, activar servidores de desarrollo y compilar código. En este artículo, cubriremos los scripts Grunt, Gulp, Webpack y npm. También le proporcionaremos algunos ejemplos de cada uno para que pueda comenzar. Cerca del final, mencionaré algunas ventajas sencillas y consejos para integrar ideas de esta publicación en su aplicación.

    Existe la sensación de que los ejecutores de tareas y los avances de JavaScript en general están complicando demasiado el panorama del front-end. Estoy de acuerdo en que pasar todo el día modificando scripts de compilación no siempre es el mejor uso de su tiempo, pero los ejecutores de tareas tienen algunos beneficios cuando se usan correctamente y con moderación. Ese es nuestro objetivo en este artículo, cubrir rápidamente los conceptos básicos de los ejecutores de tareas más populares y proporcionar ejemplos sólidos para impulsar su imaginación sobre cómo estas herramientas pueden encajar en su flujo de trabajo.

    Una nota sobre la línea de comando

    Los ejecutores de tareas y las herramientas de compilación son principalmente herramientas de línea de comandos. A lo largo de este artículo, asumiré un nivel decente de experiencia y competencia para trabajar con la línea de comandos. Si comprende cómo utilizar comandos comunes como cd, y , entonces debería estar bien a medida lsque avanzamos en los distintos ejemplos. Si no se siente cómodo usando estos comandos, hay una excelente publicación introductoria disponible en Smashing Magazine. Comencemos con el abuelo de todos ellos: Grunt.cpmv

    Gruñido

    Grunt fue el primer ejecutor de tareas popular basado en JavaScript. He estado usando Grunt de alguna forma desde 2012. La idea básica detrás de Grunt es que usas un archivo JavaScript especial, Gruntfile.jspara configurar varios complementos para realizar tareas. Tiene un vasto ecosistema de complementos y es una herramienta muy madura y estable. Grunt tiene un directorio web fantástico que indexa la mayoría de los complementos (alrededor de 5500 actualmente). La simple genialidad de Grunt es su combinación de JavaScript y la idea de un archivo de configuración común (como un archivo MAKE), lo que ha permitido a muchos más desarrolladores contribuir y utilizar Grunt en sus proyectos. También significa que Grunt se puede colocar bajo el mismo sistema de control de versiones que el resto del proyecto.

     

    Grunt está probado en batalla y es estable. En el momento de escribir este artículo, se lanzó la versión 1.0.0 , lo cual es un gran logro para el equipo de Grunt. Debido a que Grunt configura en gran medida varios complementos para que funcionen juntos, puede enredarse (es decir, ser desordenado y confuso de modificar) con bastante rapidez. Sin embargo, con un poco de cuidado y organización (¡dividiendo las tareas en archivos lógicos!), puedes conseguir que haga maravillas en cualquier proyecto.

    En el raro caso de que no haya un complemento disponible para realizar la tarea que necesita, Grunt proporciona documentación sobre cómo escribir su propio complemento . Todo lo que necesitas saber para crear tu propio complemento es JavaScript y la API de Grunt . Casi nunca tendrás que crear tu propio complemento, ¡así que veamos cómo usar Grunt con un complemento bastante popular y útil!

    Un ejemplo

    Veamos cómo funciona realmente Grunt. La ejecución grunten la línea de comando activará el programa de línea de comando Grunt que busca Gruntfile.jsen la raíz del directorio. Contiene Gruntfile.jsla configuración que controla lo que hará Grunt. En este sentido, Gruntfile.jspuede verse como una especie de libro de cocina que sigue el cocinero (es decir, Grunt, el programa); y, como todo buen libro de cocina, Gruntfile.jscontendrá muchas recetas (es decir, tareas).

    Vamos a poner a prueba a Grunt usando el complemento Grunticon para generar íconos para una aplicación web hipotética. Grunticon toma un directorio de SVG y muestra varios activos:

    • un archivo CSS con los SVG codificados en base 64 como imágenes de fondo;
    • un archivo CSS con versiones PNG de los SVG codificados en base 64 como imágenes de fondo;
    • un archivo CSS que hace referencia a un archivo PNG individual para cada icono.

    Los tres archivos diferentes representan las diversas capacidades de los navegadores y dispositivos móviles. Los dispositivos modernos recibirán los SVG de alta resolución como una única solicitud (es decir, un único archivo CSS). Los navegadores que no manejan SVG pero sí recursos codificados en base 64 obtendrán la hoja de estilo PNG en base 64. Finalmente, cualquier navegador que no pueda manejar esos dos escenarios obtendrá la hoja de estilo "tradicional" que hace referencia a los PNG. ¡Todo esto desde un único directorio de SVG!

    La configuración de esta tarea se ve así:

    module.exports = function(grunt) { grunt.config("grunticon", { icons: { files: [ { expand: true, cwd: 'grunticon/source', src: ["*.svg", ".png"], dest: 'dist/grunticon' } ], options: [ { colors: { "blue": "blue" } } ] } }); grunt.loadNpmTasks('grunt-grunticon');};

    Repasemos los distintos pasos aquí:

    1. Debes tener Grunt instalado globalmente .
    2. Cree el Gruntfile.jsarchivo en la raíz del proyecto. Es mejor instalar también Grunt como una dependencia npm en su package.jsonarchivo junto con Grunticon a través de npm i grunt grunt-grunticon --save-dev.
    3. Cree un directorio de SVG y un directorio de destino (donde irán los recursos creados).
    4. Coloque un pequeño script enhead su HTML, que determinará qué íconos cargar.

    Así es como debería verse su directorio antes de ejecutar la tarea Grunticon:

     

    |-- Gruntfile.js|-- grunticon| `-- source| `-- logo.svg`-- package.json

    Una vez que esas cosas estén instaladas y creadas, puede copiar el fragmento de código anterior en Gruntfile.js. Luego debería poder ejecutar grunt grunticondesde la línea de comando y ver cómo se ejecuta su tarea.

    El fragmento anterior hace algunas cosas:

    • agrega un nuevo configobjeto a Grunt en la línea 32 llamado grunticon;
    • completa las diversas opciones y parámetros para Grunticon en el iconsobjeto;
    • finalmente, incorpora el complemento Grunticon a través de loadNPMTasks.

    Así es como debería verse su directorio después de Grunticon:

    |-- Gruntfile.js|-- dist| `-- grunticon| |-- grunticon.loader.js| |-- icons.data.png.css| |-- icons.data.svg.css| |-- icons.fallback.css| |-- png| | `-- logo.png| `-- preview.html|-- grunticon| `-- source| `-- logo.svg`-- package.json

    Ahí lo tienes, ¡terminado! ¡En unas pocas líneas de configuración y un par de instalaciones de paquetes, hemos automatizado la generación de nuestros activos de íconos! Con suerte, esto comienza a ilustrar el poder de los ejecutores de tareas: confiabilidad, eficiencia y portabilidad.

    Gulp: bloques LEGO para su sistema de construcción

    Gulp surgió en algún momento después de Grunt y aspiraba a ser una herramienta de compilación que no fuera solo configuración sino código real. La idea detrás del código sobre la configuración es que el código es mucho más expresivo y flexible que la modificación de interminables archivos de configuración. El obstáculo de Gulp es que requiere más conocimientos técnicos que Grunt. Deberá estar familiarizado con la API de transmisión de Node.js y sentirse cómodo escribiendo JavaScript básico.

    El uso que hace Gulp de los flujos de Node.js es la razón principal por la que es más rápido que Grunt. Usar transmisiones significa que, en lugar de usar el sistema de archivos como "base de datos" para las transformaciones de archivos, Gulp usa transformaciones en memoria. Para obtener más información sobre las transmisiones, consulte la documentación de la API de transmisiones de Node.js , junto con el manual de transmisiones.

    Un ejemplo

    Al igual que en la sección Grunt, vamos a poner a prueba a Gulp con un ejemplo sencillo: concatenar nuestros módulos JavaScript en un único archivo de aplicación.

    Ejecutar Gulp es lo mismo que ejecutar Grunt. El gulpprograma de línea de comandos buscará el libro de recetas (es decir, Gulpfile.js) en el directorio en el que se ejecuta.

    Limitar la cantidad de solicitudes que realiza cada página se considera una de las mejores prácticas de rendimiento web (especialmente en dispositivos móviles). Sin embargo, colaborar con otros desarrolladores es mucho más fácil si la funcionalidad se divide en varios archivos. Introduzca los corredores de tareas. Podemos usar Gulp para combinar varios archivos de JavaScript para nuestra aplicación, de modo que los clientes móviles tengan que cargar un solo archivo, en lugar de muchos.

     

    Gulp tiene el mismo ecosistema masivo de complementos que Grunt. Entonces, para facilitar esta tarea, nos apoyaremos en el complemento gulp-concat . Digamos que la estructura de nuestro proyecto se ve así:

    |-- dist| `-- app.js|-- gulpfile.js|-- package.json`-- src |-- bar.js `-- foo.js

    Hay dos archivos JavaScript en nuestro srcdirectorio y queremos combinarlos en un solo archivo, app.jsen nuestro dist/directorio. Podemos utilizar la siguiente tarea Gulp para lograr esto.

    var gulp = require('gulp');var concat = require('gulp-concat');gulp.task('default', function() { return gulp.src('./src/*.js') .pipe(concat('app.js')) .pipe(gulp.dest('./dist/'));});

    Los bits importantes están en la gulp.taskdevolución de llamada. Allí, usamos la gulp.srcAPI para obtener todos los archivos que terminan .jsen nuestro srcdirectorio. La gulp.srcAPI devuelve un flujo de esos archivos, que luego podemos pasar (a través de la pipeAPI ) al complemento gulp-concat. Luego, el complemento concatena todos los archivos en la secuencia y los pasa a la gulp.destfunción. La gulp-destfunción simplemente escribe la entrada que recibe en el disco.

    Puedes ver cómo Gulp usa transmisiones para darnos "bloques de construcción" o "cadenas" para nuestras tareas. Un flujo de trabajo típico de Gulp se ve así:

    1. Obtenga todos los archivos de un determinado tipo.
    2. Pase esos archivos a un complemento (¡concat!) o realice alguna transformación.
    3. Pasar esos archivos transformados a otro bloque (en nuestro caso, el destbloque que finaliza nuestra cadena).

    Como en el ejemplo de Grunt, simplemente ejecutar gulpdesde la raíz del directorio de nuestro proyecto activará la defaulttarea definida en el Gulpfile.jsarchivo. Esta tarea concatena nuestros archivos y nos permite continuar con el desarrollo de nuestra aplicación o sitio web. Películas en excelente calidad Full HD

    paquete web

    La última incorporación al club de ejecución de tareas de JavaScript es Webpack . Webpack se anuncia a sí mismo como un "paquete de módulos", lo que significa que puede crear dinámicamente un paquete de código JavaScript a partir de múltiples archivos separados utilizando patrones de módulos como el patrón CommonJS. Webpack también tiene complementos, a los que llama cargadores.

    Webpack es todavía bastante joven y tiene una documentación bastante densa y confusa. Por lo tanto, recomendaría el repositorio Webpack de Pete Hunt como un excelente punto de partida antes de profundizar en la documentación oficial. Tampoco recomendaría Webpack si eres nuevo en los ejecutores de tareas o no te sientes competente en JavaScript. Dejando de lado esos problemas, sigue siendo una herramienta más específica que la amplitud general de Grunt y Gulp. Mucha gente usa Webpack junto con Grunt o Gulp por esta misma razón, permitiendo que Webpack sobresalga al agrupar módulos y permitiendo que Grunt o Gulp manejen tareas más genéricas.

    En última instancia, Webpack nos permite escribir código estilo Node.js para el navegador, una gran ventaja para la productividad y para hacer una separación clara de las preocupaciones en nuestro código a través de módulos. Usemos Webpack para lograr el mismo resultado que obtuvimos con el ejemplo de Gulp, combinando varios archivos JavaScript en un archivo de aplicación.

     

    Un ejemplo

    Webpack se usa a menudo con Babel para transpilar código ES6 a ES5. La transpilación de código de ES6 a ES5 permite a los desarrolladores utilizar el estándar ES6 emergente mientras ofrecen ES5 a navegadores o entornos que aún no son totalmente compatibles con ES6. Sin embargo, en este ejemplo, nos centraremos en crear un paquete simple de nuestros dos archivos del ejemplo de Gulp. Para comenzar, necesitamos instalar Webpack y crear un archivo de configuración webpack.config.js. Así es como se ve nuestro archivo:

    module.exports = { entry: "./src/foo.js", output: { filename: "app.js", path: "./dist" }};

    En este ejemplo, estamos apuntando a Webpack a nuestro src/foo.jsarchivo para comenzar su trabajo de recorrer nuestro gráfico de dependencia. También hemos actualizado nuestro foo.jsarchivo para que se vea así:

    //foo.jsvar bar = require("./bar");var foo = function() { console.log('foo'); bar();};module.exports = foo;

    Y hemos actualizado nuestro bar.jsarchivo para que se vea así:

    //bar.jsvar bar = function() { console.log('bar');};module.exports = bar;

    Este es un ejemplo de CommonJS muy básico. Notarás que estos archivos ahora "exportan" una función. Básicamente, CommonJS y Webpack nos permiten comenzar a organizar nuestro código en módulos independientes que se pueden importar y exportar a través de nuestra aplicación. Webpack es lo suficientemente inteligente como para seguir las palabras clave de importación y exportación y agrupar todo en un solo archivo dist/app.js. Ya no necesitamos mantener una tarea de concatenación y, en su lugar, simplemente debemos adherirnos a una estructura para nuestro código. ¡Mucho mejor!

    Extensión

    Webpack es similar a Gulp en el sentido de que "es solo JavaScript". Se puede ampliar para realizar otras tareas de ejecución de tareas a través de su sistema de carga. Por ejemplo, puedes usar css-loader y sass-loader para compilar Sass en CSS e incluso usar Sass en tu JavaScript sobrecargando el requirepatrón CommonJS . Sin embargo, normalmente recomiendo usar Webpack únicamente para crear módulos JavaScript y usar otro enfoque de propósito más general para la ejecución de tareas (por ejemplo, Webpack y scripts npm o Webpack y Gulp para manejar todo lo demás).

    scripts npm

    Los scripts npm son la última moda hipster, y por una buena razón. Como hemos visto con todas estas herramientas, la cantidad de dependencias que podrían introducir en un proyecto podría eventualmente salirse de control. La primera publicación que vi defendiendo los scripts npm como punto de entrada para un proceso de construcción fue la de James Halliday. Su publicación resume perfectamente el poder ignorado de los scripts npm (el énfasis es mío):

    "Hay algunas herramientas sofisticadas para automatizar la compilación en proyectos de JavaScript que nunca he sentido atractivo porque el npm runcomando menos conocido ha sido perfectamente adecuado para todo lo que necesitaba hacer manteniendo una huella de configuración muy pequeña" .

     

    ¿Captaste eso último al final? El principal atractivo de los scripts npm es que tienen una "huella de configuración muy pequeña". Esta es una de las razones principales por las que los scripts npm han comenzado a tener éxito (lamentablemente, casi cuatro años después). Con Grunt, Gulp e incluso Webpack, eventualmente uno comienza a ahogarse en complementos que envuelven archivos binarios y duplican el número de dependencias en un proyecto.

    Keith Cirkel tiene el tutorial sobre cómo usar npm para reemplazar Grunt o Gulp. Proporciona el modelo sobre cómo aprovechar al máximo el poder de los scripts npm y ha introducido un complemento esencial, Parallel Shell (y muchos otros similares).

    Un ejemplo

    En nuestra sección sobre Grunt, tomamos el popular módulo Grunticon y creamos íconos SVG (con alternativas PNG) en una tarea de Grunt. Este solía ser el único problema con los scripts npm para mí. Por un tiempo, mantendría Grunt instalado en proyectos solo para usar Grunticon. Literalmente le “pagaría” a Grunt en mi tarea npm para lograr el inicio del ejecutor de tareas (o, como comenzamos a llamarlo en el trabajo, un turducken de herramienta de compilación). Afortunadamente, The Filament Group , el fantástico grupo detrás de Grunticon, lanzó una versión independiente (es decir, sin Grunt) de su herramienta, Grunticon-Lib . Entonces, ¡usémoslo para crear algunos íconos con scripts npm!

    Este ejemplo es un poco más avanzado que una tarea típica de script npm. Una tarea típica de script npm es una llamada a una herramienta de línea de comandos, con los indicadores o el archivo de configuración apropiados. Aquí hay una tarea más típica que compila nuestro Sass a CSS:

    "sass": "node-sass src/scss/ -o dist/css",

    ¿Ves cómo es solo una línea con varias opciones? No se necesita ningún archivo de tarea, ni ninguna herramienta de compilación para activar, solo npm run sassdesde la línea de comandos, y ahora eres Sass es CSS. Una característica realmente interesante de los scripts npm es cómo puedes encadenar tareas de script. Por ejemplo, digamos que queremos ejecutar alguna tarea antes de que se ejecute nuestra tarea Sass. Crearíamos una nueva entrada de script como esta:

    "presass": "echo 'before sass',

    Así es: npm comprende el pre-prefijo. También entiende el post-prefijo. Cualquier entrada de script con el mismo nombre que otra entrada de script con el prefijo pre-o post-se ejecutará antes o después de esa entrada.

    Convertir nuestros íconos requerirá un archivo Node.js real. Aunque no es demasiado grave. Simplemente cree un tasksdirectorio y cree un nuevo archivo llamado grunticon.jso icons.jso lo que tenga sentido para quienes trabajan en el proyecto. Una vez creado el archivo, podemos escribir algo de JavaScript para iniciar nuestro proceso Grunticon.

    Nota: Todos estos ejemplos usan ES6, por lo que usaremos babel-node para ejecutar nuestra tarea. Puede utilizar fácilmente ES5 y Node.js, si le resulta más cómodo.

     

    import icons from "grunticon-lib";import globby from "globby";let files = globby.sync('src/icons/*');let options = { colors: { "blue": "blue" }};let icon = new icons(files, 'dist/icons', options);icon.process();

    Entremos en el código y descubramos qué está pasando.

    1. Nosotros import(es decir, requerimos) dos bibliotecas grunticon-liby globby. Globby es una de mis herramientas favoritas y hace que trabajar con archivos y globos sea muy fácil. Globby mejora Node.js Glob (seleccione todos los archivos JavaScript mediante ./*.js) con compatibilidad con Promise. En este caso, lo usamos para obtener todos los archivos del src/iconsdirectorio.
    2. Una vez que hacemos eso, configuramos algunas opciones en un optionsobjeto y luego llamamos a Grunticon-Lib con tres argumentos:
      • los archivos de iconos,
      • el destino,
      • las opciones. La biblioteca se hace cargo y mastica esos íconos y eventualmente crea las versiones SVG y PNG en el directorio que queremos.
    3. Ya casi hemos terminado. Recuerde que esto está en un archivo separado y necesitamos agregar un "gancho" para llamar a este archivo desde nuestro script npm, como este: "icons": "babel-node tasks/icons.js".
    4. Ahora podemos ejecutar npm run iconsy nuestros íconos se crearán cada vez.

    Los scripts npm ofrecen un nivel similar de potencia y flexibilidad que otros ejecutores de tareas, sin necesidad de complementos.

    Desglose de los ejecutores de tareas cubiertos aquí

    Herramienta Ventajas Contras
    Gruñido No se necesitan conocimientos reales de programación Los ejecutores de tareas más detallados que se tratan aquí
    Trago Configurar tareas con JavaScript y transmisiones reales Requiere conocimiento de JavaScript
    Agrega código a un proyecto (potencialmente más errores)
    paquete web El mejor de su clase en agrupación de módulos Más difícil para tareas más genéricas (por ejemplo, Sass a CSS)
    secuencias de comandos npm Interacción directa con herramientas de línea de comandos. Algunas tareas no son posibles sin un ejecutor de tareas.

    Algunas victorias fáciles

    Todos estos ejemplos y ejecutores de tareas pueden parecer abrumadores, así que analicémoslos. Primero, espero que no quites de este artículo que cualquier ejecutor de tareas o sistema de compilación que estés usando actualmente debe ser reemplazado instantáneamente por uno mencionado aquí. Reemplazar sistemas importantes como este no debe hacerse sin mucha consideración. Este es mi consejo para actualizar un sistema existente: hágalo de forma incremental.

    ¡Guiones envolventes!

    Un enfoque incremental es considerar escribir algunos scripts npm “envoltorios” alrededor de sus ejecutores de tareas existentes para proporcionar un vocabulario común para los pasos de compilación que esté fuera del ejecutor de tareas real utilizado. Un script contenedor podría ser tan simple como este:

     

    { "scripts": { "start": "gulp" }}

    Muchos proyectos utilizan los bloques de script starty testnpm para ayudar a los nuevos desarrolladores a aclimatarse rápidamente. Un script contenedor introduce otra capa de abstracción en la cadena de compilación de su ejecutor de tareas, pero creo que vale la pena poder estandarizar las primitivas npm (p. ej. test). Los comandos npm tienen mayor longevidad que una herramienta individual.

    Espolvoree en un pequeño paquete web

    Si usted o su equipo sienten la molestia de mantener un frágil "orden de paquetes" para su JavaScript, o están buscando actualizar a ES6, considere esta una oportunidad para introducir Webpack en su sistema de ejecución de tareas existente. Webpack es excelente porque puedes usar tanto o tan poco como quieras y aún así obtener valor de él. Comience simplemente haciendo que incluya el código de su aplicación y luego agregue babel-loader a la mezcla. Webpack tiene tal profundidad de características que podrá acomodar casi cualquier adición o característica nueva durante bastante tiempo.

    Utilice PostCSS fácilmente con scripts npm

    PostCSS es una gran colección de complementos que transforman y mejoran CSS una vez escrito y preprocesado. En otras palabras, es un postprocesador. Es bastante fácil aprovechar PostCSS usando scripts npm. Digamos que tenemos un script Sass como en nuestro ejemplo anterior:

    "sass": "node-sass src/scss/ -o dist/css",

    Podemos usar lifecyclelas palabras clave del script npm para agregar un script que se ejecute automáticamente después de la tarea Sass:

    "postsass": "postcss --use autoprefixer -c postcss.config.json dist/css/*.css -d dist/css",

    Este script se ejecutará cada vez que se ejecute el script Sass. El paquete postcss-cli es excelente porque puede especificar la configuración en un archivo separado. Observe que en este ejemplo agregamos otra entrada de script para realizar una nueva tarea; Este es un patrón común cuando se utilizan scripts npm. Puede crear un flujo de trabajo que realice todas las diversas tareas que necesita su aplicación.

    Conclusión

    Los corredores de tareas pueden resolver problemas reales. He utilizado ejecutores de tareas para compilar diferentes compilaciones de una aplicación JavaScript, dependiendo de si el objetivo era producción o desarrollo local. También he utilizado ejecutores de tareas para compilar plantillas de manillar , implementar un sitio web en producción y agregar automáticamente prefijos de proveedores que faltan en mi Sass. Estas no son tareas triviales, pero una vez que están envueltas en un corredor de tareas, se vuelven sin esfuerzo.

    Los corredores de tareas están en constante evolución y cambio. He tratado de cubrir los más utilizados en el espíritu de la época actual. Sin embargo, hay otros que ni siquiera he mencionado, como Broccoli , Brunch y Harp . Recuerde que estas son sólo herramientas: úselas sólo si resuelven un problema en particular, no porque todos los demás las estén usando. ¡Feliz tarea en marcha!

    Otras lecturas

    • Conviértase en un usuario avanzado de línea de comandos con Oh-My-ZSH y Z
    • Una introducción a PostCSS
    • Ponte en marcha con Grunt
    • Construyendo con trago
    • Hoja de referencia sobre tamaños de objetivos accesibles

    (da, ml, al, il, mrn)Explora más en

    • Móvil
    • javascript
    • Nodo.js





    Tal vez te puede interesar:

    1. ¿Deberían abrirse los enlaces en ventanas nuevas?
    2. 24 excelentes tutoriales de AJAX
    3. 70 técnicas nuevas y útiles de AJAX y JavaScript
    4. Más de 45 excelentes recursos y repositorios de fragmentos de código

    Cómo aprovechar las máquinas: ser productivo con los ejecutores de tareas

    Cómo aprovechar las máquinas: ser productivo con los ejecutores de tareas

    Patrones de diseño de interfaces inteligentes, vídeo de 10h + formación UX Clase magistral de diseño para una interfaz de usuario compleja, con Vitaly Fri

    programar

    es

    https://aprendeprogramando.es/static/images/programar-como-aprovechar-las-maquinas-ser-productivo-con-los-ejecutores-de-tareas-895-0.jpg

    2024-05-20

     

    Cómo aprovechar las máquinas: ser productivo con los ejecutores de tareas
    Cómo aprovechar las máquinas: ser productivo con los ejecutores de tareas

    Si crees que alguno de los contenidos (texto, imagenes o multimedia) en esta página infringe tus derechos relativos a propiedad intelectual, marcas registradas o cualquier otro de tus derechos, por favor ponte en contacto con nosotros en el mail [email protected] y retiraremos este contenido inmediatamente

     

     

    Top 20