Hacker News Reader

Comment by _7bxa | Hacker News Reader

Rather than do the typical HN thing of commenting on something irrelevant (like the landing page), I'll comment on the actual thing being presented:

First, I really like that this leverages Typescript to its fullest. I'm a big fan of doing things like runtime reflection of compile time types.

However:

``` id: number & PrimaryKey & AutoIncrement = 0; ```

One thing that seems confusing is, (presumably) -- these compile time types are being translated into runtime type behavior. (I'm guessing by your Typescript transformer?). While this is very cool and concise, I suspect it could be super "magical".

In your case, has Deepkit felt too magical?

View on HN

Having TypeScript types in runtime feels definitely like magic at the beginning. A TypeScript transformer makes them available in runtime so that libraries like the ORM, validator, or serialiser can use them to do whatever they do. You can read more about that in the introduction post: https://deepkit.io/blog/introducing-deepkit-framework

This is excellent work.

Thank you!

This is really wild. It feels almost like a way to wedge dependent types into the system, at least that's what the MinLength<2> & MaxLength<5> stuff feels like. Amazing.

How was it digging into the compiler api for that stuff? Every time I've poked around with that it's felt like a mess. Any resources you'd recommend?

I skimmed some of Deepkit and looked at your responses here. I have to say these parts of Deepkit really seems solve a major pain point that I have been investigating fairly recently. Kudos.

The places where I consider to use TypeScript are UI/CRUD/frontend centric, because I feel like the ecosystem around JS/TS is really rich and (finally) maturing when it comes to these things. So its really all about coordinating UI/user feedback, validation, serialization/parsing etc. And all that under regular change/evolution.

Now my conclusion so far has been to just try and keep it simple and separated and do the plumbing between all those parts explicitly. There is a benefit to that as well, but it does require more boilerplate and more bug surface. I will definitely tinker with some of the Deepkit libs to reassess this, because I think it might just do the right things in those areas.

This is/was a common concern about frameworks in Python like Attrs and Pydantic. And for the most part, no: it's just the right amount of magic. This is maybe a bit more magical than those, but as long as there is a coherent underlying data model and sufficient debugging capability, this kind of thing is usually a productivity boost with little downside.

Aren't the latter two definitions for the ORM side of things? Just guessing, I haven't looked into it too much.

> Rather than do the typical HN thing of commenting on something irrelevant (like the landing page)

I think you just did! (comment on something irrelevant to Deepkit, like the generic and uninformative landing page, that is)

CLASSIC! Replying to an unrelated comment by pointing out how unrelated that comment is.

Reply on news.ycombinator.com