Jump to content
Sign in to follow this  
Ondrej Kelle

Node modules with Delphi and Free Pascal

Recommended Posts

https://tondrej.blogspot.com/2019/01/node-modules-with-delphi-and-free-pascal.html

 

chakracore-delphi now comes with NodeSample, a new sample console application showing (as of now very limited) support for Node modules. Included are:

 

- commonmark
- graphql
- json-query
- lodash
- moment

 

The sample only shows how Node modules can be resolved and used in Delphi and Free Pascal applications. It doesn't implement Node's event loop or any of its internal modules or native bindings like path, fs or http; any scripts referencing them will - for now - raise an exception.

 

Screencast (YouTube)

  • Like 1

Share this post


Link to post

Very interesting.

I'm not that deep in Chakra and Node, maybe can you point out the main differences between both briefly ?
Where are both cores compatible, and where not ?
Maybe you know a good source in the web like "Can-I-Use" for comparing both  engines.

I never considered Chakra as 1:1 replacement for Node, but they seems to be more close than expected.

Share this post


Link to post

ChakraCore is a Javascript (and WebAssembly) engine, comparable to Google's V8, Mozilla's SpiderMonkey or other similar implementations.

 

Node.js is much more - a runtime host environment (native executable for the target platform) embedding V8, it implements some (native code) services and exposes them to the engine through an API. For example, you can instantiate a simple web server from Javascript run by Node as described here.

 

There's also Node.js on ChakraCore, a fork of Node, using ChakraCore instead of V8 (by providing a V8 API shim layer and delegating to the ChakraCore engine).

 

Node comes with a huge online ecosystem of Javascript modules and a package manager (npm) to manage the dependencies.

Node modules can reuse other modules through an established ("require") method - you could think of it as Node's runtime equivalent of Delphi's "uses" clause in Javascript.

 

My example shows a way to implement this "require" mechanism in a Delphi or Free Pascal host application, reading npm's "package.json" files where the module metadata is declared and resolving the "require" clauses to full-path file names so they can be loaded and evaluated at runtime with ChakraCore. It doesn't provide any of Node's extra services, so modules relying on them won't work. For example, an attempt to call require('http'); from a script will raise an exception since my host application doesn't provide the "http" module and the implementation of its API (which could be done with some extra work, e.g. using Indy).

 

A hint on how one might provide those services to the engine can be found in the NodeProcess unit which is an incomplete stub implementation of the 'process' module (I just wanted to satisfy graphql for the demo).

  • Like 1

Share this post


Link to post

I considered Node as a small excutable wrapper (a main loop if you will) around the V8 engine, and all the rest done by additional JS modules.
Don't beat me if I think too simple here, but I have never looked under the hood of Node,
maybe I'm wrong and there are still a lot "system stuff modules" written in C++.

If the same thing could be done with ChakraCore too (build a small executable around, maybe via Delphi), and then use the ecosystem of V8-Node too.

Anyway, the question would be if there is any advantage of such ChakraCode-Node over V8-Node ?
Probably a smaller executable, or a better Delphi-integration, if possible at all ?

 

But your demos here look very promising.

 

Edited by Rollo62

Share this post


Link to post
2 hours ago, Rollo62 said:

I considered Node as a small excutable wrapper (a main loop if you will) around the V8 engine, and all the rest done by additional JS modules.

There's a lot implemented natively:

C:\>node --version
v11.0.0

C:\>node
> require('module').builtinModules
[ 'async_hooks',
  'assert',
  'buffer',
  'child_process',
  'console',
  'constants',
  'crypto',
  'cluster',
  'dgram',
  'dns',
  'domain',
  'events',
  'fs',
  'http',
  'http2',
  '_http_agent',
  '_http_client',
  '_http_common',
  '_http_incoming',
  '_http_outgoing',
  '_http_server',
  'https',
  'inspector',
  'module',
  'net',
  'os',
  'path',
  'perf_hooks',
  'process',
  'punycode',
  'querystring',
  'readline',
  'repl',
  'stream',
  '_stream_readable',
  '_stream_writable',
  '_stream_duplex',
  '_stream_transform',
  '_stream_passthrough',
  '_stream_wrap',
  'string_decoder',
  'sys',
  'timers',
  'tls',
  '_tls_common',
  '_tls_wrap',
  'trace_events',
  'tty',
  'url',
  'util',
  'v8',
  'vm',
  'zlib',
  'v8/tools/splaytree',
  'v8/tools/codemap',
  'v8/tools/consarray',
  'v8/tools/csvparser',
  'v8/tools/profile',
  'v8/tools/profile_view',
  'v8/tools/logreader',
  'v8/tools/arguments',
  'v8/tools/tickprocessor',
  'v8/tools/SourceMap',
  'v8/tools/tickprocessor-driver',
  'node-inspect/lib/_inspect',
  'node-inspect/lib/internal/inspect_client',
  'node-inspect/lib/internal/inspect_repl' ]
>

I believe (most of) those things are compiled and linked directly into Node executable as native code.

2 hours ago, Rollo62 said:

the question would be if there is any advantage of such ChakraCode-Node over V8-Node ?

I'm not sure. It does seem like a lot of work.

 

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×