Hacker News Reader

Comment by 9dev | Hacker News Reader

I just don’t get why they absolutely had to come up with new syntax. All of this would have been possible with standard Typescript, unlocking heaps of existing tooling, editor support, and prior knowledge. But no! Let’s come up with a new language, bespoke compiler, new LSP and IDE integrations, and make developers learn yet a new DSL.

It’s creating changes for the sake of creating changes.

View on HN

We first tried a TypeScript DSL and I really wish it would have worked for our use cases (e.g. describing complex REST APIs in Azure), but unfortunately it didn't.

I explained a bit more here last time TypeSpec was on here: https://news.ycombinator.com/item?id=39843184

https://www.speakeasy.com/guides/api-frameworks/typespec

This post has a bit more detail about why "we don't need more standards" might not be the correct take here

(Disclaimer speakeasy is a client but I wasn't directly involved in writing this and just figured it's pretty relevant here)

Pydantic/FastAPI - it is well designed, industry proven. Doesn’t need custom DSLs.

Came here to post this. We use Django Ninja at work (basically FastAPI style endpoints for Django), and it automatically does OpenAPI and Swagger docs for us. Whatever web framework one chooses in whichver language should def have this built-in by now, IMO, seems like tablestakes for anything larger than a "micro-framework"

Having your Framework generate the Docs is nice, but doesn't always fit.

At work, I build backends for mobile applications. When designing new APIs to be consumed by apps, we want input from the mobile developers. We facilitate this by having an api-specs repo with TSP and using Pull Requests to discuss, track and finally commit on new APIs.

It also allows mobile developers to open PRs with changes they want. The contracts are basically an interface that both sides can discuss and agree on.

Nah, it doesn't really say why they didn't just use TypeScript.

Off the top of my head, I don't think you can perfectly describe the type (string format) of an UUID in typescript types, which you can do with OpenAPI. That may be a reason.

You can get by, e.g. you can use JSDoc comments describing format or pattern, generic types taking a parameter of either format or pattern along with a base type, or create a custom well-known type you define as having the properties of a UUID. But aside from comments, this is not reflected well in the tooling, and none of these options compose particularly well.

You can do it with template string types: https://ybogomolov.me/type-level-uuid

The built in DOM types for the browser's `crypto.randomUUID` function actually already use this technique to a lesser extent: https://github.com/microsoft/TypeScript/blob/121c5dd36bd87e4...

See n2d4's comment but also AJV's JSONSchemaType

import { JSONSchemaType } from 'ajv'

It will bridge the JSON Schema and TypeScript types

We've found this useful too:

import { OpenAPIV3_1 as oa } from 'openapi-types'

export type Schema<T> = JSONSchemaType<T> & oa.SchemaObject

We validate that the type aligns with the schema and load the schema to validate all incoming requests

It's even worse, you still need node to run this thing, so you don't avoid the node dependency.

You don't get a bonus and promotion for just using TypeScript.

Facts, bonus-driven "innovation".

Also why Google has so many dead products.

"3 years of experience with TypeSpec"

Corollary: Not even a patent cube.

"Looks good on my CV" syndrome.

I'm not sure why you're getting downvoted. It might be hitting too close to home for some. But yeah, 95% of developers choose things to do to boost them for the next job.

I believe that 99% of the time, a reuse of older technologies results in greater innovation that is more stable and a return is multiple of the underlying foundations.

This applies here as well. Typescript could go a long way.

But admittedly, writing a grammar, parser and then a whole compiler along with its tooling of a new DSL is fun for sure but does look good on CV as well.

I didn't say anything more than that.

I downvoted both of your comments because I think it's rude and insulting to assume the motivation of someone's work is self-aggrandizing, and to dismiss out of hand the work might be motivated by technical needs because you can't immediately recognize those needs. I find the attitude frustrating, similar to the other common HN dismissal of "I could build it in a weekend".

Is that why a lot of teams inside azure use it for their API? Do all of them just do it for their CV? Or maybe it is that you're missing something ?

Reply on news.ycombinator.com