/ Background

Design and Origin

Jsi is a byte-code oriented interpreter designed for interfacing-with, and embedding-in C.

This makes it very different from Node-js which is a compiler written in C++, and which is not designed to be embedded.

Jsi is C-centric whereas Node is JS-centric. Meaning that with Jsi, the locus of control can resides in C-code.

Although Jsi was originally was based off source from quad-wheel, it is now internally modelled after Tcl.

Glue Language

Like Tcl, Jsi is designed to be used a glue language, where only time critical code is implement as C extensions because:

  • Script code tends to be easier to write, more compact, and more resilient than C.
  • Therefore script is used when speed of implementation trumps speed of execution.
  • Efforts to increase software integrity can focus on hardening extensions.
  • Moreover, extensions and scripts can greatly facilitate C-Testing.
  • Finally C-only development is also available.

ECMA Compatibilty

Jsi implements version 5.1 of the Ecma-script 262 standard, with the following deviations:

  • Semicolons are not auto-inserted.
  • Using empty array/object elements will kick an error, eg. [1,,3].
  • delete actually deletes things, not just object properties.
  • length works for objects, as well as arrays/strings/functions.
  • The value of typeof [] is "array" instead of "object".
  • The Error object is unimplemented: the argument to catch() is just a string.
  • The Date object is unimplemented: use strftime/strptime.
  • UTF support is only for strings (not code) and is lightly tested.
  • Prototype and other inheritance related features are incomplete, and can even be disabled entirely.

Extensions include:

  • Functions parameters may have types and defaults.
  • This enables Jsi to provide type-checking and testing support.
  • Select features from newer versions of the standard (eg. Array of and forEach).
  • Non-standard object functions such as merge are available, eg. o = o1.merge({a:1,b:2});


Following are principle goals Jsi:

  • Support embedded development using plain C (C99).
  • But should also be compilable by native GNU g++, without use of "extern C".
  • Have as few dependencies as possible.
  • Be generally free of value/object/memory leaks (verified with -fsanitize).
  • Provide amalgamated source for simplified application integration .
  • Low-level C-functions available in a C-only Lite version.
  • Come with a Debugger.
  • Support Web applications, particularly with database and websockets.
  • Support standalone applications via self-mounting .zip.
  • Package and extension support.

Note that C-integration is the main priority here, not speed of script execution.

And while compiling as C++ is supported, it is mostly used for integrity checking.


Following is a partial list of things that are either incomplete or unimplemented:

  • Creation of a complete test suite for code-coverage.
  • Run applications directly from fossil.
  • A PostgreSql extension.
  • Extension for libmicrohttpd for use in post.
  • Support for libevent/libev.

While some prototype stuff is supported, lovers of object oriented should look elsewhere, as Jsi is intended for straightline code, with few-to-no unnecessary abstractions.


  • Desktop applications are held hostage by their user interface, be it QT, GTK, IOS or .NET.
  • Increasingly web browsers are becoming the GUI, usually over the Internet.
  • Moderately complex applications often end up requiring some form of script support, eg. Lua.
  • If an application employs a Web GUI, a script language already is being used: Javascript.
  • Time, energy and resources can be saved by using the same language on both ends.
  • In fact, the same scripts can even be run in both the browser and the app.
  • JSON provides seamless data interchange, thus avoiding data structure compatibility issues.