Home

Awesome

build status npm version dependency Status devDependency Status

Zwitterion

A web dev server that lets you import anything*

* If by anything you mean: JavaScript ES2015+, TypeScript, JSON, JSX, TSX, AssemblyScript, Rust, C, C++, WebAssembly, and in the future anything that compiles to JavaScript or WebAssembly.

Zwitterion is designed to be an instant replacement for your current web development static file server.

Production deployments are also possible through the static build.

For example, you can write stuff like the following and it just works:

./index.html:

  <!DOCTYPE html>

  <html>
    <head>
      <script type="module" src="app.ts"></script>
    </head>

    <body>
      This is the simplest developer experience I've ever had!
    </body>
  </html>

./app.ts:

import { getHelloWorld } from './hello-world.ts';

const helloWorld: string = getHelloWorld();

console.log(helloWorld);

./hello-world.ts:

export function getHelloWorld(): string {
  return 'Why hello there world!';
}

Really, it just works.

Zwitterion lets you get back to the good old days of web development.

Just write your source code in any supported language and run it in the browser.

Also...Zwitterion is NOT a bundler. It eschews bundling for a simpler experience.

Current Features

Upcoming Features

Documentation

Installation and Basic Use

Local Installation and Use

Install Zwitterion in the directory that you would like to serve files from:

npm install zwitterion

Run Zwitterion by accessing its executable directly from the terminal:

node_modules/.bin/zwitterion

or from an npm script:

{
  ...
  "scripts": {
    "start": "zwitterion"
  }
  ...
}

Global Installation and Use

Install Zwitterion globally to use across projects:

npm install -g zwitterion

Run Zwitterion from the terminal:

zwitterion

or from an npm script:

{
  ...
  "scripts": {
    "start": "zwitterion"
  }
  ...
}

Production Use

It is recommended to use Zwitterion in production by creating a static build of your project. A static build essentially runs all relevant files through Zwitterion, and copies those and all other files in your project to a dist directory. You can take this directory and upload it to a Content Delivery Network (CDN), or another static file hosting service.

You may also use a running Zwitterion server in production, but for performance and potential security reasons it is not recommended.

To create a static build, run Zwitterion with the --build-static option. You will probably need to add the application/javascript MIME type to your hosting provider for your TypeScript, AssemblyScript, Rust, Wasm, and Wat files.

From the terminal:

zwitterion --build-static

From an npm script:

{
  ...
  "scripts": {
    "build-static": "zwitterion --build-static"
  }
  ...
}

The static build will be located in a directory called dist, in the same directory that you ran the --build-static command from.

Languages

JavaScript

JavaScript is the language of the web. You can learn more here.

Importing JavaScript ES2015+ is straightforward and works as expected. Simply use import and export statements without any modifications. It is recommended to use explicit file extensions:

./app.js:

import { helloWorld } from './hello-world.js';

console.log(helloWorld());

./hello-world.js:

export function helloWorld() {
  return 'Hello world!';
}

JavaScript transpilation is done by the TypeScript compiler. By default, the TypeScript compiler's compilerOptions are set to the following:

  {
    "module": "ES2015",
    "target": "ES2015"
  }

You can override these options by creating a .json file with your own compilerOptions and telling Zwitterion where to locate it with the --tsc-options-file command line option. The available options can be found here. Options are specified as a JSON object. For example:

tsc-options.json:

{
  "target": "ES5"
}

Tell Zwitterion where to locate it:

zwitterion --tsc-options-file tsc-options.json

TypeScript

TypeScript is a typed superset of JavaScript. You can learn more here.

Importing TypeScript is straightforward and works as expected. Simply use import and export statements without any modifications. It is recommended to use explicit file extensions:

./app.ts:

import { helloWorld } from './hello-world.ts';

console.log(helloWorld());

./hello-world.ts:

export function helloWorld(): string {
  return 'Hello world!';
}

By default, the TypeScript compiler's compilerOptions are set to the following:

  {
    "module": "ES2015",
    "target": "ES2015"
  }

You can override these options by creating a .json file with your own compilerOptions and telling Zwitterion where to locate it with the --tsc-options-file command line option. The available options can be found here. Options are specified as a JSON object. For example:

tsc-options.json:

{
  "target": "ES5"
}

Tell Zwitterion where to locate it:

zwitterion --tsc-options-file tsc-options.json

JSON

JSON is provided as a default export. It is recommended to use explicit file extensions:

./app.js:

import helloWorld from './hello-world.json';

console.log(helloWorld);

./hello-world.json:

{
  "hello": "world"
}

JSX

Importing JSX is straightforward and works as expected. Simply use import and export statements without any modifications. It is recommended to use explicit file extensions:

./app.js:

import { helloWorldElement } from './hello-world.jsx';

ReactDOM.render(
  helloWorldElement,
  document.getElementById('root')
);

./hello-world.jsx:

export const hellowWorldElement = <h1>Hello, world!</h1>;

JSX transpilation is done by the TypeScript compiler. By default, the TypeScript compiler's compilerOptions are set to the following:

  {
    "module": "ES2015",
    "target": "ES2015"
  }

You can override these options by creating a .json file with your own compilerOptions and telling Zwitterion where to locate it with the --tsc-options-file command line option. The available options can be found here. Options are specified as a JSON object. For example:

tsc-options.json:

{
  "target": "ES5"
}

Tell Zwitterion where to locate it:

zwitterion --tsc-options-file tsc-options.json

TSX

Importing TSX is straightforward and works as expected. Simply use import and export statements without any modifications. It is recommended to use explicit file extensions:

./app.js:

import { helloWorldElement } from './hello-world.tsx';

ReactDOM.render(
  helloWorldElement,
  document.getElementById('root')
);

./hello-world.tsx:


const helloWorld: string = 'Hello, world!';

export const hellowWorldElement = <h1>{ helloWorld }</h1>;

TSX transpilation is done by the TypeScript compiler. By default, the TypeScript compiler's compilerOptions are set to the following:

  {
    "module": "ES2015",
    "target": "ES2015"
  }

You can override these options by creating a .json file with your own compilerOptions and telling Zwitterion where to locate it with the --tsc-options-file command line option. The available options can be found here. Options are specified as a JSON object. For example:

tsc-options.json:

{
  "target": "ES5"
}

Tell Zwitterion where to locate it:

zwitterion --tsc-options-file tsc-options.json

AssemblyScript

AssemblyScript is a new language that compiles a strict subset of TypeScript to WebAssembly. You can learn more about it in The AssemblyScript Book.

Zwitterion assumes that AssemblyScript files have the .as file extension. This is a Zwitterion-specific extension choice, as the AssemblyScript project has not yet chosen its own official file extension. You can follow that discussion here. Zwitterion will follow the official extension choice once it is made.

Importing AssemblyScript is nearly identical to importing JavaScript or TypeScript. The key difference is that the default export of your entry AssemblyScript module is a function that returns a promise. This function takes as its one parameter an object containing imports to the AssemblyScript module.

Passing values to and from functions exported from AssemblyScript modules should be straightforward, but there are some limitations. Zwitterion uses as-bind under the hood to broker values to and from AssemblyScript modules. Look there if you need more information.

You can import AssemblyScript from JavaScript or TypeScript files like this:

./app.js:

import addModuleInit from './add.as';

runAssemblyScript();

async function runAssemblyScript() {
  const adddModule = await addModuleInit();

  console.log(addModule.add(1, 1));
}

./add.as:

export function add(x: i32, y: i32): i32 {
  return x + y;
}

If you want to pass in imports from outside of the AssemblyScript environment, you create a file with export declarations defining the types of the imports. You then pass your imports in as an object to the AssemblyScript module init function. The name of the property that defines your imports for a module must be the exact filename of the file exporting the import declarations. For example:

./app.js:

import addModuleInit from './add.as';

runAssemblyScript();

async function runAssemblyScript() {
  const adddModule = await addModuleInit({
    'env.as': {
      log: console.log
    }
  });

  console.log(addModule.add(1, 1));
}

./env.as:

export declare function log(x: number): void;

./add.as:

import { log } from './env.as';

export function add(x: i32, y: i32): i32 {

  log(x + y);

  return x + y;
}

You can also import AssemblyScript from within AssemblyScript files, like so:

./add.as:

import { subtract } from './subtract.as';

export function add(x: i32, y: i32): i32 {
  return subtract(x + y, 0);
}

./subtract.as:

export function subtract(x: i32, y: i32): i32 {
  return x - y;
}

By default, no compiler options have been set. The available options can be found here. You can add options by creating a .json file with an array of option names and values, and telling Zwitterion where to locate it with the --asc-options-file command line option. For example:

./asc-options.json:

[
  "--optimizeLevel", "3",
  "--runtime", "none",
  "--shrinkLevel", "2"
]

Tell Zwitterion where to locate it:

zwitterion --asc-options-file asc-options.json

Rust

Rust is a low-level language focused on performance, reliability, and productivity. Learn more here.

Rust support is currently very basic (i.e. no wasm-bindgen support). You must have Rust installed on your machine. You can find instructions for installing Rust here. It is a goal of Zwitterion to automatically install a local version of the necessary Rust tooling when Zwitterion is installed, but that is currently a work in progress.

Importing Rust is nearly identical to importing JavaScript or TypeScript. The key difference is that the default export of your entry Rust module is a function that returns a promise. This function takes as its one parameter an object containing imports to the Rust module. You can import Rust from JavaScript or TypeScript files like this:

./app.js

import addModuleInit from './add.rs';

runRust();

async function runRust() {
  const addModule = await addModuleInit();

  console.log(addModule.add(5, 5));
}

./add.rs

#![no_main]

#[no_mangle]
pub fn add(x: i32, y: i32) -> i32 {
  return x + y;
}

C

C support is currently very basic. You must have Emscripten installed on your machine. You can find instructions for installing Emscripten here. It is a goal of Zwitterion to automatically install a local version of the necessary C tooling when Zwitterion is installed, but that is currently a work in progress.

Importing C is nearly identical to importing JavaScript or TypeScript. The key difference is that the default export of your entry C module is a function that returns a promise. This function takes as its one parameter an object containing imports to the C module. You can import C from JavaScript or TypeScript files like this:

./app.js

import addModuleInit from './add.c';

runC();

async function runC() {
  const addModule = await addModuleInit();

  console.log(addModule.add(5, 5));
}

./add.c

int add(int x, int y) {
  return x + y;
}

C++

C++ support is currently very basic. You must have Emscripten installed on your machine. You can find instructions for installing Emscripten here. It is a goal of Zwitterion to automatically install a local version of the necessary C++ tooling when Zwitterion is installed, but that is currently a work in progress.

Importing C++ is nearly identical to importing JavaScript or TypeScript. The key difference is that the default export of your entry C++ module is a function that returns a promise. This function takes as its one parameter an object containing imports to the C++ module. You can import C++ from JavaScript or TypeScript files like this:

./app.js

import addModuleInit from './add.cpp';

runCPP();

async function runCPP() {
  const addModule = await addModuleInit();

  console.log(addModule.add(5, 5));
}

./add.cpp

extern "C" {
  int add(int x, int y) {
    return x + y;
  }
}

WebAssembly Text Format (Wat)

Wat is a textual representation of the Wasm binary format. It allows Wasm to be more easily written by hand. Learn more here.

Importing Wat is nearly identical to importing JavaScript or TypeScript. The key difference is that the default export of your entry Wat module is a function that returns a promise. This function takes as its one parameter an object containing imports to the Wat module. You can import Wat from JavaScript or TypeScript files like this:

./app.js

import addModuleInit from './add.wat';

runWat();

async function runWat() {
  const addModule = await addModuleInit();

  console.log(addModule.add(5, 5));
}

./add.wat

(module
  (func $add (param $x i32) (param $y i32) (result i32)
    (i32.add (get_local $x) (get_local $y))
  )
  (export "add" (func $add))
)

WebAssembly (Wasm)

Wasm is a binary instruction format built to be efficient, safe, portable, and open. Learn more here.

Importing Wasm is nearly identical to importing JavaScript or TypeScript. The key difference is that the default export of your entry Wasm module is a function that returns a promise. This function takes as its one parameter an object containing imports to the Wasm module. You can import Wasm from JavaScript or TypeScript files like this:

./app.js

import addModuleInit from './add.wasm';

runWasm();

async function runWasm() {
  const addModule = await addModuleInit();

  console.log(addModule.add(5, 5));
}

./add.wasm

Imagine this is a compiled Wasm binary file with a function called `add`

Command Line Options

Port

Specify the server's port:

--port [port]

Build Static

Create a static build of the current working directory. The output will be in a directory called dist in the current working directory:

--build-static

Exclude

A comma-separated list of paths, relative to the current directory, to exclude from the static build:

--exclude [exclude]

Include

A comma-separated list of paths, relative to the current directory, to include in the static build

--include [include]

SPA Root

A path to a file, relative to the current directory, to serve as the SPA root. It will be returned for the root path and when a file cannot be found:

--spa-root [spaRoot]

Disable SPA

Disable the SPA redirect to index.html:

--disable-spa

Headers File

A path to a JSON file, relative to the current directory, for custom HTTP headers:

--headers-file [headersFile]

Custom HTTP headers are specified as a JSON object with the following shape:

type CustomHTTPHeaders = {
    [regexp: string]: HTTPHeaders;
}

type HTTPHeaders = {
    [key: string]: string;
}

For example:

./headers.json

{
  "^service-worker.ts$": {
    "Service-Worker-Allowed": "/"
  }
}

TSC Options File

A path to a JSON file, relative to the current directory, for tsc compiler options:

--tsc-options-file [tscOptionsFile]

The available options can be found here. Options are specified as a JSON object. For example:

tsc-options.json:

{
  "target": "ES5"
}

ASC Options File

A path to a JSON file, relative to the current directory, for asc compiler options:

--asc-options-file [ascOptionsFile]

By default, no compiler options have been set. The available options can be found here. Options are specified as an array of option names and values. For example:

./asc-options.json:

[
  "--optimizeLevel", "3",
  "--runtime", "none",
  "--shrinkLevel", "2"
]

Special Considerations

Third-party Packages

Third-party packages must be authored as if they were using Zwitterion. Essentially this means they should be authored in standard JavaScript or TypeScript, and AssemblyScript, Rust, C, and C++ must be authored according to their WebAssembly documentation. Notable exceptions will be explained in this documentation. CommonJS (the require syntax), JSON, HTML, or CSS ES Module imports, and other non-standard features that bundlers commonly support are not suppored in source code.

Root File

It's important to note that Zwitterion assumes that the root file (the file found at /) of your web application is always an index.html file.

ES Module script elements

Zwitterion depends on native browser support for ES modules (import/export syntax). You must add the type="module" attribute to script elements that reference modules, for example:

<script type="module" src="amazing-module.ts"></script>

Performance

It's important to note that Zwitterion does not bundle files nor engage in tree shaking. This may impact the performance of your application. HTTP2 and ES modules may help with performance, but at this point in time signs tend to point toward worse performance. Zwitterion has plans to improve performance by automatically generating HTTP2 server push information from the static build, and looking into tree shaking, but it is unclear what affect this will have. Stay tuned for more information about performance as Zwitterion matures.

With all of the above being said, the performance implications are unclear. Measure for yourself.

Read the following for more information on bundling versus not bundling with HTTP2:

Under the Hood

Zwitterion is simple. It is more or less a static file server, but it rewrites requested files in memory as necessary to return to the client. For example, if a TypeScript file is requested from the client, Zwitterion will retrieve the text of the file, compile it to JavaScript, and then return the compiled text to the client. The same thing is done for JavaScript files. In fact, nearly the same process will be used for any file extension that we want to support in the future. For example, in the future, if a C file is requested it will be read into memory, the text will be compiled to WebAssembly, and the WebAssembly will be returned to the client. All of this compilation is done server-side and hidden from the user. To the user, it's just a static file server.