JS++ 0.5.2: BSD License, Interfaces, Abstract Classes, Virtual Methods, Non-generic Standard Library Classes

You’ve asked and we’ve listened. JS++ is now licensed under the 3-clause BSD License.

When we first announced 0.5.1 back in March, we introduced bare minimum classes. Specifically, I noted the following class features were unavailable:

  • Generic classes
  • Abstract classes
  • Inner classes
  • Interfaces
  • Virtual methods
  • Custom Conversion Rules as defined in my book, “The JS++ Type System”, Chapter 6.2

Every feature in the above list that isn’t crossed out is now available except the last feature (custom conversion rules) which will be arriving next. In addition, today’s release marks the introduction of the Standard Library. I’m going to briefly introduce the new features.

Update to Hello World

The JS++ Hello World program is now written as:

import System;

Console.log("Hello World");

Notice we no longer have to declare console as external. external is used for importing JavaScript libraries, and since we didn’t have a JS++ console implementation yet, we resorted to using the JavaScript console. However, now that we have a Console class in the Standard Library, it’s no longer a problem.

It is always recommended that you use the Standard Library’s Console class over the external JavaScript console. JS++ will detect if a console is available and will not crash if you try to log to an unavailable console. This can be a problem for web browsers like older versions of Internet Explorer, which are still used heavily in enterprise web applications.

Standard Library

The following Standard Library classes are now available:

  • System.Boolean
  • System.Character
  • System.Console
  • System.Date
  • System.Double
  • System.Exception
  • System.Exceptions
  • System.Integer8
  • System.UInteger8
  • System.Integer16
  • System.UInteger16
  • System.Integer32
  • System.UInteger32
  • System.Math
  • System.Object
  • System.RegExp
  • System.String

Many of the above classes, such as System.String and System.Integer32, are wrapper classes for auto-boxing. Currently, these wrapper classes simply provide a type-safe (and sometimes optimized) version of their JavaScript-equivalent methods. For example:

import System;

string s = "my string";
Console.log(s.replace(/^[a-z]/, string(string match){ return match.toUpperCase(); })); // Prints "My string"

The above example provides the exact same functionality as JavaScript’s String.prototype.replace. However, you get safety guarantees that you wouldn’t get with JavaScript. For example, if you try to call System.String.replace using the wrong arguments:

[  ERROR  ] JSPPE5023: No overload for `System.String.replace' that takes `1' argument(s) at line 4 char 12 at replace.jspp


Always favor using the JS++ Standard Library over “rolling your own” functions. Consider the following code (which you can run yourself with the latest JS++):

import System;

double t = (new Date).getTime();
string z;
for (int i = 0; i < 5000000; ++i) {
	z += Double.POSITIVE_INFINITY.toString();
Console.log((new Date).getTime() - t);

And the nearly equivalent JavaScript code:

var t = (new Date).getTime();
var z = "";
for (var i = 0; i < 5000000; ++i) {
	z += Number.POSITIVE_INFINITY.toString();
console.log((new Date).getTime() - t);

JS++ average time: 124.4ms
JavaScript average time: 211ms

In this case, JS++ is roughly 70% faster... for nearly identical code.

You may think JS++ adds overhead (based on perceptions of what fast code may look like), but well-written JS++ will be faster than JavaScript. See my other article on optimization for more details.

Typed Exceptions and Multiple Catch Clauses

JS++ 0.5.2 introduces the System.Exception class and enables you to create your own custom exceptions.

Here's an example:

import System;

class CustomException : System.Exception
    CustomException() {
    CustomException(string message) {

try {
    throw new CustomException("This is a custom exception object.");
catch(CustomException e) {
    Console.log("Caught CustomException");
catch(System.Exception e) {
    Console.log("Caught System.Exception");

Variadic Parameters

The latest version of JS++ also introduces variadic parameters, which allow you to supply an arbitrary number of arguments to a function:

import System;

void log(Date date, ...string messages, bool silent) {
    if (silent) return;

    foreach(string message in messages) {
        Console.log(date.toString() + ": " + message);

log(new Date(), "1", "2", "3", false);


An interface creates a contract. Methods defined in an interface must be implemented by all inheriting classes. Classes can inherit more than one interface.

According to JS++ naming conventions, interfaces should be prefixed with "I" and should be UpperCamelCase.

import System;

interface IWalkable {
	void walk();
interface ITalkable {
	void talk();

class Person : IWalkable, ITalkable
	void talk() {
	void walk() {

Person person = new Person();

Callback Type Parameter Names

Callback types can have parameters. Previously, you could only specify the parameter types for a callback/function type. However, you can now add names for these parameters. While these names cannot be used and have no meaningful effect on the executed code, they improve the readability of the code.

import System;

class Bird
	void fly() {

void(Bird bird) fly = void(Bird bird) {
Bird bird = new Bird();

Removal of 'Convert' Module

We have removed from the Convert module from the latest release. It was always used as a stopgap until we implemented the Standard Library wrapper classes, which provide toString() and other methods.

Bug fix: 'typeof' for internal types

For non-external types, typeof will always return the string "internal".

import System;

int x;
Console.log(typeof x); // "internal"

Virtual Methods

JS++ 0.5.2 introduces the virtual keyword and the override keyword to enable virtual methods on classes.

Virtual methods enable late binding and runtime polymorphism.

class Shape
    public virtual double area() {
        return 0;
class Rectangle : Shape
    private int length, width;
    public Rectangle(int length, int width) {
        this.length = length;
        this.width = width;
    public override double area() {
        return length * width;
class Triangle : Shape
    private int base, height;
    public Triangle(int base, int height) {
        this.base = base;
        this.height = height;
    public override double area() {
        return (base * height) / 2;

Abstract Classes

Use the abstract modifier to create abstract classes and methods.

abstract class Shape
    public abstract int area();
class Rectangle : Shape
    private int length, width;
    public override int area() {
        return length * width;


Enumerations (enums) can be used to restrict values and write type-safe code:

enum Importance { None, Regular, Critical }
Importance errorLevel = Importance.Critical;

The one missing feature...

Sadly, there is still one major missing feature from JS++. The Standard Library does not support System.Array yet because it is a generic class, and generics have not yet been implemented. In the meantime, you can resort to declaring your arrays as var:

var arr = [ 1, 2, 3 ];

BSD License

Last, but not least, JS++ 0.5.2 is the first version of JS++ licensed under the 3-clause BSD License.

The download for JS++ 0.5.2 is available from our home page.

Enjoy JS++!

Code Written in JS++ Can be Significantly Faster than the Equivalent JavaScript

JS++ type guarantees don’t just mean more reliable applications. They can also mean faster applications.

People have expressed concern about the “conversion overhead” that comes with the JS++ type system. However, we’ll show you today that having code that varies in type (such as JavaScript code) can be substantially slower, and even if you lose 1ms in JS++ “conversion overhead”, you may gain 10ms, 100ms, or more from typed optimizations that you can only get with JS++.

Here are two side-by-side benchmarks:

JS++: test.jspp

import System;

double t = (new Date).getTime();
string z;
for (int i = 0; i < 5000000; ++i) {
	z += i.toString();
Console.log((new Date).getTime() - t);
$ time node test.jspp.js

real	0m0.537s
user	0m0.496s
sys	0m0.100s
$ time node test.jspp.js

real	0m0.536s
user	0m0.500s
sys	0m0.096s
$ time node test.jspp.js

real	0m0.536s
user	0m0.508s
sys	0m0.088s
$ time node test.jspp.js

real	0m0.534s
user	0m0.480s
sys	0m0.116s
$ time node test.jspp.js

real	0m0.533s
user	0m0.496s
sys	0m0.096s

JavaScript: test.js

var t = (new Date).getTime();
var z = "";
for (var i = 0; i < 5000000; ++i) {
    z += i.toString();
console.log((new Date).getTime() - t);
$ time node sample.js 

real	0m0.575s
user	0m0.572s
sys	0m0.076s
$ time node sample.js 

real	0m0.561s
user	0m0.556s
sys	0m0.072s
$ time node sample.js 

real	0m0.572s
user	0m0.544s
sys	0m0.092s
$ time node sample.js 

real	0m0.565s
user	0m0.560s
sys	0m0.076s
$ time node sample.js 

real	0m0.563s
user	0m0.540s
sys	0m0.088s

Core i7-4790k
Linux x64 (Debian)
32gb RAM
Node.js v.7.9.0 (Google V8)
JS++ v.0.5.2

Take a close look at the JS++ code and the JavaScript code. They are nearly identical except the JS++ code has types and an import statement.

In this particular case, JS++ is roughly 7.2% faster than JavaScript on a basic toString() benchmark. We do some special things under the hood here, but it should be clear that even with the perceived overhead of JS++ conversions and the much heavier overhead of auto-boxing, JS++ code is still noticeably faster. However, the topic of today's post is not about toString(). If we slightly change the JavaScript code:

var t = (new Date).getTime();
var z; // variable is no longer initialized to string
for (var i = 0; i < 5000000; ++i) {
	z += i.toString();
console.log((new Date).getTime() - t);
$ time node sample.js 

real	0m0.779s
user	0m0.804s
sys	0m0.072s
$ time node sample.js 

real	0m0.783s
user	0m0.784s
sys	0m0.092s
$ time node sample.js 

real	0m0.794s
user	0m0.824s
sys	0m0.088s
$ time node sample.js 

real	0m0.787s
user	0m0.788s
sys	0m0.092s
$ time node sample.js 

real	0m0.782s
user	0m0.808s
sys	0m0.064s

Suddenly, JS++ has jumped from being ~7% faster to being 52.2% faster.

First of all, without static typing, you lose correctness. The result of the above small change results in "undefined0123..." rather than "0123...". Therefore, while it may not be the best benchmark, it illustrates the point. Besides losing correctness, the drop in performance is substantial when types change. You often see JavaScript code written where the type constantly changes, and you can see the cost of this negligence compared to JS++.

The reason this happens is because V8 optimizes "optimistically". When you initialize your variable to a string, V8's JIT code generator will generate code optimized for strings. However, when the type changes, V8 has to "de-optimize", change the variable type, convert data, and more. These are expensive operations which highlight how performance can degrade. The example we showed today involved only one variable. Imagine the performance difference in an application with thousands of variables.

Finally, the JS++ type system is patent-pending. I've made my case clear about patents being only used for competition. Since most programmers immediately jump to conclusions, I will use this example: you can use a patented skateboard without getting in trouble with the law; however, you cannot make and sell a patented skateboard without getting in trouble with the law. If you're on the fence with JS++, don't expect to see our technologies in TypeScript, Flow, or any competing language any time soon. You're free to use them, and we encourage you to do so if your only criteria when selecting technologies are "open source" and "unpatented."

JS++ is free, closed-source software licensed under the BSD License, and the benchmarks above can be executed with the latest JS++ 0.5.2 release.

Scaling JS++: Abstraction, Performance, and Readability

Sometimes, people will argue that C++ scales better than C for development teams and large projects because it has classes. While code organization is certainly helpful, Linus Torvalds will argue it is unnecessary because there are other ways of achieving code organization – such as prefixing function names with a “namespace.” JS++ is influenced a lot by C++ and Bjarne Stroustrup’s philosophies. While most people point to classes as the reason for C++’s success and scalability, there is a more subtle reason it scales so well: readability.

The C++ STL provides a level of abstraction without sacrificing performance. Stroustrup said he wanted std::vector to be as fast as C arrays. You can implement these details yourself, but why not just use std::vector?

While working on the JS++ Standard Library, Stroustrup’s philosophies have once again come into play.

As an example, think about converting a JavaScript number from decimal (base 10) to hexadecimal (base 16). Can you think – off the top of your head – how it would be done? There is a certain pleasure derived when you can read through someone else’s code as clearly and effortlessly as you might be able to read a book. We enforce these standards internally at Onux, and I’m going to reveal how it influences the design of JS++.

Getting back to the example, this is how it’s done in JavaScript:

var x = 97;

I’ve argued that we need to deprecate JavaScript’s Number.prototype.toString(base). Instead, we are proposing a toBase(unsigned int base) method to convert from base 10 (decimal) to a specified arbitrary base. Consider the readability of the following functions:


Both functions do the same thing, but I’ve argued that no programmer will ever have to look up what toBase(16) means versus toString(16). The beauty of a compiled language is that we have full control over optimization. Of course, in JavaScript, you can do this:

function toBase(number, base) {
    return number.toString(base);

All else being equal, and you care about performance, wouldn’t you much rather have this?


In JS++, we can perform this exact optimization in a process known as “function inlining”. Here’s an example from Wikipedia. In other words, even though JS++’s toBase(16) is clearer than toString(16), there is no loss of performance because toBase just gets compiled to toString with no additional function calls; the toBase method basically doesn’t even exist in the final generated code.

We can take this one step further. Converting from base 10 (decimal) to base 16 (hexadecimal) is quite common. Why not provide a Standard Library function to do this?

char x = `a`;

In this case, toHex() is just an alias for toBase(16), which is in turn an alias for toString(16). With each layer of abstraction, we gain more clarity and readability in our code. This makes it easy for others to work on our code, it makes it easy to scale development for teams, and – most of all – each layer of abstraction results in no performance loss. In fact, toHex() just gets compiled to toString(16).

Think for a moment. You’re tired, groggy, and unmotivated. Would you rather read code that looks like toString(16) or toHex()? This readability gain has only been focused on 1-3 lines of code so far. What we want to achieve with JS++ will expand across your entire code base.

When I meet programmers and they say they have problems with “spaghetti code”, I almost always guess (correctly) that they’re working at a JavaScript house. Classes – by themselves – won’t stop developers from writing unreadable code. We need abstraction… without sacrificing performance. This is what’s coming with the JS++ Standard Library. Here’s to a better future!

JS++ 0.5.1: ‘foreach’

We just released JS++ 0.5.1, which features the foreach keyword.

Basic usage is as follows:

external console;

int[] arr = [ 50, 40, 30 ];

foreach (int value in arr) {

// Output:
// 50
// 40
// 30

More complex usage, such as arrays of objects, are also possible:

external console;

class Foo
	string bar() {
		return "bar";

Foo[] foo = [ new Foo(), new Foo(), new Foo() ];

foreach (Foo value in foo) {

// Output:
// "bar"
// "bar"
// "bar"

Additionally, the for-in keyword has been implemented. It is a counterpart to the foreach keyword in the sense that it enumerates keys rather than values.

JS++ 0.5.0: Basic Classes

JS++ now supports the ‘class’ keyword. As promised, we would have classes available by Q1 2017. Notably, we are providing “basic” classes, so the following features are supported:

  • ‘class’ keyword
  • Inheritance
  • Constructors (including private/protected constructors that limit instantiation/inheritance)
  • Static Constructors
  • Instantiation
  • Fields
  • Methods
  • ‘this’ keyword
  • ‘super’ keyword
  • Method Overloading
  • Constructor Overloading
  • Getters and Setters (via ‘property’ keyword)
  • Type system support
  • Debugger support for classes (via source maps)

What did we consider to be outside the scope of basic classes? The following features are currently not available yet:

As an example of what you can do with JS++ classes, we included an example with the Tiled Map Editor:

Tiled Map Editor

The included sample for Tiled can be found in the ‘Samples/Classes/tiled-loader’ directory with JS++ 0.5.0. Currently, it will load all maps exported to JSON with orthogonal tiles. It’s just a small but powerful example of what you can start doing with JS++ for early adopters.

I am also happy to inform that the backend for the JS++ website is written completely in JS++, and it has now run stable for one week without a single crash or error (other than 404 errors).

Finally, we have made the decision to not include the Mac/Linux installer… yet.

Be sure to check out the documentation on the ‘class’ keyword to get up to speed on JS++ classes.

Download JS++ 0.5.0 from our home page.

Website Backend Now Powered by JS++

As of 8 March 2017, the backend for the JS++ website is powered by the JS++ programming language itself (in conjunction with Node.js). The backend is developed using JS++ with classes, which will be available in the next release.

We wanted to wait at least 24 hours to ensure stable operations before making this post. Based on our logs, it is clear everything is running smoothly.

Our website frontend is not completely written in JS++. It will likely be migrated in the future if the code becomes more complex.

Mac/Linux Installer Coming for JS++ 0.5

The next version of JS++ will feature the ‘class’ keyword and is expected for Q1 2017.

In addition, Mac and Linux users will benefit from a JS++ installer:

The installer is completely optional. However, it will be useful if you don’t want to manually install JS++ and various editor plugins. We auto-detect which editors are installed on your system, and, if a plugin is available, we will attempt to install it for you.

JS++ for Mac OS X Updated to Latest Version

During our Christmas release, we had to release one version down ( for Mac OS X. I’m happy to announce that – now that our staff are back from their breaks – JS++ for Mac OS X has been updated to the latest version and is in sync with JS++ for Windows and Linux.

Please note that, as of for Mac OS X, JS++ defaults to the 32-bit binary. The 64-bit binary is available as jspp-x64.

You can download JS++ for Mac OS X from our homepage.

A JS++ Christmas: AJAX, js++Unit, Mac compiler, Tutorials

Merry Christmas from JS++!

We have multiple “gifts” and announcements for you this Christmas. We have lots of new libraries written with JS++ and a new version.

Version and Mac Support

We have released version which supports callback conversions, array conversions, and C-style casts such as:

int x = (int) y;

For a long time now, we have not provided Mac support. That’s going to change beginning this Christmas. We’ve released for Mac OS X. It is one version down from the latest release for PC, but this was due to the fact that I let our staff off on holiday, found a bug with auto-boxing, and patched it at the last minute.

If you want access to our new libraries, you will need to download the new versions.

Library: js++Unit

js++Unit is an xUnit testing framework for automated testing in JS++. js++Unit currently works best for Node.js and is inspired by the Mocha test framework. It doesn’t really support the browser yet, but we’ll get there. We’re taking open source contributions for js++Unit too!

js++Unit also comes with a full-featured assertion framework (Vendor.JSPPUnit.Assert) and will do neat things like working with cycles for deepEqual.

You can download js++Unit from GitHub.

Library: ConsoleStyle

If you have a terminal emulator that supports ANSI escape codes, we have a library for you to provide colors to your console output. Download the ConsoleStyle library from GitHub. js++Unit depends on it and you need to link ConsoleStyle to use js++Unit.

Library: AJAX

Are you tired of having to include the entire jQuery library just to send an AJAX request? In JS++, you no longer have to. Since JS++ features dead code elimination, if you import an AJAX library that defines functions for HTTP GET and POST requests and you only use GET requests, the logic for POST requests will not be compiled into your final application.

You can download the AJAX library here. (It also ships with the latest version of JS++.)

Tutorial: What Are “Type Guarantees?”

The Getting Started guide has been completely re-written. We now explain how to use JavaScript libraries from JS++. We go one step further and explain what “type guarantees” are and how you can take advantage of them from JS++ using a new “RGBtoHex” tutorial.

The RGBtoHex tutorial shows an “untyped” JavaScript library. We teach you how to use it from JS++ – without ever adding types to your code. We gradually begin to add types (without compromising the soundness of the type system). Finally, we end with fully typed code and a re-usable function.

RGBtoHex is an ideal tutorial. RGB values are limited to the values 0 to 255. This is the JS++ byte data type. In the RGBtoHex tutorial, we show you how JS++ will guarantee your values will remain within the 0 to 255 range.

Check out the Getting Started tutorial now.

Merry Christmas!

JS++ Debugging with Source Maps

JS++ is being released today with support for in-browser debugging via source maps. Source maps allow you to debug your JS++ programs from a web browser of your choice that supports source maps debugging: Google Chrome, Mozilla Firefox, Microsoft Edge (untested), etc. With source maps, you can set breakpoints, log messages, and more with all locations pointing back to the original source JS++ file—rather than the generated .jspp.js file.

At the time of this writing, the recommended web browser to use for source maps debugging is Google Chrome.

In order to leverage source maps, compile your JS++ files with the --debug (or -d) flag:

Compiling source maps with JS++

This will generate a .map file, which maps the generated code back to the original JS++ source code.

When you run the generated code in your web browser, you will notice that console.log statements point to the original source .jspp file’s location rather than the locations of the generated code:

Source Maps - console.log Original Location

In addition, you can set breakpoints, step into, step over, step out and use all the features you’d expect from your debugger:

Source Maps - Set Breakpoint

Finally, we have worked to improve Microsoft Windows integration even more. In JS++ 0.4.2, we gave you Windows context menu integration. However, due to restrictions in Windows, this only allowed compilation of one file. JS++ is a multi-file, modular programming language. Thus, we needed users to be able to select multiple files and compile them. You can now do this in the latest version of JS++:


Another problem with Windows integration was that the JS++ CLI compiler would pop up and immediately exit. If you had an error, there was no way to know what to fix. With the latest version of JS++, you will now receive a popup dialog notifying you of the compilation results:


Get the latest download of JS++ by navigating to our home page.