Para el código del lado del cliente , está haciendo lo correcto. babelify y enviarlo al cliente.

Para el código del lado del servidor , solo haría una compilación regular usando babel-cli

De acuerdo con http://babeljs.io/docs/setup/#babel_register , babel-register no está diseñado para uso en producción : el enlace require se recomienda principalmente para casos simples.

para Babel 6+

A partir de Babel 6, no se incluyen transformaciones por defecto. Entonces, comencemos instalando babel-cli y babel-preset-es2015 .

 $ npm install --save-dev babel-cli babel-preset-es2015

Agregue una transformación a su archivo .babelrc : este es el módulo prest que descargamos anteriormente. Eche un vistazo a la lista completa de ajustes preestablecidos para ver cuál o cuáles son los más adecuados para usted.

 { "presets": ["es2015"] }

Agregue un script de build a su package.json . Debajo de src están sus archivos de entrada y build son los archivos de salida transformados

 "scripts": { "build": "babel src -d build" }

¡Entonces constrúyelo!

 $ npm run build

Luego ejecuta tu código. En este punto, querrá ejecutar los archivos en su directorio de build

 $ npm start

para Babel <= 5, solo use el enlace require.

 require("babel/register");

Babel transformará todos los archivos posteriores requeridos por el nodo con las extensiones .es6 , .es , .jsx y .js . El polyfill también se requiere automáticamente.

Podrá mantener sus archivos fuente en ES6 pero aún así ejecutarlos usando node server.js

Según tus comentarios, parece que tienes un pequeño problema. Preste especial atención a la parte resaltada en amarillo arriba. Su primer archivo solo puede ser ES5, que lo ejecuta el propio nodo. Todas las necesidades posteriores serán transformadas por Babel...

Así es como se vería una configuración típica

servidor.js

 // only ES5 is allowed in this file require("babel/register"); // other babel configuration, if necessary // load your app var app = require("./app.js");

aplicación.js

 // this file will be loaded through babel // you can now use ES6 here and in every other include

¡préndelo!

 $ node server.js

Acabo de escribir una entrada de blog sobre este tema .

La documentación de Babeljs CLI advierte lo siguiente:

babel-node no está diseñado para uso en producción

No debería usar babel-node en producción. Es innecesariamente pesado, con un alto uso de memoria debido a que el caché se almacena en la memoria. También experimentará siempre una penalización en el rendimiento de inicio, ya que toda la aplicación debe compilarse sobre la marcha.

Este es un ejemplo de cómo puede configurar los scripts npm para ejecutar su aplicación con nodo en lugar de babel-node.

 "scripts": { "clean": "rm -rf build && mkdir build", "build-css": "node-sass scss/app.scss public/css/app.css", "build-server": "babel -d ./build ./server -s", "build": "npm run clean && npm run build-css && npm run build-server", "lint": "eslint source/ --quiet", "start": "node ./build/index.js", "debug": "node --debug ./build/index.js", "test": "for i in $(ls tests/); do babel-node \"./tests/${i}\" | faucet ; done", "validate": "npm run lint; npm run test && npm outdated --depth 0" },

Puedes encontrar más detalles en la publicación del blog .

Es importante sopesar los pros y los contras de usar babel-node en producción.

• babel-node agrega entre medio segundo y un segundo al costo de inicio, en hardware básico. Pero si su aplicación es un servidor de ejecución prolongada, ese costo inicial no importará mucho.
• Intente medir el consumo de memoria adicional. Para mi aplicación, por ejemplo (lectura y procesamiento de datos de series temporales), solo ocupaba 20 MB. Dependiendo de su situación, esto puede o no ser significativo.

Por otro lado,

• el uso de babel-node simplifica directamente el desarrollo: no necesitará scripts de "compilación" y no tendrá directorios src / lib y dist separados
• si import desde archivos locales, ¿importará desde src/myutils o desde lib/myutils ? Usar babel-node elimina ese problema.

Solo uso Babel para soporte de módulos. Ahora V8 acaba de lanzar soporte para módulos el 10 de enero de 2017. Con suerte, veremos soporte de módulos en Node bajo una bandera en unos meses, lo que hace que mi razón para usar Babel sea discutible.