from Hacker News

Show HN: Ezno, a type checker for JavaScript and optimiser for React

by kaleidawave on 9/22/22, 4:58 PM with 98 comments

  • by brundolf on 9/23/22, 4:26 PM

    > One of the key ideas with Ezno is that it attempts "maximum" knowledge of a source

    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 shapes but value reference identities

    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.

    Wow, and side-effects-tracking too! Amazing

    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.

    Either way, this is insanely impressive. Definitely not just yet-another-JavaScript-toolchian.

  • by simplify on 9/23/22, 8:06 PM

    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.

    (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 :)).

  • by madeofpalk on 9/23/22, 4:24 PM

    > 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.

    I would disagree this is a TypeScript compiler. It's a mostly-typescript-compatible compiler/type-checker.

    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"?

  • by nilsbunger on 9/23/22, 4:36 PM

    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.

  • by bcherny on 9/24/22, 2:28 AM

    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:

    - Inferred generics that work

    - Effect tracking

    - Prepack-style AOT evaluation, but for typechecking

    - JSX built in, with proper inference

    - Using a typechecker to reduce the amount of work React needs to do (!!!)

    - Using a typechecker to make SSR more efficient

    - …

    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.

  • by bin_bash on 9/23/22, 3:55 PM

    anyone else think it's really strange this is "Ezno" and not "Enzo"?

  • by immigrantheart on 9/23/22, 4:30 PM

    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.

  • by fbn79 on 9/23/22, 3:55 PM

    Remind me of Hegel (https://hegel.js.org/) but with typescript compatibility. It's a pity Hegel develompent stopped because war in Ukraine (https://github.com/JSMonk/hegel/issues/363). Looks really cool but in my opinion would better to concetrate on type checking living other things (vdom, ssr) out or in optional plugins

  • by juancampa on 9/23/22, 3:42 PM

    On a related note: Is there anyone working on a faster tsc? I know there's esbuild and swc, but those only transpile, they don't type-check.

  • by mrpf1ster on 9/23/22, 6:41 PM

    This looks incredible, looking forward to an official release to play around with!

  • by bryzaguy on 9/23/22, 5:13 PM

    Wow! Amazing! Am I reading correctly that Ezno is aiming to render React obsolete?

  • by zer0zzz on 9/23/22, 11:05 PM

    No one’s looking at Static Hermes?

    https://github.com/facebook/hermes/commits/static_h

  • by ghasemi on 9/24/22, 9:44 AM

    Ezno is a city in Iran :D

  • by shanghaikid on 9/24/22, 1:37 AM

    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.

  • by z3t4 on 9/23/22, 11:15 PM

    So how do I use this ?

    I think 90% of JS types can be inferred statically...

  • by nexxel on 9/23/22, 4:02 PM

    Looks really cool!

  • by pwdisswordfish9 on 9/23/22, 10:11 PM

    > VDOM is a virtual representation of the document, actual DOM references the document (e.g. .click() isn't on VDOM structures).

    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.