Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Zero-codegen, no-compile TypeScript type inference from Protobufs

github.com

Post reply on HN
Print view View original

31–40 of 80 posts

Re: Show HN: Zero-codegen, no-compile TypeScript type inference from Protobufs

#31

Post by mubou »

spankalee wrote: post #28
mubou wrote: post #4

The fact that the source is so small is wild. I would have expected a huge convoluted parsing library implemented in types. On the other hand, the fact that this is even possible is more wild. Instead of replacing JS with a proper statically-typed language, we're spending all this effort turning a preprocessor's type system into a turing-complete metalanguage. Pretty soon we'll be able to compile TypeScript entirely…

TypeScript does an amazing job at describing the types of real-world JavaScript. It's incredibly good, and very useful, even in the face of extremely dynamic programs. The fact that it can describe transforms of types, like "this is a utility that adds an `xxx` prefix to every property name" is frankly unparalleled in mainstream languages, but more importantly lets us describe patterns that come up in real-world JS p…

I don't disagree! It's just the fact that it has to be transpiled to JS that's the problem, because it means none of the types are "real"; there's no runtime assurance that a string is actually a string. TS is great and I'd never go back to JS, but it's ultimately a bandaid. Native TS support in browsers is probably never going to happen, though, sadly.

Imagine if WASM were supported natively instead, with browsers exposing the same DOM interfaces that they do to JS. You could link a wasm binary in a and do everything you can with JS/TS, but with any language of your choosing. No doubt a compiled form of TS would appear immediately. We'd no longer need separate runtime type checking.

Just feels like priorities are in the wrong place.

Re: Show HN: Zero-codegen, no-compile TypeScript type inference from Protobufs

#32

Post by merb »

mubou wrote: post #31
spankalee wrote: post #28

Earlier quoted context omitted.

TypeScript does an amazing job at describing the types of real-world JavaScript. It's incredibly good, and very useful, even in the face of extremely dynamic programs. The fact that it can describe transforms of types, like "this is a utility that adds an `xxx` prefix to every property name" is frankly unparalleled in mainstream languages, but more importantly lets us describe patterns that come up in real-world JS p…

I don't disagree! It's just the fact that it has to be transpiled to JS that's the problem, because it means none of the types are "real"; there's no runtime assurance that a string is actually a string. TS is great and I'd never go back to JS, but it's ultimately a bandaid. Native TS support in browsers is probably never going to happen, though, sadly. Imagine if WASM were supported natively instead, with browsers e…

Wasm gc was needed for that. Wasm evolves slowly so that it can be done right. Even if the dom api comes, not a lot of it will change since only c-like languages will be as small as possible to fit into the space of JavaScript.

Re: Show HN: Zero-codegen, no-compile TypeScript type inference from Protobufs

#33

Post by recursive »

ZitchDog wrote: post #29
recursive wrote: post #14

This requires the whole `.proto` declaration inline in source a string constant. I'm not holding my breath on "Import non-js content"[1] getting approved, so that means you still have to use another build dependency, or manually keep the .proto files synchronized across multiple sources truth. In that light, it's not clear when this would be a benefit over straight-forward code gen. Cool POC hack though. [1]: https:/…

The problem is that TypeScript is terrible at codegen, there are no standard extension points like we have with javac and others. So we are forced to do these crazy hacks at the type level rather than just generating types as you would in other languages.

Not familiar with the capabilities of javac, but in my imagination, I'm referring to a tool that runs prior to the typescript compiler, that just writes the intended source as text. Typescript never knew it wasn't in the repository or anything.

Re: Show HN: Zero-codegen, no-compile TypeScript type inference from Protobufs

#34

Post by spankalee »

mubou wrote: post #31
spankalee wrote: post #28

Earlier quoted context omitted.

TypeScript does an amazing job at describing the types of real-world JavaScript. It's incredibly good, and very useful, even in the face of extremely dynamic programs. The fact that it can describe transforms of types, like "this is a utility that adds an `xxx` prefix to every property name" is frankly unparalleled in mainstream languages, but more importantly lets us describe patterns that come up in real-world JS p…

I don't disagree! It's just the fact that it has to be transpiled to JS that's the problem, because it means none of the types are "real"; there's no runtime assurance that a string is actually a string. TS is great and I'd never go back to JS, but it's ultimately a bandaid. Native TS support in browsers is probably never going to happen, though, sadly. Imagine if WASM were supported natively instead, with browsers e…

I think you're conflating cause and effect in several cases. TypeScript can't be thought of, and would never exist, independently from JavaScript like you're trying to do.

TypeScript wasn't created separate from JavaScript and then chose JavaScript as a backend. TypeScript only exists to perform build-time type checking of JavaScript. There wouldn't be a TypeScript that compiled to something else, because other languages already have their own type systems.

Runtime type-checking isn't part of TypeScript because 1) It isn't part of JavaScript, and TypeScript doesn't add runtime features anymore. 2) It'd be very expensive for simple types, 3) Complex types would be prohibitively expense as you have to both reify the types and perform deep structural checking.

WASM also is natively supported, and with newer extensions like reference types and GC, we're getting closer to the point where a DOM API could be defined. It'll still be a long while, but that's the long-term direction it's heading in. But even then, you would only see a TypeScript-to-WASM compiler[1] because there's already so much TypeScript out there, not because TypeScript is a particularly good language for that environment. A more static language would be a lot better for a WASM target.

[1]: Porfor is already such a compiler for JS and TS, but it does not do runtime type-checking: https://porffor.dev/

Re: Show HN: Zero-codegen, no-compile TypeScript type inference from Protobufs

#36

Post by mherkender »

This is kinda why I hate advanced type systems, they slowly become their own language.

"No compile/no codegen" sounds nice until you get slow compile times because a type system is slow VM, the error messages are so confusing it's hard to tell what's going on, and there's no debugging tools.

Re: Show HN: Zero-codegen, no-compile TypeScript type inference from Protobufs

#37

Post by catapart »

recursive wrote: post #14

This requires the whole `.proto` declaration inline in source a string constant. I'm not holding my breath on "Import non-js content"[1] getting approved, so that means you still have to use another build dependency, or manually keep the .proto files synchronized across multiple sources truth. In that light, it's not clear when this would be a benefit over straight-forward code gen. Cool POC hack though. [1]: https:/…

It's true that it's another dependency, but this is the entire contents of a file I drop into my project root called `raw-loader.d.ts`:

```

declare module '*?raw' { const rawFileContent: string export default rawFileContent }

```

Then, when I add the file to my types property array of my tsconfig's compilerOptions, I can import anything I want into a typescript file as a string, so long as I add "?raw" to the end of it. I use it to inject HTML and CSS into templates. No reason it couldn't be used to inject a .proto file's contents into the inline template.

Again, you're technically correct! But a "import non js content" feature is a pretty solveable problem in TS. Maybe not at the language level, but at the implementation level, at least.

Re: Show HN: Zero-codegen, no-compile TypeScript type inference from Protobufs

#38

Post by jitl »

It’s pretty rad how flexible template literal types are, but I can’t imagine wanting this kind of shenanigans hanging out in a production app slowing down compile times. I prefer to define types in TypeScript and generate proto from that, since the TypeScript type system is so much more powerful than the Protobuf system. Types are much more composable in TS.

Re: Show HN: Zero-codegen, no-compile TypeScript type inference from Protobufs

#39

Post by tantalor »

jitl wrote: post #38

It’s pretty rad how flexible template literal types are, but I can’t imagine wanting this kind of shenanigans hanging out in a production app slowing down compile times. I prefer to define types in TypeScript and generate proto from that, since the TypeScript type system is so much more powerful than the Protobuf system. Types are much more composable in TS.

What do you use to go from ts->pb?

Re: Show HN: Zero-codegen, no-compile TypeScript type inference from Protobufs

#40

Post by IshKebab »

mubou wrote: post #9
sgrove wrote: post #7

Earlier quoted context omitted.

Or even run doom in TypeScript's type system!

Prepare to have your mind blown: https://www.youtube.com/watch?v=0mCsluv5FXA

Probably not though because he was clearly referring to that.
Post reply on HN