51–60 of 88 posts
[flagged]
This comment encapsulates perfectly what's wrong about the ts talibans... Astonishing to see how their minds can't comprehend that businesses can and do thrive with js.
would this be "pydantic-for-javascript" ?
Seems like you put a lot of work into this and as such I'm hesitant to criticize. But what in the world made you think this is superior to using an actual type-safe language like TypeScript? /** * Streams results for our lovable assistant * @param {string} query The question for our assistant * @stream {object} chunk * @stream {string} chunk.id * @stream {string} chunk.object * @stream {integer} chunk.created * @stre…
Seems like you put a lot of work into this and as such I'm hesitant to criticize. But what in the world made you think this is superior to using an actual type-safe language like TypeScript? /** * Streams results for our lovable assistant * @param {string} query The question for our assistant * @stream {object} chunk * @stream {string} chunk.id * @stream {string} chunk.object * @stream {integer} chunk.created * @stre…
Seems like you put a lot of work into this and as such I'm hesitant to criticize. But what in the world made you think this is superior to using an actual type-safe language like TypeScript? /** * Streams results for our lovable assistant * @param {string} query The question for our assistant * @stream {object} chunk * @stream {string} chunk.id * @stream {string} chunk.object * @stream {integer} chunk.created * @stre…
Yes, I was wondering about that too. If you put in the effort to parse the docblock into runtime validation, why not pick up the existing utilities to convert TypeScript types into runtime code during the build? That would be much more powerful, with the added benefit of having type safety for all other code, and a familiar syntax for developers.
@param {number{-90,90}} coords.lng Longitude
How and when are these kinds of types checked? Would this error only be found at runtime?
Earlier quoted context omitted.
Yes, I was wondering about that too. If you put in the effort to parse the docblock into runtime validation, why not pick up the existing utilities to convert TypeScript types into runtime code during the build? That would be much more powerful, with the added benefit of having type safety for all other code, and a familiar syntax for developers.
…or just use Zod?
It converts Zod types to OpenAPI specification.
Seems like you put a lot of work into this and as such I'm hesitant to criticize. But what in the world made you think this is superior to using an actual type-safe language like TypeScript? /** * Streams results for our lovable assistant * @param {string} query The question for our assistant * @stream {object} chunk * @stream {string} chunk.id * @stream {string} chunk.object * @stream {integer} chunk.created * @stre…
To use Typescript or not doesnt matter, it is about runtime validation. The one like the native JS way with JSDoc, the other likes Typescript and doesnt matter the build step for the API.
Earlier quoted context omitted.
…or just use Zod?
And if you like Zod, you might as well use this: https://github.com/asteasolutions/zod-to-openapi It converts Zod types to OpenAPI specification.
Json schema is more universal, and it can be used in .NET, Java, etc.
Earlier quoted context omitted.
No not necessarily! I just haven’t written type import support yet; though you’re welcome to help. And no — type safety is applied at the HTTP interface. API consumers need no special library to get all the benefits.
> And no — type safety is applied at the HTTP interface. So it's basically validation middleware. The HTTP protocol does not define any such thing.
There are various tools for it already, but the JS ecosystem has always been up for yet another framework.