¿Los generadores de código de Yeoman se usan comúnmente en sitios web de producción? La tecnología cambia la vida futura

Utilizamos generadores Yeoman en https://qkast.com

Es una conveniencia en cuanto a empacar cosas en un ciclo de ejecución repetible. Hay una comparación adecuada entre el brunch, que es una mejor opción.

Por defecto, yeoman no concatena archivos a uno / dos / lo que sea que establezca. Si bien esto es mejor para la depuración, es mejor solo hasta que se envíe el soporte de mapas fuente (más adelante este año, uglifyjs v2, coffeescript v2). Como resultado, yeoman requiere la adición manual de los nuevos scripts a index.html cada vez . Muy molesto para mí. Brunch tiene pedidos automáticos y, por lo general, todo lo que necesita es agregar un archivo al vendor/ directorio (s). Además, ¿hay alguna forma en Yeoman de hacer que se compile file.js antes de file.js y después de file.js ? No encontré la funcionalidad. Brunch simplemente no se preocupa por el lenguaje que usa, puede establecer el orden de concatenación como desee, si la compilación es compatible.
Los andamios son mucho más complicados. Si bien los generadores son más potentes, no es algo que quiera crear a menudo. No puede cambiar las rutas de archivo generadas ( brunch g --path ). Como contraste, en Brunch, puede hacer un generador simplemente ejecutando brunch g generator stuff o simplemente agregando un archivo json simple y apuntando a qué archivos copiar. Incluso puede llamar a otros generadores, como yeoman. Y lo más importante, los generadores de brunch son locales para su aplicación, porque cada aplicación necesita un andamiaje ligeramente diferente que sea fácil de cambiar.
Los generadores en Yeoman también parecen tener funcionalidad de esqueletos de brunch. No creo que sea una buena idea, porque usas esqueletos solo una vez, al comienzo del proyecto.
Archivos de configuración feos y extremadamente detallados ( archivos grunt). Comparar: configuración de brunch y configuración de yeoman
Las bibliotecas (no todas) que se envían con aplicaciones predeterminadas se minimizan . Esta es una mala decisión porque afecta mucho a la depuración y en entornos de producción, ya estás minimizando cosas.
La aplicación predeterminada es bastante pequeña, a diferencia del brunch con esqueleto chaplin. La razón por la que el brunch con chaplin es predeterminado es que permite construir aplicaciones web de cualquier tamaño de manera simple (simple! = Fácil, recuerde), pero necesita saber backbone + chaplin. Lo que no parece ser una tarea difícil, teniendo en cuenta que hay excelentes aplicaciones de ejemplo (http://ost.io, tuitea tu brunch) y que mi equipo aprendió el brunch con chaplin + coffeescript + manillar + menos stack después de solo la experiencia de Django / Python en algo así como dos días
La velocidad también parece ser más lenta, mi flujo de trabajo habitual es: cambiar un archivo, instantáneamente alt-tab al navegador (brunch instantáneamente [<500ms usualmente] compila cosas), jugar con el inspector web. No puedo hacer esto con yeoman porque, por ejemplo, los archivos de brújula se compilan muy lentamente.
En cuanto a los esqueletos , yeoman tiene yeoman init ember simple en lugar de brunch n -s . No es mala idea. Por supuesto, esto combina algunos esqueletos con yeoman (es necesario mantener una cáscara de yeoman angular, una cáscara de ember yeoman) que es algo que no puedo hacer porque no uso estos marcos (los mejores productos están hechos por personas que los usan).
Parece que no hay compatibilidad de módulos personalizados / CommonJS , solo AMD.
Sin notificaciones (Centro de notificaciones OS X 10.8, Growl, libnotify).

Yeoman y Brunch · Edición # 408 · brunch / brunch

DesarrolloLenguajes de programaciónProgramación informáticaSitios webSitios web de programación informáticaweb