constexpr

This is a very good talk but I wonder if this alternate compiler design has actually made the TypeScript compiler slower in normal compilation mode. If you really do "helicopter in" to every point in the syntax tree and run IDE queries to implement type checking then that could potentially be much slower if there's any overhead at all to doing that.

I've been experimenting with programming languages and compilers myself (https://github.com/evanw/skew) and my compiler appears to be ~2x faster than tsc when run with node even though it's also doing constant folding, tree shaking, inlining, and minification while tsc is just removing type annotations (my compiler appears to be ~15x faster when run natively). The slow compilation speed of tsc is my main complaint about the TypeScript ecosystem.

I'm the cofounder of Figma (www.figma.com), a startup in San Francisco building a browser-based collaborative design tool to improve the way designers and engineers work together. We're a small team of 14, and we're looking for talented designers and engineers (www.figma.com/careers) who are interested in tackling challenges in the creative tools space.

Example challenges: annotation system on top of documents for feedback, 2D boolean operations on paths, speed up zooming in the app using a tile quadtree, UI testing framework that simulates user actions, real-time events and data pushing across the site, zero-downtime deployments, search API for filtering user files.

Our tech stack: C++, Emscripten, Node, CoffeeScript, JavaScript, WebGL, Ruby, Sinatra

If you're interested in learning more about what we're working on or want to meet up to talk about any of my other projects (http://madebyevan.com/), you can email me at wallace@figma.com.

This approach uses much less memory, gives a render that is exact instead of approximate (it doesn't suffer from corner clipping or grid resolution issues as you zoom in), and is quicker to do an initial render because there's no CPU-side preprocessing involved. I haven't profiled both techniques side-by-side though so I'm not sure which technique is ultimately faster.

San Francisco; Full Time; Onsite

I'm the cofounder of Figma (www.figma.com), a startup in San Francisco building a browser-based collaborative design tool to improve the way designers and engineers work together. We're a small team of 16, and we're looking for talented designers and engineers (www.figma.com/careers) who are interested in tackling challenges in the creative tools space.

Example challenges: annotation system on top of documents for feedback, 2D boolean operations on paths, speed up zooming in the app using a tile quadtree, UI testing framework that simulates user actions, simultaneous multi-user editing, zero-downtime deployments, search API for filtering user files.

Our tech stack: C++, Emscripten, Node, CoffeeScript, JavaScript, WebGL, Ruby, Sinatra

If you're interested in learning more about what we're working on or want to meet up to talk about any of my other projects (http://madebyevan.com/), you can email me at wallace@figma.com.

Right now the only implicit conversions are null to nullable types and smaller integers to larger ones. There is no "===" right now and "==" requires equal types. I may consider aligning this more with JavaScript in the future. There's a live compiler demo at http://evanw.github.io/thinscript/ where you can try out all of this yourself :)

There is no "any" type since ThinScript is an ahead-of-time compiled language and emulating dynamic types is a non-goal. Types are required and omitting them is a syntax error. Right now "let" is an alias for "var" and "var" behaves like "let".

Yes. As the parent comment said, you could try to to choose a subset of TypeScript that's relatively efficient to help avoid some of the issues with JavaScript. The problem is that the TypeScript language itself lacks certain primitives required for efficient ahead-of-time compiled code (integers, for example).

I don't consider the design of TypeScript a weakness at all. TypeScript is really well designed and is great at what it does. The type system they came up with is pretty optimal for modeling real-world JavaScript code. But the tuning they did around the JavaScript ecosystem means it's not a great language to use for generating efficient native code. I started ThinScript in part for exactly that reason. I want good tooling and rapid prototyping, just for native development instead of web development. That requires a different set of trade-offs and design decisions.

I'm not planning on supporting return type inference since I actually don't like that feature of TypeScript, but I could be convinced otherwise. It really harmed API readability for me when I tried to use it.

All declarations in ThinScript are order-independent right now so classes are accessible everywhere simultaneously. I'm getting away with that because I'm currently requiring all global initializers to be constant. One idea I had that would allow for non-constant global initializers without really complex static analysis to determine initialization order was to initialize non-constant global variables on first access instead of on startup.

I chose "int" because I was aiming for familiarity with existing languages. I'm also planning for WebAssembly to be just one target among many targets so I don't want to align too closely with WebAssembly. Some other targets I'm considering are C, x86, Swift, and C#, for example.

I considered that but I'm worried that won't work with WebAssembly because it's a more memory-constrained environment. Your app may generate a ton of data in a frame and run off the end of the address space. I guess I'm probably just thinking back to asm.js where you sometimes only have 256mb to work with. I'll try this first at least since it makes stuff easier.

I'm planning on experimenting with either pure reference counting (Swift), reference counting + cycle collection (Python), or garbage collection. I'd love to hear about what people are doing for emscripten actually. I've read that Unity uses IL2CPP which uses the Boehm GC but I couldn't find anywhere that described how that actually works in emscripten. Local variables correspond to "registers" in machine code, but how does the garbage collector read them so it can scan them during a collection?

I plan to do it eventually. I've implemented generics before so that's not the issue. It's just hard to get the design of generics right when the compiler has multiple targets. You want to emit compact JavaScript code and at the same time support the generation of efficient machine code. C++ does generic code through template expansion but that ends up generating a ton of code, which is bad for code delivered in a network environment. It may make sense to make different tradeoffs given the context of this project. I'm planning on putting off generics for a while though until more pieces fall into place.

Yes. TypeScript doesn't have a sound type system and it comes with a lot of baggage:

* Using hashtables in TypeScript relies on the representation of JavaScript objects with strings as properties. Emulating JavaScript's in-memory representation in an ahead-of-time compiled language isn't a good idea for performance reasons.

* TypeScript only has a single number type (double) which is pretty slow if you actually need to work with integers. JavaScript VMs do a lot of work to figure out which numbers are integers using information that's only available at runtime. Using explicit integer types means the generated code is a lot tighter.

* A lot of existing TypeScript code uses structural typing to model dynamic type contracts present in today's JavaScript code, but this is usually a loosely-typed approximation and not something that a compiler can rely on. It's more just to improve tooling for developers.

* TypeScript uses exceptions which are hard to emulate efficiently in native code.

* I want to be able to add certain things and extend the language, so I don't want to limit myself to TypeScript. For example, I'm considering a preprocessor for conditional compilation and something similar to C#'s unsafe syntax for pointer manipulation.

Yes! I considered this and it's an interesting idea. ThinScript may end up being pretty opinionated about memory allocation though (I'm not sure yet if I'm doing pure reference counting, pure garbage collection, or some combination of both) so it could be a useful higher-level target language.

Oh wow I did not expect this to be up here this soon. Warning: two-week-old project. I've got a lot of plans for this but it'll take at least a few months for this to be anywhere near useful. Right now it's just an experiment!

> Displaying a JavaScript dialog—alert, confirm, or prompt—no longer activates the calling tab.

This seems like a regression to me. If some page is bugging me then I'd like to know which one it is so I can close it.

I currently write compilers that target JavaScript and have looked a TypeScript a lot for something like this. In practice, TypeScript isn't actually strictly typed. There is a ton of TypeScript code out there that does stuff like run-time prototype manipulation (mixins, for example), using arbitrary objects as hash tables, and liberal use of the "any" type.

So either you cross-compile a JavaScript VM to be able to handle everything (super slow and bloated, especially without the ability to JIT compile executable code) or you pick a small subset of TypeScript to compile, in which case it wouldn't really be TypeScript at all.

Plus TypeScript doesn't have integer types (only doubles) so it would generate pretty inefficient code. JavaScript JITs do a lot of work to turn usage of doubles into integers based on run-time behavior that is unknowable at compile-time.

San Francisco; Full Time; Onsite

I'm the cofounder of Figma (www.figma.com), a startup in San Francisco building a browser-based collaborative design tool to improve the way designers and engineers work together. We're a small team of 17, and we're looking for talented engineers (www.figma.com/careers) who are interested in tackling challenges in the creative tools space.

Example challenges: annotation system on top of documents for feedback, 2D boolean operations on paths, speed up zooming in the app using a tile quadtree, UI testing framework that simulates user actions, real-time events and data pushing across the site, zero-downtime deployments, search API for filtering user files.

Our tech stack: C++, Emscripten, Node, CoffeeScript, JavaScript, WebGL, Ruby, Sinatra

If you're interested in learning more about what we're working on or want to meet up to talk about any of my other projects (http://madebyevan.com/), you can email me at wallace@figma.com.

I don't know much about the project but I have a lot of experience with asm.js. Using asm.js has many drawbacks and should only be used if the tradeoffs are acceptable. Some of the large issues:

- A bad debugging experience (no segfaults on null, local variables are numbers instead of strings or objects, function pointer calls are super confusing)

- Much more difficult to interoperate with external JavaScript libraries

- Massive code bloat (you have to reinvent everything like arrays, strings, maps, regexes, memory management, etc. instead of just using the browser's built-in implementations)

Meshes are closer but vector networks also attach specific attributes to edges which is not usually the case with meshes. Examples: control handles (for curves), stroke weight, dash pattern.

Figma is not just a UI mocking tool. It's a full general-purpose vector graphics editor. Vector networks work similar to meshes in 3D.

Figma is not just a UI mocking tool. It's a general-purpose drawing tool and is feature-equivalent with Sketch.

Graphs have a set of vertices and a set of edges, but vector networks also have a set of faces.

San Francisco; Full Time; Onsite

I'm the cofounder of Figma (www.figma.com), a startup in San Francisco building a browser-based collaborative design tool to improve the way designers and engineers work together. We're a small team of 17, and we're looking for talented designers and engineers (www.figma.com/careers) who are interested in tackling challenges in the creative tools space.

Example challenges: annotation system on top of documents for feedback, 2D boolean operations on paths, speed up zooming in the app using a tile quadtree, UI testing framework that simulates user actions, real-time events and data pushing across the site, zero-downtime deployments, search API for filtering user files.

Our tech stack: C++, Emscripten, Node, CoffeeScript, JavaScript, WebGL, Ruby, Sinatra

If you're interested in learning more about what we're working on or want to meet up to talk about any of my other projects (http://madebyevan.com/), you can email me at wallace@figma.com.

> Threads won't be able to share FBO's or VBO's, but we're working on SharredArrayBuffer, which will allow multiple threads to share data (more like C style arrays than JS style lists, they still would have to be glBufferData'd to VRAM from RAM).

It would be amazing to have fast GPU-GPU transfer. Is it the case in Firefox that using texImage2D/texSubImage2D on a main thread context with a worker <canvas> will result in a guaranteed GPU-GPU transfer? Or does that download the pixels to the CPU and re-upload them?

> Isn't that the case for all applications?

Yes, but I haven't been following GPU tech recently so I wasn't sure if that still applies universally. Maybe some day we'll get preemptive multitasking on GPUs :)

This sounds pretty great.

This technique would be really powerful if the worker thread could pass a buffer of the rendered results off to the main thread efficiently for use by the main thread. For example, a game has a worker thread to refine lightmaps while the main thread uses those lightmaps for rendering the game (similar to http://madebyevan.com/shaders/lightmap/). Does anyone know if this is possible?

Also, what does this mean for GPU use on the worker? Can heavy GPU use in the worker still lock up the GPU and impact the GPU use of the main thread and the windowing system in the OS?

We're using Xcode instead of Visual Studio but that's essentially our process. Right now we're focusing our effort on getting the product right on the web first so native is currently on the back burner. A native version will definitely be a good option later on for power users.

People normally associate WebGL with 3D game content, but it's for 2D too! I decided to build our own GPU rendering pipeline for the performance and document size benefits you mentioned and also so we can guarantee top-quality, consistent rendering across platforms. A GPU rendering pipeline is actually a pretty normal technology choice for a cross-platform desktop app. It hasn't been too hard to find people with that expertise to work on the editor. We're looking at people with game development or browser development backgrounds.

The biggest pain points when using emscripten are debugging, compilation time, and code size. Debugging means poking through what is the JavaScript equivalent of assembly code but without a debugger that understands it (no segfaults on null access, strings are just numbers, etc.). The emscripten toolchain doesn't include an incremental linker yet and compilation time is limited by C++'s dumb compilation model. C++ also generates a lot of code if you use the standard library and templates (this is C++'s fault, not emscripten). In practice, we have an Xcode project hooked up to build the same C++ code and use that as our IDE. That way we can mostly treat emscripten as just a build target. I would only do it if it's worth the tradeoff.

San Francisco; Full Time; Onsite

I'm the cofounder of Figma, a startup in San Francisco building a browser-based collaborative design tool to improve the way designers and engineers work together. We're a small team of 15, and we're looking for talented designers and engineers (front end, backend, full stack, lead devops, mobile, and data science) who are interested in tackling challenges in the creative tools space.

Example challenges: annotation system on top of documents for feedback, 2D boolean operations on paths, speed up zooming in the app using a tile quadtree, UI testing framework that simulates user actions, real-time events and data pushing across the site, zero-downtime deployments, search API for filtering user files.

Our tech stack: C++, Emscripten, Node, CoffeeScript, JavaScript, WebGL, Ruby, Sinatra

If you're interested in learning more about what we're working on or want to meet up to talk about any of my other projects (http://madebyevan.com/), you can email me at wallace@figma.com.