3 ms·

Cool, but I assume not great for performance? Probably better to just stick with codegen

• dtech 2y ago
  Assuming you mean compiler/editor performance then yes I assume this wrecks it. Shouldn't matter for runtime though.
  • jillyboel 2y ago
    Right, I meant editor performance. None of the options should impact runtime performance anyway.
• 18nleung 2y ago
  You're right that IDE/dev-time performance might be slower than using generated types since this relies on "dynamic" TypeScript inference rather than static codegen'd types. That said, depending on how your codegen works and how you're using protos at runtime, this approach might actually be faster at runtime. Types are stripped at compile-time and there’s no generated class or constructor logic — in the compiled output, you're left with plain JS objects which potentially avoids the serialization or class overhead that some proto codegen tools introduce. (FWIW, type inference in VSCode seemed reasonably fast with the toy examples I was playing with)
  • recursive 2y ago
    Typescript never generates classes or constructors that aren't present in source code. Whether or not constructors are present is completely independent from whether you're using code gen.
  • jillyboel 2y ago
    > depending on how your codegen works and how you're using protos at runtime, this approach might actually be faster at runtime If your codegen is introducing runtime overhead you should use a different codegen. > type inference in VSCode seemed reasonably fast with the toy examples I was playing with It usually is. It can become a problem in a real project that has a lot of stuff going on, though.