"Ectype - bringing type safety (and more!) to vanilla JavaScript" by Holly Wu (Strange Loop 2023)

More than a library but not quite a language, Ectype showcases a novel approach to web languages: rather than creating a completely new syntax and transforming that code into JavaScript, Ectype reshapes JavaScript itself into a cleaner, more deliberate language.
Ectype uses a novel pairing of a library and type-checker that work in tandem to bring new language features like static type-safety, runtime type introspection, and more, directly to vanilla JavaScript. Declare types and validate foreign data, all from the familiar syntax of JavaScript, backed by the guarantees of static type-checking.
At the same time, Ectype allows JavaScript to be a scripting language again: because files written with Ectype are all valid JavaScript, they can be immediately run in Node, Deno, Bun, the browser, and anywhere else JavaScript will run - all without needing to be compiled or bundled first.
Holly Wu
Recreational Language Enthusiast
Holly has been doing full-stack web dev in one form or another for over a decade, but it wasn’t until 2017 that she got bit by the programming language design bug and disappeared down the rabbit hole of trying to make JavaScript better. She emerges from that rabbit hole before you now, covered in peculiar flowers and luminous fungi, to present to you the discoveries from her journey.
----
Recorded Sept 22, 2023 at Strange Loop 2023 in St. Louis, MO.
thestrangeloop.com

[@xananax6823]

Absolutely amazing, kudos. Seems so evident in retrospect, but it takes someone with granular sensibility to think about it. Additionally to the idea being very good, I love the API.

[@garthgoldwater5256]

This is such an incredible idea! I’m all for it!

[@thaisrobba6449]

Loved it! For a lot of things I can see how this would be very useful, great talk!

[@christophebenz]

Wonderful, I especially love the generics implemented via functions on types. Like Zig which I discovered recently!

[@alurma]

Very cool approach!

[@mast1999]

This is genius.
So simple... yet genius...
Love it.

[@AustinMarlar]

Cool talk/idea. I would point out one issue with the zod slide.
In 99% of cases, you only need to define the schema and then infer the type. There is no need to have both a schema and type in most cases (at least, from my exp)
const coolStringSchema = z.string();
type CoolString = z.infer;
// It's also possible to use specifically the "input" or "output" version of
// the schema in the case of transforms
type CoolStringIn = z.input;
type CoolStringOut = z.output; // default of z.infer

[@JeffHeon]

Excellent talk!

[@SrdjanStrbanovicHome]

just watched again, the elegance of simplicity strikes hard. kudos!
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.
Tony Hoare"
hopefully, you get support to continue this work...

[@NamanGoel34]

A more production ready version of this idea is:
Flow + Flowtate comments.
No new syntax. Just comments for annotations.
The type checker runs as a server, just like a “linter”.
No runtime cost.
var x/*: int */ = 5;
function add(a/*: number */, b/*: number */)/*: number */ {
return a + b;
}

[@Tony-dp1rl]

So much work on type-safe JS, but I doubt type-safety issues have cost me a day's work in the last 5 years total without any type checking. Who are these developers with type-safety issues and what the hell are they writing? :)

[@TankorSmash]

I run into undefineds just about every debugging session I run into, I'm impressed you don't!

[@blundettoad]

In large codebases, types are documentation. Even sans the type safety, they are invaluable for developer productivity. This effect would be less pronounced in small codebases.

[@cold_ultra]

What kind of software are you building? I work on a large react codebase with multiple other teams and not having types there is simply not a option

[@nijolas.wilson]

Well said! Well written, well tested code does not require types. Big or small team. Big or small software. I don't understand the desperate need for types - almost feels like an addiction. Tests are much better at keeping you safe, types just slow you down and give you a false sense of security. If you test your code you don't need types.

[@theguatemalian]

@@nijolas.wilson You don't need as many tests or runtime type checks when you have types. You're essentially putting the cognitive load on the developer instead of the type system to ensure all those checks pass. This is how you end up with 3-4:1 test:application code. Types can easily cut a test suite in half and remove most runtime checks from functions. I don't know about you but I enjoy writing application code a lot more than writing hundreds of unnecessary tests.