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.
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.
Jsi implements version 5.1 of the Ecma-script 262 standard, with the following deviations:
- Semicolons are not auto-inserted.
- Empty array/object elements are not supported, eg. [1,,3].
- It is an error to use return inside the body of try/catch/with.
- delete works with more than just object properties.
- The Error object is unimplemented: the argument to catch() is just a string.
- The Date object is unimplemented: use strftime/strptime.
- The value of typeof  is "array" instead of "object".
- UTF support is only lightly tested.
- Prototype and other inheritance related features are incomplete, and can even be disabled entirely.
- Not every method is implemented in the core but are polyfills (eg. Array.reduce).
- Select features from newer versions of the standard (eg. Array of and forEach).
- Functions supporting parameters with types and defaults.
- Type-checking and testing support.
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.
- 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.