1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
|
# esdev
Incredibly fast ECMAScript & TypeScript bundler designed for development.
## Motivation
JavaScript bundlers run very slow in web browsers.
## Purpose
The purpose of esdev is to very quickly convert ECMAScript/TypeScript into something a web browser can execute.
Goals:
- Transpile fast inside a web browser. "Fast" is defined as "<= 3ms per un-minified file up to 1000 LOC" without build caching (FS cache yes).
- Transpile JSX to ECMAScript
- Remove TypeScript annotations
- Conditionally support React Fast Refresh
- Rewrite CommonJS/SystemJS/UMD imports and exports to ESM
- Support most of tsconfig.json/jsconfig.json
- Support `defines` like in esbuild
- Support esbuild plugins
- Support importing CSS files from JavaScript
Non-goals:
- Bundling for production
- Tree-shaking
- Minification
- AST plugins
- Support Node.js
- CommonJS, UMD, IIFE
- ES6 to ES5
- Supporting non-recent versions of Chromium, Firefox, or Safari. (No IE)
## How it works
Much of the code is a line-for-line port of esbuild to Zig, with a few important differences.
### Implementation differences
#### Moar lookup tables
### Why not just use esbuild?
#### Missing features
- Hot Module Reloading
- Rewrite CommonJS/SystemJS/UMD imports and exports to ESM
- React Fast Refresh
#### Go WASM performance isn't great.
There's a number of reasons for this:
- Unlike native targets, Go's WASM target runs the garbage collector on the same thread as the application. Since this usecase is very constrained (no need for shared memory, or long-term objects), rewriting in Zig lets us get away with a bump allocator -- skipping garbage collection entirely. This is faster than what Go does and possibly Rust, since this zeroes out the heap in one call at the end, rather than progressively zeroing memory.
- Goroutines cross the JS<>WASM binding, which is very slow. The more goroutines you use, the slower your code runs. When building a Zig project in single-threaded mode, Zig's `comptime` feature compiles away most of the difference.
- Slow startup time: unless you use TinyGo, Go WASM binaries are > 2 MB. In esbuild's case, at the time of writing its 6 MB. That's a lot of code for the web browser to download & compile.
#### Different constraints enable performance improvements
If bundler means "merge N source files into 1 or few source file(s)", esdev is most definitely not a bundler. Unlike most bundlers today, esdev deliberately outputs
If bundler means "turn my development code into something a browser can run",
### Compatibility Table
Key:
| Feature | esbuild | esdev |
| ---------------------------------- | ------- | ----- |
| Minification | ✅ | ❌ |
| JSX (transform) | ✅ | ⌛ |
| TypeScript (transform) | ✅ | ⌛ |
| Hot Module Reloading | ❌[1] | ⌛ |
| React Fast Refresh | ❌[1] | ⌛ |
| Tree Shaking | ✅ | ⌛ |
| Incremental builds | ✅ | ⌛ |
| CSS | ✅ | 🗓️ |
| Support older browsers | ✅ | ❌[2] |
| Plugins | ✅ | ⌛[3] |
| AST Plugins | ❌ | ❌[4] |
| Filesystem Cache API (for plugins) | ❓ | 🗓️[4] |
Key:
|Tag | Meaning
|----|----------------------------------------------|
| ✅ | "compatible" |
| ❌ | "not supported, and no plans to change that" |
| ⌛ | "in-progress" |
| 🗓️ | "planned" or "eventually but work has not started" |
| ❓ | "unknown" |
Citations:
[1]:
|
