## 1. Project Overview & Quickstart (JimmyLv/deploy-ch) # deploy-ch Open-source repository JimmyLv/deploy-ch ### Repository Details - **Repository:** [JimmyLv/deploy-ch](https://github.com/JimmyLv/deploy-ch) - **Primary Language:** Code *Note: High-volume repository documentation is actively indexed and synchronized by YakaAI.* ## 2. Official Technical Reference & Guides (JimmyLv/docs) ## File: README.md --- --- # Introduction AssemblyScript compiles a **strict subset** of [TypeScript](https://www.typescriptlang.org) \(a typed superset of JavaScript\) to [WebAssembly](https://webassembly.org) using [Binaryen](https://github.com/WebAssembly/binaryen), looking like: {% code-tabs %} {% code-tabs-item title="fib.ts" %} ```typescript export function fib(n: i32): i32 { var a = 0, b = 1; for (let i = 0; i < n; i++) { let t = a + b; a = b; b = t; } return b; } ``` {% endcode-tabs-item %} {% endcode-tabs %} ```text $> asc fib.ts -b fib.wasm -O3 ``` Its architecture differs from a JavaScript VM in that it compiles a program **ahead of time**, quite similar to other static compilers. On top of [WebAssembly types](basics/types.md), it provides both [low-level built-ins](basics/environment.md#low-level-webassembly-operations) to access WebAssembly features directly as well as a JavaScript-like [standard library](basics/environment.md#standard-library) on top of a relatively small [managed runtime](details/runtime.md) enabling the creation of programs that look and feel much like TypeScript. For example, on the lowest level, memory can be accessed using the `load(offset)` and `store(offset, value)` built-ins that compile to WebAssembly instructions directly ```typescript store(8, load(0) + load(4)); ``` while the standard library provides implementations of `ArrayBuffer` , `Uint8Array` , `String` , `Map` etc. on a higher level: ```typescript var view = new Int32Array(12); view[2] = view[0] + view[1]; ``` The compiler still has its limitations and we are still waiting for WebAssembly features that are currently undergoing specification \(marked as 🦄 throughout the documentation\) to unleash its full potential. But it is open source and everyone can contribute, so we are getting there. Sounds appealing to you? Read on! --- ## File: details/README.md --- All the dirty details. Options, APIs, memory layouts and the ins and outs of caring for an AssemblyScript module. --- # The Details --- ## File: basics/README.md --- --- # The Basics Unlike TypeScript, which targets a JavaScript environment with all of its dynamic features, AssemblyScript targets WebAssembly, and intentionally **avoids the dynamicness of JavaScript** where it cannot be compiled ahead of time _efficiently_. The first thing one is going to notice is that AssemblyScript's [type system](types.md) differs from TypeScript's in that it uses WebAssembly's **more specific integer and floating point types**, with `number` merely an alias of `f64`. These types are enough to implement other numerical types and higher level structures like strings and arrays as provided by the [standard library](environment.md#standard-library), yet the relevant specifications \(like [reference types](https://github.com/WebAssembly/reference-types) and [GC](https://github.com/WebAssembly/gc)\) to describe higher level structures to JavaScript are not yet available. This means that **objects cannot yet flow in and out of WebAssembly natively**, making it necessary to read/write them from/to memory. To make this process more convenient, [the loader](loader.md) provides the utility necessary to translate between the WebAssembly and the JavaScript world. It must also be noted that WebAssembly has **no immediate access to the DOM** or other JavaScript APIs currently, sometimes making it necessary to create some custom glue code by means of [exports and imports](exports-and-imports.md) to/from JavaScript. Combined, this makes it **unlikely that existing TypeScript code can be compiled** to WebAssembly without modifications, yet likely that already **reasonably strict TypeScript code can be made compatible** with the AssemblyScript compiler. But what does this mean _exactly_? Well, let there be... ## Differences For a better understanding of what to expect, let's start with a collection of obviously "not so strictly typed" code snippets, and how to fix them. ### Strict typing There is no `any` or `undefined` for obvious reasons: ```typescript // 😢 function foo(a?) { var b = a + 1; return b; } // 😊 function foo(a: i32 = 0): i32 { var b = a + 1; return b; } ``` There are no union types: ```typescript // 😢 function foo(a: i32 | string): void { } // 😊 function foo(a: T): void { } ``` Objects must be strictly typed as well: ```typescript // 😢 var a = {}; a.prop = "hello world"; // 😊 var a = new Map(); a.set("prop", "hello world"); // 😊 class A { constructor(public prop: string) {} } var a = new A("hello. world"); ``` ### The case of === Also, AssemblyScript does some things differently. It uses `===` for identity comparisons \(means: the exact same object\) for example. Idea is that its special JavaScript semantics for strings \(same type and value\) become irrelevant in a strict type context anyway. Some like this better, some hate it for portability reasons. ```typescript var s1 = "1"; var s2 = "123".substring(0, 1); s1 === s1 // true s1 === s2 // false s2 === s2 // true s1 === 1 // compile error s1 == s2 // true ``` For all other types than `string` and operator-overloaded objects with a `==` overload, `===` is equivalent to `==`. ```typescript 1 === 1 // true 1 == 1 // true obj === obj // true obj == obj // true if there is no == overload doing something different ``` ### And the kitchen sink The examples above mainly exist so one can get an initial idea, but there is of course more, as explained on the following pages, to consider.