Uso De Módulos ES En Node.js

“Antes de que el software pueda ser reutilizable, primero tiene que ser utilizable”. –Ralph Johnson

Los módulos son bloques de construcción independientes de un programa de software. Son básicamente un patrón de diseño que implementa características de diseño modular en lenguajes de programación. El sistema de módulos es compatible con muchos idiomas y es bastante popular, ya que la forma en que se manejan, empaquetan y administran las dependencias determina qué tan fácil es trabajar con un código fuente grande y en crecimiento.

En el diseño modular, la lógica comercial relacionada con características o funcionalidades particulares se empaqueta (modulariza) en un formato estandarizado para reutilización, flexibilidad y en aras de reducir la complejidad. Esta configuración ofrece un sistema débilmente acoplado debido a una interfaz de comunicación fluida, ya que no hay variables globales ni estado compartido.

Aunque el concepto de módulos es bastante diferente según el lenguaje , son similares a la idea de espacios de nombres en lenguajes como Java. Los módulos permiten la organización del código al dividir una base de código en componentes reutilizables, de modo que cada uno realice funciones individuales y se puedan combinar o componer para formar funcionalidades más grandes o una aplicación completa.

En Node.js, el sistema de módulos ha recorrido un largo camino desde su adopción anterior de CommonJS . Hoy en día, los módulos ECMAScript (módulos ES), que ahora son estables y aptos para uso en producción, son el estándar oficial para empaquetar código para su reutilización tanto en JavaScript del lado del cliente como del lado del servidor.

Tabla de contenido

En este artículo, aprenderemos sobre los módulos ES en Node. Sin embargo, exploraremos brevemente otras formas de manejar y organizar el código del lado del servidor con CommonJS.

¿Por qué? Para que tengamos un punto de referencia para reconocer los beneficios de los módulos ES. En esencia, aprenderemos sobre los desafíos que intenta resolver y que los sistemas de módulos anteriores no estaban adaptados para resolver.

Estaremos mirando:

• Una introducción a los módulos ES : aquí, presentamos los módulos ES de una manera emocionante
• Una breve historia de los módulos ES : aquí aprendemos sobre la transición del sistema de módulos anterior a los módulos ES. También examinaremos brevemente qué tan interoperables son estos sistemas de módulos entre sí.
• Adición de soporte para módulos ES en Node : aquí, aprendemos cómo podemos agregar gradualmente soporte para módulos ES en Node. También aprendemos cómo migrar una base de código antigua para comenzar a usar módulos ES
• Comparación y contraste de características : aquí, aprenderemos sobre las características de estos dos sistemas de módulos y cómo se comparan
• Luego, por último, los módulos ES avanzan

requisitos previos

Para seguir fácilmente este tutorial, es recomendable tener instalada la última versión de Node.js. Las instrucciones sobre cómo hacerlo están disponibles en la documentación de Node .

Además, para un mejor contexto, es posible que los lectores deban tener bastante conocimiento del sistema de módulos CommonJS en Node. Es igualmente acogedor para los recién llegados que están aprendiendo el sistema de módulos Node.js o aplicando módulos ES en sus proyectos de Node hoy.

¿Qué son los módulos ES?

Con el lanzamiento de la versión 15.3.0 de Node (actualmente en v15.11.0), los módulos ES ahora se pueden usar sin una bandera experimental, ya que ahora son estables y compatibles con el ecosistema NPM. Los detalles sobre el índice de estabilidad se pueden encontrar aquí en la documentación de ESM de node.js. Con los módulos ES, los módulos se definen con el uso de las palabras clave importy exporten lugar de la require()función en CommonJS. Así es como se usan:

export function sayLanguage(language) {
    console.log(`I love ${language}!`);
  }

//f.js


import {sayLanguage} from './f.js';

console.log(sayLanguage('JavaScript'));

//g.js

{
  "name": "esm",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "type": "module",
  "author": "",
  "license": "ISC"
}
//package.json

Nota : los lectores deben tomar nota del campo de tipo en el archivo package.json anterior. Para poder cargar un módulo ES, debemos configurar "tipo": "módulo" en este archivo o, como alternativa, podemos usar la extensión de archivo .mjs en lugar de la extensión de archivo .js habitual. Además, desde la versión 12.7.0 y 13.2.0 de Node, la carga de módulos ECMAScript ya no requería que pasáramos ningún indicador de línea de comandos.

Alexs-MacBook-Pro:esm terra-alex.$ node g.js
I love JavaScript!
undefined
Alexs-MacBook-Pro:esm terra-alex.$

El resultado/salida terminal de ejecutar nuestro código se muestra arriba.

Agregar soporte para módulos ES en Node hoy

Este apoyo estaba antes detrás de la --experimental-modulebandera. Actualmente, esto ya no es necesario a partir de la versión 13.14.0 a 14.0.0, la implementación ahora es estable y ahora se puede usar con el sistema de módulos commonJS anterior.

Los archivos que terminan en .mjso .jsextensiones (con el package.jsonarchivo más cercano con un fieldtipo) se tratan como módulos ES, como se muestra anteriormente. Entonces, en esencia, cuando ejecutamos node g.jsen la misma carpeta que la anterior package.json, el archivo se trata como un ESM. Además, es un ESM si estamos pasando argumentos de cadena a la entrada estándar de Node.js con flag --input-type=module. Más detalles se pueden encontrar aquí .

Es importante tener en cuenta que con ESM, sin el typecampo en el package.jsonarchivo principal o las otras formas especificadas anteriormente, Node arroja el error que se muestra a continuación:

(nodo: 2844) Advertencia: para cargar un módulo ES, configure "tipo": "módulo" en el paquete.json o use la extensión .mjs. (Use `node --trace-warnings ...` para mostrar dónde está el se creó una advertencia). Además, aparte, no podemos hacer uso de declaraciones de importación fuera de los módulos.

Alcance del paquete

El alcance de un paquete, definido por el typeindicador en un package.jsonarchivo principal y todas las carpetas debajo de él, está presente en el alcance actual de ese paquete, como se explicó anteriormente. Además, los archivos que terminan con la .mjsextensión siempre se cargan como módulos ES, independientemente del alcance de ese paquete.

Del mismo modo, todas las demás formas de archivos sin extensiones y sin el typeindicador en el package.jsonarchivo principal se tratan como CommonJS. Además, los archivos que terminan con .cjsextensiones se tratan como módulos CJS independientemente del alcance del paquete.

Es importante saber que debido a que Node.js ahora admite módulos ES y módulos commonJS, los autores de paquetes siempre deben asegurarse de que el typecampo en su archivo package.json esté siempre incluido, independientemente del tipo de módulo. Esto permite la compatibilidad con versiones anteriores; por ejemplo, en una situación en la que cambia el tipo predeterminado de Node.js, Node sabría cómo manejar o interpretar archivos en nuestro programa. Más detalles aquí .

Sintaxis de importación y exportación en módulos ES

En los módulos ES, los especificadores son como rutas de archivo basadas en cadenas que se usan después de la frompalabra clave. Existen ambos algoritmos para cargar un especificador de módulo ES y para determinar el formato de módulo de una URL resuelta. A continuación se muestra un ejemplo:

import {cat} from 'animals';

El animalespecificador en este caso es un paquete npm, por ejemplo. Otras formas en que se puede hacer referencia a los especificadores incluyen desde rutas de archivo o URL absolutas y relativas, y rutas dentro de otros paquetes. En esta sección de la documentación se muestran ejemplos .

Nota : Los módulos integrados de Node.js ahora se pueden cargar o referenciar mediante cadenas de URL absolutas desde la versión 14.13.1. Al usar la palabra clave de importación, se debe proporcionar una extensión de archivo para resolver los especificadores de URL relativos o absolutos.

Aunque importlas declaraciones solo se permiten en módulos ES, pueden hacer referencia a módulos ESM o CommonJS. Por ejemplo:

import packageMain from 'commonjs-package'; // Works

import { method } from 'commonjs-package'; // Errors

Nota : las declaraciones de importación que hacen referencia a otros tipos de archivos como JSON o Wasm todavía son experimentales y requieren que se pasen los indicadores --experimental-json-modulesy --experimental-wasm-modules, respectivamente, ya que solo se admiten en commonJS. A partir de la versión 14.8.0 de Node, pudimos hacer uso de la espera de nivel superior sin pasar los indicadores de la CLI. Los detalles, incluido el uso de la palabra clave await fuera de las funciones asíncronas (también conocido como espera de nivel superior) para ESM, se pueden encontrar aquí .

Para las exportaciones en módulos ES, podemos hacer uso de lo siguiente:

• Nombrado exportmodule.exports.name = "Alex"
• Exportación por defecto Función por defecto de exportación sayName() {console.log('Mi nombre es Mat')}

Nota : todos los paquetes de nodos incorporados admiten todos los tipos de exportaciones (nombradas, predeterminadas) descritas anteriormente. Desde la versión 14.13.0 de Node, se ha agregado soporte para la detección de exportaciones con nombre de CommonJS en ESM.

Puntos de entrada de paquetes

Ahora hay dos campos que pueden definir puntos de entrada para un paquete: mainy , en el archivo exportsde un proyecto . package.jsonSi bien el maincampo solo define el punto de entrada principal del paquete, el exportscampo proporciona una alternativa en la que se puede definir el punto de entrada principal y, al mismo tiempo, proporciona el beneficio de encapsular el paquete.

Se puede acceder a los archivos del módulo dentro de los paquetes agregando una ruta al nombre del paquete. Otra forma es si el paquete package.jsoncontiene un exportscampo donde solo se puede acceder a los archivos dentro de los paquetes a través de las rutas definidas en el exportsobjeto.

Para establecer el punto de entrada principal de un paquete, por ejemplo, es recomendable definir ambos exportsy en el archivo maindel paquete . package.jsonSe pueden encontrar más detalles en la documentación .

Sistema de módulos CommonJS

Antes de la introducción de los módulos ES, la comunidad confiaba en gran medida en CommonJS para empaquetar el código JavaScript del lado del servidor. En el sistema de módulos de CommonJS, cada archivo se trata como un módulo, que expone un conjunto de API (a través de una interfaz bien definida) con el uso del exports objeto . Para entender esto mejor, aquí hay un ejemplo usando el objeto creado por el sistema de módulos:

function sayName(name) {
    console.log(`My name is ${name}.`)
  };

function sayAge(age){
  console.log(`I'm ${age} years old.`)
  };


module.exports = {sayName, sayAge};
//a.js

Para usar estas funciones (importadas como módulos en un archivo diferente), podemos usar la requirefunción . Esto acepta un identificador de módulo (ID) especificado por una ruta relativa o absoluta o por nombre, según el tipo de módulo de las API expuestas, así:

const {sayName, sayAge} = require('./a') 
// assuming a.js is in the same folder path

console.log(sayName('Alex')) // My name is Alex.

console.log(sayAge(25)) // I'm 25 years old.

//b.js
//TO RUN THE CODE SAMPLE TYPE: $ node b.js on your terminal

Como podemos ver arriba, el requireobjeto devuelve/importa el contenido del módulo exportado desde el a.jsarchivo. Para obtener más información sobre la implementación de las palabras clave module, exporty require, podemos echar un vistazo al envoltorio del módulo aquí .

La especificación CommonJS también está disponible aquí . La especificación destaca las características mínimas que debe tener un sistema de módulos para admitir y ser interoperable con otros sistemas de módulos.

La implementación de CommonJS permite una estructura definida sobre cómo se cargan los archivos. En este enfoque, el código requerido de otros archivos se carga o analiza sincrónicamente. Por esta razón, capturar y detectar puntos de falla o depurar código es más fácil y menos tedioso.

¿Por qué? Debido a que las variables presentes en los módulos o archivos exportados están dentro del alcance de ese módulo o son privados para él y no en el alcance global, tales errores se propagan correctamente. Además, debido a la enorme separación de preocupaciones, los módulos se cargan de padre a hijo, recorriendo el gráfico de dependencia.

Nota : cuando la función contenedora regresa, el objeto exportado se almacena en caché y luego se devuelve como el valor de retorno para el require()método. Esto es como un ciclo. ¿Cómo? En la siguiente llamada al module.exportsmétodo, se repite el mismo proceso de envolver el módulo con la función de envoltorio. Pero no sin antes comprobar si ese módulo ya está almacenado en la caché.

La firma de la función contenedora se muestra a continuación:

(function(exports, require, module, __filename, __dirname) {
// Module code actually lives in here
});

El Moduleobjeto, que toma como parámetros un ID y un módulo padre, contiene el exportobjeto:

function Module(id = '', parent) {
  this.id = id;
  this.path = path.dirname(id);
  this.exports = {};
  this.parent = parent;
  updateChildren(parent, this, false);
  this.filename = null;
  this.loaded = false;
  this.children = [];
};

El updateChildrenmétodo explora la ruta del archivo hasta llegar a la raíz del sistema de archivos. Su trabajo es actualizar la childrenpropiedad del Moduleobjeto con el nuevo parent, según sea el caso. Aquí está la firma a continuación:

function updateChildren(parent, child, scan) {
  const children = parent && parent.children;
  if (children && !(scan && children.includes(child)))
   children.push(child);
}

Veamos un ejemplo para entender esto mejor. En el b.jsarchivo anterior, agregue esta línea de código para imprimir el módulo y el objeto de argumento:

console.log(módulo, argumentos);

Después de ejecutar node b.js, obtenemos el siguiente resultado:

retina@alex es-modules in Node % node b.js
My name is Alex.
undefined
I'm 25 years old.
undefined
<ref *1> Module {
  id: '.',
  path: '/Users/retina/Desktop/es-modules in Node',
  exports: {},
  parent: null,
  filename: '/Users/retina/Desktop/es-modules in Node/b.js',
  loaded: false,
  children: [
    Module {
      id: '/Users/retina/Desktop/es-modules in Node/a.js',
      path: '/Users/retina/Desktop/es-modules in Node',
      exports: [Object],
      parent: [Circular *1],
      filename: '/Users/retina/Desktop/es-modules in Node/a.js',
      loaded: true,
      children: [],
      paths: [Array]
    }
  ],
  paths: [
    '/Users/retina/Desktop/es-modules in Node/node_modules',
    '/Users/retina/Desktop/node_modules',
    '/Users/retina/node_modules',
    '/Users/node_modules',
    '/node_modules'
  ]
} [Arguments] {
  '0': {},
  '1': [Function: require] {
    resolve: [Function: resolve] { paths: [Function: paths] },
    main: Module {
      id: '.',
      path: '/Users/retina/Desktop/es-modules in Node',
      exports: {},
      parent: null,
      filename: '/Users/retina/Desktop/es-modules in Node/b.js',
      loaded: false,
      children: [Array],
      paths: [Array]
    },
    extensions: [Object: null prototype] {
      '.js': [Function (anonymous)],
      '.json': [Function (anonymous)],
      '.node': [Function (anonymous)]
    },
    cache: [Object: null prototype] {
      '/Users/retina/Desktop/es-modules in Node/b.js': [Module],
      '/Users/retina/Desktop/es-modules in Node/a.js': [Module]
    }
  },
  '2': Module {
    id: '.',
    path: '/Users/retina/Desktop/es-modules in Node',
    exports: {},
    parent: null,
    filename: '/Users/retina/Desktop/es-modules in Node/b.js',
    loaded: false,
    children: [ [Module] ],
    paths: [
      '/Users/retina/Desktop/es-modules in Node/node_modules',
      '/Users/retina/Desktop/node_modules',
      '/Users/retina/node_modules',
      '/Users/node_modules',
      '/node_modules'
    ]
  },
  '3': '/Users/retina/Desktop/es-modules in Node/b.js',
  '4': '/Users/retina/Desktop/es-modules in Node'
}

Como se muestra arriba, podemos ver el objeto del módulo en la línea 6 con todas las propiedades, incluidos filename, id, children, profundidad de la ruta, etc. Además, podemos ver el argumentobjeto, que consiste en la ruta del exportobjeto, la requirefunción, el archivo y la carpeta, y the Module(que es esencialmente lo que hace la función contenedora, pero ejecuta el código contenido en un archivo/módulo).

Finalmente, como ejercicio, podemos continuar e imprimir la requirefunción en el b.jsarchivo. Para obtener más información sobre el resultado de la requirefunción, podemos consultar la implementación en esta sección del código fuente de Node.

Nota : Se debe poner especial énfasis en los métodos y . El método, como su nombre lo indica, verifica si el ID del módulo pasado es una cadena válida. Para comprender la función require en un nivel mucho más alto, puede consultar la sección Knowledge de la documentación de Node.loadvalidateStringvalidateString

Interoperabilidad para ambos sistemas de módulos

En CommonJS, los módulos se empaquetan como funciones antes de que se evalúen en tiempo de ejecución. Para los módulos ES, la reutilización de código proporcionada a través importy el export enlace ya están creados o cargados de forma asíncrona antes de que se evalúen. Para comprender cómo funciona ESM bajo el capó, puede consultar aquí . Ahora exploremos más 🙂

Para una comparación rápida, un módulo CommonJS pasa por esta fase en su ciclo de vida:

Resolución -> Carga -> Envoltura -> Evaluación -> Almacenamiento en caché

Esto valida el hecho de que para CommonJS, no hay forma de determinar qué se exporta como módulo hasta que el módulo se empaqueta y evalúa. Esto es bastante diferente para los módulos ES, ya que el lenguaje ya analiza y comprende los símbolos importados antes de que se evalúe el código.

Cuando se analiza el código, justo antes de que se evalúe, se crea un registro de módulo interno , y solo después de que esta estructura de datos esté bien formada, se analizan los archivos y se evalúa el código.

Por ejemplo:

//d.mjs
const check = () => {
  console.log('Just checking`);
};
export.check = check;


//e.mjs assuming they are on the same folder path
import {check} from './d'

En el e.mjsarchivo anterior, Node.js analiza y valida las importaciones antes de continuar con la ejecución o evaluación de la pieza de código. Este no es el caso de un módulo CommonJS: los símbolos exportados solo se dan a conocer después de que el módulo se ajusta y evalúa.

Esta incompatibilidad es una de las muchas razones por las que el organismo estándar a cargo de ECMAScript pretendía implementar la interoperabilidad tanto para ESM como para el sistema de módulos CommonJS existente de Node.

Además, la resolución del especificador actual no es compatible con todos los comportamientos predeterminados del cargador CommonJS. Una de las principales diferencias es la resolución automática de extensiones de archivo y la capacidad de importar directorios que tienen un archivo de índice.

Por ejemplo, si hacemos un import './directory'desde, digamos, un directorio que tiene un index.js, los módulos ES no buscan un index.jsarchivo en la carpeta especificada, como ocurría en CommonJS. En su lugar, arroja un error. Esto se puede arreglar pasando la bandera experimental --experimental-specifier-resolution=[mode]. Más detalles aquí .

Nota : para personalizar la resolución del módulo predeterminado, se pueden proporcionar ganchos de cargador opcionalmente a través del --experimental-loader ./loader-name.mjsargumento de Node.js. Las API de los cargadores se están rediseñando actualmente, lo que significa que cambiarán en el futuro.

Además, mientras que las declaraciones de importación pueden hacer referencia tanto a un módulo ES como a un módulo commonJS, las declaraciones de importación solo se permiten en módulos ES. Sin embargo, para cargar módulos ES, commonJS admite expresiones de importación dinámica. Además, se puede construir una función de requisito dentro de un ESM utilizando el module.createRequire()método.

Se pueden encontrar más detalles sobre la interoperabilidad con CommonJS en esta sección de la documentación.

Características de ambos sistemas de módulos

• Dynamic import()es compatible con los módulos CommonJS y ES. Se puede usar para incluir archivos de módulo ES del código CommonJS
• ECMAScript 6 también proporciona que los módulos se puedan cargar desde una URL, mientras que CommonJS se limita a rutas de archivo relativas y absolutas. Esta nueva mejora no solo complica la carga, sino que también la ralentiza
• Las fuentes que están en formatos que Node.js no comprende se pueden convertir a JavaScript. Más detalles se pueden encontrar aquí
• Se eliminó el soporte para puntos de entrada principales sin extensión en ESM
• Propuesta-importación-meta proporciona la URL absoluta del archivo del módulo ES actual. Actualmente es una propuesta de etapa 4 en la especificación TC39.
• Las importaciones dinámicas se pueden usar para importar módulos ES y CommonJS. En los módulos CommonJS, se puede usar para cargar módulos ES. Tenga en cuenta que devuelve una promesa.
• Se debe proporcionar una extensión de archivo al usar la importpalabra clave. Los índices de directorio (p. ej., './database/index.js') deben especificarse por completo
• Dual CommonJS y ESM ahora son posibles con el uso de exportaciones condicionales. Ahora, Node.js puede ejecutar puntos de entrada del módulo ES y un paquete puede contener puntos de entrada CommonJS y ESM
• A partir de la versión 14.13.1, ESM agregó soporte para usar node: URLspara cargar módulos integrados de Node.js, lo que permite hacer referencia a los módulos integrados mediante cadenas de URL absolutas válidas

Nota : la función requireno debe usarse en módulos ES. Esto se debe a que los módulos ES se ejecutan de forma asíncrona. Para cargar un módulo ES desde un módulo CommonJS, podemos hacer uso de import().

Los lectores también deben tener en cuenta que todavía existen algunas diferencias conocidas entre los módulos ESM y commonJS. Por ejemplo, actualmente los módulos nativos no son compatibles con las importaciones de ESM. Además, el cargador de módulos ES tiene su propio tipo de sistema de almacenamiento en caché y no se basa require.cacheen el lenguaje commonJS.

Otros incluyen la falta de disponibilidad de _filename o _dirname que se encuentran en el sistema de módulos commonJS. ESM proporciona otras formas de replicar este comportamiento con el uso de import.meta.url.

Para obtener más detalles sobre las diferencias entre los módulos ES y los módulos commonJS, los lectores pueden consultar esta sección de la documentación .

Módulos ES avanzando

Los módulos ES ya no están etiquetados como experimentales y ahora son estables en términos de implementación técnica a partir de la versión 15.3.0 de Node. Esto significa que ahora están listos para su uso en producción. El desafío, por lo tanto, es que los autores, mantenedores y desarrolladores del paquete sean explícitos al definir el campo de tipo en el package.jsonarchivo y otras convenciones útiles discutidas en las especificaciones. Más detalles sobre esto se pueden encontrar aquí .

Hoy en día, es posible usar tanto CommonJS como ESM en una sola aplicación, pero con menos fricción. Pero, por supuesto, los módulos CommonJS necesitan saber si el módulo que se está cargando es un módulo CommonJS o ES, ya que este último se carga solo de forma asíncrona.

Los problemas relacionados con el peligro de los paquetes dobles y las formas de evitar o reducir estos peligros se tratan ampliamente en la sección del paquete de la documentación.

Además, de acuerdo con las especificaciones de ESM, el uso de la palabra clave import no completa la ruta del archivo de manera predeterminada con la extensión del nombre del archivo, como ocurre con los módulos CommonJS. Por lo tanto, esto también debe indicarse explícitamente de antemano. Se pueden encontrar más detalles en la sección que describe las diferencias entre ambos sistemas de módulos .

Conclusión

Antes de la introducción del estándar ES6, no había ninguna implementación nativa para organizar el código fuente en JavaScript del lado del servidor. La comunidad se basó en gran medida en el formato del módulo CommonJS.

Hoy en día, con la introducción y la estabilización de la API de los módulos ES, los desarrolladores pueden disfrutar de los muchos beneficios asociados con la especificación de lanzamiento. Este artículo ha destacado la transición entre ambos sistemas de módulos y su interoperabilidad.

Tenga en cuenta que este artículo no ha cubierto la API de los cargadores, ya que aún son experimentales y definitivamente cambiarán en futuras versiones. Para obtener más información al respecto, consulte esta sección de la documentación.

Herramientas como Babel y esm , que traducen la sintaxis más nueva en código compatible con entornos más antiguos, la transición se vuelve aún más fácil.

A la larga, todo este proceso de borrador es un paso importante y allana el camino para futuras mejoras.

 Gracias por leer 🙂

Fuente: https://blog.logrocket.com/es-modules-in-node-today/

#modules #esmodule 

What is GEEK

Buddha Community

NBB: Ad-hoc CLJS Scripting on Node.js

Nbb

Not babashka. Node.js babashka!?

Ad-hoc CLJS scripting on Node.js.

Status

Experimental. Please report issues here.

Goals and features

Nbb's main goal is to make it easy to get started with ad hoc CLJS scripting on Node.js.

Additional goals and features are:

• Fast startup without relying on a custom version of Node.js.
• Small artifact (current size is around 1.2MB).
• First class macros.
• Support building small TUI apps using Reagent.
• Complement babashka with libraries from the Node.js ecosystem.

Requirements

Nbb requires Node.js v12 or newer.

How does this tool work?

CLJS code is evaluated through SCI, the same interpreter that powers babashka. Because SCI works with advanced compilation, the bundle size, especially when combined with other dependencies, is smaller than what you get with self-hosted CLJS. That makes startup faster. The trade-off is that execution is less performant and that only a subset of CLJS is available (e.g. no deftype, yet).

Usage

Install nbb from NPM:

$ npm install nbb -g

Omit -g for a local install.

Try out an expression:

$ nbb -e '(+ 1 2 3)'
6

And then install some other NPM libraries to use in the script. E.g.:

$ npm install csv-parse shelljs zx

Create a script which uses the NPM libraries:

(ns script
  (:require ["csv-parse/lib/sync$default" :as csv-parse]
            ["fs" :as fs]
            ["path" :as path]
            ["shelljs$default" :as sh]
            ["term-size$default" :as term-size]
            ["zx$default" :as zx]
            ["zx$fs" :as zxfs]
            [nbb.core :refer [*file*]]))

(prn (path/resolve "."))

(prn (term-size))

(println (count (str (fs/readFileSync *file*))))

(prn (sh/ls "."))

(prn (csv-parse "foo,bar"))

(prn (zxfs/existsSync *file*))

(zx/$ #js ["ls"])

Call the script:

$ nbb script.cljs
"/private/tmp/test-script"
#js {:columns 216, :rows 47}
510
#js ["node_modules" "package-lock.json" "package.json" "script.cljs"]
#js [#js ["foo" "bar"]]
true
$ ls
node_modules
package-lock.json
package.json
script.cljs

Macros

Nbb has first class support for macros: you can define them right inside your .cljs file, like you are used to from JVM Clojure. Consider the plet macro to make working with promises more palatable:

(defmacro plet
  [bindings & body]
  (let [binding-pairs (reverse (partition 2 bindings))
        body (cons 'do body)]
    (reduce (fn [body [sym expr]]
              (let [expr (list '.resolve 'js/Promise expr)]
                (list '.then expr (list 'clojure.core/fn (vector sym)
                                        body))))
            body
            binding-pairs)))

Using this macro we can look async code more like sync code. Consider this puppeteer example:

(-> (.launch puppeteer)
      (.then (fn [browser]
               (-> (.newPage browser)
                   (.then (fn [page]
                            (-> (.goto page "https://clojure.org")
                                (.then #(.screenshot page #js{:path "screenshot.png"}))
                                (.catch #(js/console.log %))
                                (.then #(.close browser)))))))))

Using plet this becomes:

(plet [browser (.launch puppeteer)
       page (.newPage browser)
       _ (.goto page "https://clojure.org")
       _ (-> (.screenshot page #js{:path "screenshot.png"})
             (.catch #(js/console.log %)))]
      (.close browser))

See the puppeteer example for the full code.

Since v0.0.36, nbb includes promesa which is a library to deal with promises. The above plet macro is similar to promesa.core/let.

Startup time

$ time nbb -e '(+ 1 2 3)'
6
nbb -e '(+ 1 2 3)'   0.17s  user 0.02s system 109% cpu 0.168 total

The baseline startup time for a script is about 170ms seconds on my laptop. When invoked via npx this adds another 300ms or so, so for faster startup, either use a globally installed nbb or use $(npm bin)/nbb script.cljs to bypass npx.

Dependencies

NPM dependencies

Nbb does not depend on any NPM dependencies. All NPM libraries loaded by a script are resolved relative to that script. When using the Reagent module, React is resolved in the same way as any other NPM library.

Classpath

To load .cljs files from local paths or dependencies, you can use the --classpath argument. The current dir is added to the classpath automatically. So if there is a file foo/bar.cljs relative to your current dir, then you can load it via (:require [foo.bar :as fb]). Note that nbb uses the same naming conventions for namespaces and directories as other Clojure tools: foo-bar in the namespace name becomes foo_bar in the directory name.

To load dependencies from the Clojure ecosystem, you can use the Clojure CLI or babashka to download them and produce a classpath:

$ classpath="$(clojure -A:nbb -Spath -Sdeps '{:aliases {:nbb {:replace-deps {com.github.seancorfield/honeysql {:git/tag "v2.0.0-rc5" :git/sha "01c3a55"}}}}}')"

and then feed it to the --classpath argument:

$ nbb --classpath "$classpath" -e "(require '[honey.sql :as sql]) (sql/format {:select :foo :from :bar :where [:= :baz 2]})"
["SELECT foo FROM bar WHERE baz = ?" 2]

Currently nbb only reads from directories, not jar files, so you are encouraged to use git libs. Support for .jar files will be added later.

Current file

The name of the file that is currently being executed is available via nbb.core/*file* or on the metadata of vars:

(ns foo
  (:require [nbb.core :refer [*file*]]))

(prn *file*) ;; "/private/tmp/foo.cljs"

(defn f [])
(prn (:file (meta #'f))) ;; "/private/tmp/foo.cljs"

Reagent

Nbb includes reagent.core which will be lazily loaded when required. You can use this together with ink to create a TUI application:

$ npm install ink

ink-demo.cljs:

(ns ink-demo
  (:require ["ink" :refer [render Text]]
            [reagent.core :as r]))

(defonce state (r/atom 0))

(doseq [n (range 1 11)]
  (js/setTimeout #(swap! state inc) (* n 500)))

(defn hello []
  [:> Text {:color "green"} "Hello, world! " @state])

(render (r/as-element [hello]))

Promesa

Working with callbacks and promises can become tedious. Since nbb v0.0.36 the promesa.core namespace is included with the let and do! macros. An example:

(ns prom
  (:require [promesa.core :as p]))

(defn sleep [ms]
  (js/Promise.
   (fn [resolve _]
     (js/setTimeout resolve ms))))

(defn do-stuff
  []
  (p/do!
   (println "Doing stuff which takes a while")
   (sleep 1000)
   1))

(p/let [a (do-stuff)
        b (inc a)
        c (do-stuff)
        d (+ b c)]
  (prn d))

$ nbb prom.cljs
Doing stuff which takes a while
Doing stuff which takes a while
3

Also see API docs.

Js-interop

Since nbb v0.0.75 applied-science/js-interop is available:

(ns example
  (:require [applied-science.js-interop :as j]))

(def o (j/lit {:a 1 :b 2 :c {:d 1}}))

(prn (j/select-keys o [:a :b])) ;; #js {:a 1, :b 2}
(prn (j/get-in o [:c :d])) ;; 1

Most of this library is supported in nbb, except the following:

• destructuring using :syms
• property access using .-x notation. In nbb, you must use keywords.

See the example of what is currently supported.

Examples

See the examples directory for small examples.

Also check out these projects built with nbb:

• c64core: retrocompute aesthetics twitter bot
• gallery.cljs: script to download walpapers from windowsonearth.org.
• nbb-action-example: example of a Github action built with nbb.

API

See API documentation.

Migrating to shadow-cljs

See this gist on how to convert an nbb script or project to shadow-cljs.

Build

Prequisites:

• babashka >= 0.4.0
• Clojure CLI >= 1.10.3.933
• Node.js 16.5.0 (lower version may work, but this is the one I used to build)

To build:

• Clone and cd into this repo
• bb release

Run bb tasks for more project-related tasks.

Download Details:
Author: borkdude
Download Link: Download The Source Code
Official Website: https://github.com/borkdude/nbb 
License: EPL-1.0

#node #javascript

Hire Dedicated Node.js Developers - Hire Node.js Developers

If you look at the backend technology used by today’s most popular apps there is one thing you would find common among them and that is the use of NodeJS Framework. Yes, the NodeJS framework is that effective and successful.

If you wish to have a strong backend for efficient app performance then have NodeJS at the backend.

WebClues Infotech offers different levels of experienced and expert professionals for your app development needs. So hire a dedicated NodeJS developer from WebClues Infotech with your experience requirement and expertise.

So what are you waiting for? Get your app developed with strong performance parameters from WebClues Infotech

For inquiry click here: https://www.webcluesinfotech.com/hire-nodejs-developer/

Book Free Interview: https://bit.ly/3dDShFg

#hire dedicated node.js developers #hire node.js developers #hire top dedicated node.js developers #hire node.js developers in usa & india #hire node js development company #hire the best node.js developers & programmers

Why use Node.js for Web Development? Benefits and Examples of Apps

Front-end web development has been overwhelmed by JavaScript highlights for quite a long time. Google, Facebook, Wikipedia, and most of all online pages use JS for customer side activities. As of late, it additionally made a shift to cross-platform mobile development as a main technology in React Native, Nativescript, Apache Cordova, and other crossover devices. 

Throughout the most recent couple of years, Node.js moved to backend development as well. Designers need to utilize a similar tech stack for the whole web project without learning another language for server-side development. Node.js is a device that adjusts JS usefulness and syntax to the backend. 

What is Node.js? 

Node.js isn’t a language, or library, or system. It’s a runtime situation: commonly JavaScript needs a program to work, however Node.js makes appropriate settings for JS to run outside of the program. It’s based on a JavaScript V8 motor that can run in Chrome, different programs, or independently. 

The extent of V8 is to change JS program situated code into machine code — so JS turns into a broadly useful language and can be perceived by servers. This is one of the advantages of utilizing Node.js in web application development: it expands the usefulness of JavaScript, permitting designers to coordinate the language with APIs, different languages, and outside libraries.

What Are the Advantages of Node.js Web Application Development? 

Of late, organizations have been effectively changing from their backend tech stacks to Node.js. LinkedIn picked Node.js over Ruby on Rails since it took care of expanding responsibility better and decreased the quantity of servers by multiple times. PayPal and Netflix did something comparative, just they had a goal to change their design to microservices. We should investigate the motivations to pick Node.JS for web application development and when we are planning to hire node js developers. 

Amazing Tech Stack for Web Development 

The principal thing that makes Node.js a go-to environment for web development is its JavaScript legacy. It’s the most well known language right now with a great many free devices and a functioning local area. Node.js, because of its association with JS, immediately rose in ubiquity — presently it has in excess of 368 million downloads and a great many free tools in the bundle module. 

Alongside prevalence, Node.js additionally acquired the fundamental JS benefits: 

• quick execution and information preparing; 
• exceptionally reusable code; 
• the code is not difficult to learn, compose, read, and keep up; 
• tremendous asset library, a huge number of free aides, and a functioning local area. 

In addition, it’s a piece of a well known MEAN tech stack (the blend of MongoDB, Express.js, Angular, and Node.js — four tools that handle all vital parts of web application development). 

Designers Can Utilize JavaScript for the Whole Undertaking 

This is perhaps the most clear advantage of Node.js web application development. JavaScript is an unquestionable requirement for web development. Regardless of whether you construct a multi-page or single-page application, you need to know JS well. On the off chance that you are now OK with JavaScript, learning Node.js won’t be an issue. Grammar, fundamental usefulness, primary standards — every one of these things are comparable. 

In the event that you have JS designers in your group, it will be simpler for them to learn JS-based Node than a totally new dialect. What’s more, the front-end and back-end codebase will be basically the same, simple to peruse, and keep up — in light of the fact that they are both JS-based. 

A Quick Environment for Microservice Development 

There’s another motivation behind why Node.js got famous so rapidly. The environment suits well the idea of microservice development (spilling stone monument usefulness into handfuls or many more modest administrations). 

Microservices need to speak with one another rapidly — and Node.js is probably the quickest device in information handling. Among the fundamental Node.js benefits for programming development are its non-obstructing algorithms.

Node.js measures a few demands all at once without trusting that the first will be concluded. Many microservices can send messages to one another, and they will be gotten and addressed all the while. 

Versatile Web Application Development 

Node.js was worked in view of adaptability — its name really says it. The environment permits numerous hubs to run all the while and speak with one another. Here’s the reason Node.js adaptability is better than other web backend development arrangements. 

Node.js has a module that is liable for load adjusting for each running CPU center. This is one of numerous Node.js module benefits: you can run various hubs all at once, and the environment will naturally adjust the responsibility. 

Node.js permits even apportioning: you can part your application into various situations. You show various forms of the application to different clients, in light of their age, interests, area, language, and so on. This builds personalization and diminishes responsibility. Hub accomplishes this with kid measures — tasks that rapidly speak with one another and share a similar root. 

What’s more, Node’s non-hindering solicitation handling framework adds to fast, letting applications measure a great many solicitations. 

Control Stream Highlights

Numerous designers consider nonconcurrent to be one of the two impediments and benefits of Node.js web application development. In Node, at whatever point the capacity is executed, the code consequently sends a callback. As the quantity of capacities develops, so does the number of callbacks — and you end up in a circumstance known as the callback damnation. 

In any case, Node.js offers an exit plan. You can utilize systems that will plan capacities and sort through callbacks. Systems will associate comparable capacities consequently — so you can track down an essential component via search or in an envelope. At that point, there’s no compelling reason to look through callbacks.

 

Final Words

So, these are some of the top benefits of Nodejs in web application development. This is how Nodejs is contributing a lot to the field of web application development. 

I hope now you are totally aware of the whole process of how Nodejs is really important for your web project. If you are looking to hire a node js development company in India then I would suggest that you take a little consultancy too whenever you call. 

Good Luck!

Original Source

#node.js development company in india #node js development company #hire node js developers #hire node.js developers in india #node.js development services #node.js development

Node JS Development Company| Node JS Web Developers-SISGAIN

Top organizations and start-ups hire Node.js developers from SISGAIN for their strategic software development projects in Illinois, USA. On the off chance that you are searching for a first rate innovation to assemble a constant Node.js web application development or a module, Node.js applications are the most appropriate alternative to pick. As Leading Node.js development company, we leverage our profound information on its segments and convey solutions that bring noteworthy business results. For more information email us at hello@sisgain.com

#node.js development services #hire node.js developers #node.js web application development #node.js development company #node js application

Top 10 NodeJs app Development Companies- ValueCoders

Node.js is a prominent tech trend in the space of web and mobile application development. It has been proven very efficient and useful for a variety of application development. Thus, all business owners are eager to leverage this technology for creating their applications.

Are you striving to develop an application using Node.js? But can’t decide which company to hire for NodeJS app development? Well! Don’t stress over it, as the following list of NodeJS app development companies is going to help you find the best partner.

Let’s take a glance at top NodeJS application development companies to hire developers in 2021 for developing a mind-blowing application solution.

Before enlisting companies, I would like to say that every company has a foundation on which they thrive. Their end goals, qualities, and excellence define their competence. Thus, I prepared this list by considering a number of aspects. While making this list, I have considered the following aspects:

• Review and rating
• Enlisted by software peer & forums
• Hourly price
• Offered services
• Year of experience (Average 8+ years)
• Credibility & Excellence
• Served clients and more

I believe this list will help you out in choosing the best NodeJS service provider company. So, now let’s explore the top NodeJS developer companies to choose from in 2021.

#1. JSGuru

JSGuru is a top-rated NodeJS app development company with an innovative team of dedicated NodeJS developers engaged in catering best-class UI/UX design, software products, and AWS professional services.

It is a team of one of the most talented developers to hire for all types of innovative solution development, including social media, dating, enterprise, and business-oriented solutions. The company has worked for years with a number of startups and launched a variety of products by collaborating with big-name corporations like T-systems.

If you want to hire NodeJS developers to secure an outstanding application, I would definitely suggest them. They serve in the area of eLearning, FinTech, eCommerce, Telecommunications, Mobile Device Management, and more.

• Ratings: 4.9/5.0

• Founded: 2006

• Headquarters: Banja Luka, Bosnia, and Herzegovina

• Price: Starting from $50/hour

Visit Website - https://www.valuecoders.com/blog/technology-and-apps/top-node-js-app-development-companies

#node js developer #hire node js developer #hiring node js developers #node js development company #node.js development company #node js development services