> One of the key ideas with Ezno is that it attempts "maximum" knowledge of a source<p>I've been working on a new TypeScript-like language myself from scratch, which among other things takes this approach. Mine can do some of the numeric stuff shown here, but I'm jealous of (inspired by? :)) some of the crazier stuff going on here, like usage-based argument types and tracing not just value <i>shapes</i> but value <i>reference identities</i><p>The "automatic generics" feature in particular is absolutely bonkers. It never even occurred to me that you could do that. I'm wondering if there are unforeseen edge-cases, but also wishing I had it at work. Clunky generics syntax is one of the worst parts of TypeScript, even while generic function types are one of its best parts.<p>Wow, and side-effects-tracking too! Amazing<p>I am curious whether some of these checks will be limited by JavaScript's dynamism. Part of why I'm doing mine as a new language is that JavaScript's semantics are just way too flexible to form some of the guarantees I feel like you need for some of this aggressive inference. But now I'm questioning that.<p>Either way, this is insanely impressive. Definitely not just yet-another-JavaScript-toolchian.
As a programming language geek, TypeScript is one of the best things to ever happen to the industry. It's finally dispelled the notion that "types == Java == bad/annoying", and shown how powerful and convenient a type system can actually be.<p>(This is something that's been possible for decades, but it never hit mainstream before as it's hard to implement it well enough to satisfy the silly preferences of us typical programmers :)).
> Ezno's type checker is built from scratch. Getting the features I wanted requires a lot of different functionality and needed several new ideas that as far as I know aren't present in any type-system or existing checkers.<p>I would disagree this is a <i>TypeScript</i> compiler. It's a mostly-typescript-compatible compiler/type-checker.<p>The Typescript team iterate on it reasonably quickly. If you fall behind as the Typescript team adds new features, and you cannot check that code, is it still "Typescript"?
What I'd really like is a tsc that creates code to check types at runtime, like for API boundaries and parsing unknown input. Kind of like a built-in Zod. Maybe it's just an automatic type guard anywhere you have an "as SomeType" or an ignore directive.
Wow, this is seriously impressive work, if it really works as well as the code examples make it seem. Many of these ideas I have not seen in other JS typecheckers:<p>- Inferred generics that work<p>- Effect tracking<p>- Prepack-style AOT evaluation, but for typechecking<p>- JSX built in, with proper inference<p>- Using a typechecker to reduce the amount of work React needs to do (!!!)<p>- Using a typechecker to make SSR more efficient<p>- …<p>These are super interesting and very novel. I hope to see this open sourced soon —- curious if this kind of approach will work at scale.
All of these compiler/transpiler related projects, especially for big mainstream language like TypeScript seems like a full time job, more so than any other open source initiatives. You need to keep up with the spec, constantly read the source codes, etc. Kudos to those who are providing their time to do this.
Remind me of Hegel (<a href="https://hegel.js.org/" rel="nofollow">https://hegel.js.org/</a>) but with typescript compatibility. It's a pity Hegel develompent stopped because war in Ukraine (<a href="https://github.com/JSMonk/hegel/issues/363" rel="nofollow">https://github.com/JSMonk/hegel/issues/363</a>). Looks really cool but in my opinion would better to concetrate on type checking living other things (vdom, ssr) out or in optional plugins
No one’s looking at Static Hermes?<p><a href="https://github.com/facebook/hermes/commits/static_h" rel="nofollow">https://github.com/facebook/hermes/commits/static_h</a>
Typescript is great, for team collaboration, code refactor, etc, but I don't think every project should use it, sometimes javascript is much easier and faster to implement.
> VDOM is a virtual representation of the document, actual DOM references the document (e.g. .click() isn't on VDOM structures).<p>This sentence is unreadable. The superfluous/incorrect use of parens for `.click()`, in combination with this page's style sheet and the way that paragraph wrapped in my browser are all things that didn't help, but eventually I was able to move past it. (It still doesn't make any sense, but I know that part isn't where the weirdness is.) Still unreadable. Bad for something pulled from a written work that's supposed to be a list of definitions you reference.