12 ms·

Deepkit – High-Performance TypeScript Framework

251 points by nikolay 4y ago

dotancohen 4y ago
I closed the page after waiting about 5 seconds for the page to load. Yes, I realize that the "loading" was really just Javascript effects to present each element individually. I'm sure that artists and designers love that stuff. But the people interested in a programming language framework are people who have things to do and value their time - otherwise they would not be looking for a framework.
- nikolay 4y ago
  I agree. You can jump straight to the framework docs [0]. [0]: https://deepkit.io/framework https://deepkit.io/framework
- deleted 4y ago
  [deleted]
- Xevi 4y ago
  Not to mention that the landing page says absolutely nothing about what it is. Just saying that it's a framework means nothing. A framework can be a lot of different things. Sorry to sound so negative.
  - kevsim 4y ago
    I think if they lifted the diagram from the docs [0] to the front page it would make things a lot more clear. 0: https://deepkit.io/framework https://deepkit.io/framework
    - Xevi 4y ago
      Yeah it appear that they made the framework page their home page now, which is much better.
  - norman784 4y ago
    I agree with you, the landing page is very poor, if they are trying to sell the framework to someone it need to have more clear information. Maybe they can learn from next.js, remix.run and redwoodjs landing pages.
    - primering 4y ago
      I agree. We will do that once we shift focus on marketing/website, which is when we are out of alpha. Currently its a pragmatic low time-budget site that has only as purpose to tell that this exist, not to sell it like the companies you linked.
- dmitriid 4y ago
  They've removed the animations now. The page still loads ~2MB of Javascript, but at least it doesn't faaaaaaaaaaaaaaadeeeeee iiiiiin ooooooone woooooord aaaaat aaaaa tiiiiiime.
- primering 4y ago
  I agree, so I removed it. Designers sometimes recommend something that will not work out in the real world, so I have no hard feeling removing that. Website is still not optimised though. It's a big SPA that loads most things in advance and followed a pragmatic mindset. Better done than perfect. It's low priority to make that faster, however shouldn't be a problem though as the target audience usually has big bandwidth.
  - dmitriid 4y ago
    > Designers sometimes recommend something that will not work out in the real world There's also common sense. There are 33 words on that page, and it took 5 seconds for them to appear. No amount of design can justify that. Additionally, the work will be served better if https://deepkit.io/framework https://deepkit.io/framework is the home page, not the nothingness that is the home page
    - primering 4y ago
      Yeah, I thought about that, too. Will probably do that, thanks! //edit: I just did that
      - dmitriid 4y ago
        Awesome!
_7bxa 4y ago
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?
- krautsourced 4y ago
  Aren't the latter two definitions for the ORM side of things? Just guessing, I haven't looked into it too much.
- akiselev 4y ago
  > 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)
  - phist_mcgee 4y ago
    CLASSIC! Replying to an unrelated comment by pointing out how unrelated that comment is.
- deleted 4y ago
  [deleted]
- primering 4y ago
  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 https://deepkit.io/blog/introducing-deepkit-framework
krypton2k 4y ago
haha Solid Engineered...
- throwaway77384 4y ago
  Rather than just deriding someone, you could of course offer them a way to improve, by suggesting that it should be 'and solidly engineered', or 'engineered solidly'. The whole sentence / tag line could probably do with improving, but maybe this is not a native speaker, making derision all the more unacceptable.
  - tempodox 4y ago
    “Made in Germany”. Also, the grammar has been corrected by now.
- Brometheus 4y ago
  My goodness, I advice you to read the implementation details of this and be humbled about your own aptitude for programming.
aphexairlines 4y ago
- High performance - Scripting language Pick one.
- cies 4y ago
  Not entirely true. https://www.techempower.com/benchmarks https://www.techempower.com/benchmarks Has entries for JS and PHP quick high in the ranks.
  - ceeplusplus 4y ago
    The only JS entry I see in the top 20 uses a custom JS runtime that has "no support for ES modules". Not exactly a production ready application.
    - woojoo666 4y ago
      Still high performance scripting though?
    - capableweb 4y ago
      That's moving the goal post though. The argument was "High performance != Any Scripting language", which is clearly not true.
    - Tade0 4y ago
      PHP achieves a decent 40% in the composite score table though: https://www.techempower.com/benchmarks/#section=data-r20&hw=ph&test=composite https://www.techempower.com/benchmarks/#section=data-r20&hw=... I suppose you'd need to have Facebook-level scale for infrastructure to cost more than development in a "faster" language.
  - aphexairlines 4y ago
    There's a super interesting article from the just-js author explaining how he got a JS implementation into that top 20: https://just.billywhizz.io/blog/on-javascript-performance-01/ https://just.billywhizz.io/blog/on-javascript-performance-01...
Zababa 4y ago
The benchmark page doesn't load anything for me https://deepkit.io/benchmarks https://deepkit.io/benchmarks.
- m00dy 4y ago
  yeah, it looks like data points are missing.
  - primering 4y ago
    It's fixed.
    - capableweb 4y ago
      I'm unable to run the benchmarks at all. If I try to run it on my local machine, there is something wrong with the TypeScript setup or something, can't even run them. If I try the provided Dockerfile, Alpine can't install python for whatever reason.
stareatgoats 4y ago
This looks really interesting. The possibility to define runtime types basically removes the need to write data object validation blocks, greatly alleviates database sync etc. I'm sure I'm not the only one to have implemented runtime types on top of Typescript for this reason, albeit not at this low level and therefore incurring a certain performance penalty. So performance would be one reason to chose Deepkit for me. The integrated framework looks interesting too. Something that make me hesitant is the relative small user base and size of the community (mainly one single developer?) considering this would basically be to commit to a new programming language. And if the Typescript team should decide to do anything similar then the project might be dead in the water?
- ConsoleTVs 4y ago
  I never understood the "single developer" argument. React itself does not even have more than 5 active developers (https://github.com/facebook/react/graphs/contributors https://github.com/facebook/react/graphs/contributors), Vue literally have a single one (https://github.com/vuejs/vue/graphs/contributors https://github.com/vuejs/vue/graphs/contributors). You can apply this to almost any library. I mean, what's that argument for?
  - stareatgoats 4y ago
    It means that the project depends on the whims or life events of a single person - a single point of failure if you like: critical patches may not be merged, the maintainer might turn malicious etc. More people on the project means more eyeballs on the code. This seems self-evident to me (especially if the project is core in ones tech stack) so I'm really surprised at the "what's the argument for?". Am I missing something? (I don't see how you can cite Vue as an example; Evan is the main contributor to Vue, but he is certainly not the only one.)
m00dy 4y ago
one interesting thing is that it looks like the built-in debugger can also do static analysis and draw a call graph of the execution context. [0]. https://deepkit.io/assets/screenshots/debugger-http-light.png https://deepkit.io/assets/screenshots/debugger-http-light.pn...
cies 4y ago
Cool jooq[1]-query-syntax-like ORM! https://deepkit.io/library/orm https://deepkit.io/library/orm It does not seem to have the code-generation (for the db table DTOs) though. I also like typescript's "string & MinLength<3> & Email" type combining. A quick edit-test-loop must be a great selling point of this kind of FW compared to FW in more strongly types languages (that have slower edit-test-loops due to compilation) that I usually prefer. [1]: https://www.jooq.org/ https://www.jooq.org/
- mmgutz 4y ago
  The typing is interesting as I have been leveraging Typescript as an IDL for code generation between Go backend and TypeScript frontend. (GraphQL and gRPC were not expressive enough to define services, DTOs and JSON schema forms). Parsing Typescript's AST is simple. My guess is they generate code based on statically analyzable type arguments. I'm eager to try their approach. I am currently parsing jsdoc comments and tags for metadata which doesn't benefit from Typescript's checker. jooq is awesome. I was using that with DropWizard way back when. Now I'm just Go.
  - primering 4y ago
    We generate byte-code from the TypeScript AST, embed that into the emitted JavaScript, and execute them on-demand in a virtual machine during runtime. The result is a type-object which contains the computed type of a TypeScript type expression which can then be used for various use-cases. We use them for ORM, validation, serialisation, RPC, HTTP Router, etc. You can learn more on how it works here https://deepkit.io/blog/introducing-deepkit-framework https://deepkit.io/blog/introducing-deepkit-framework and in very detail in the TypeScript Bytecode proposal: https://github.com/microsoft/TypeScript/issues/47658 https://github.com/microsoft/TypeScript/issues/47658. Soon in a new doc/ebook it is explained in great detail how it works and the API of it can be utilised to build for example your own libraries/functionalities on top of it.
    - VyperCard 4y ago
      It’s a great read. Thanks.
bernadus_edwin 4y ago
I have one silly question. Is this for backend or frontend?
- aziaziazi 4y ago
  There’s a library called @deepkit/desktop-ui and another @deepkit/mongo. I guess you can use it anywhere, just pick libraries that makes sense on your environnement.
- primering 4y ago
  Both, but for the backend it's an entire framework that replaces something like Express/NestJS and for the frontend it is not. In the frontend can be used the validator and serialiser, so that types can be easily shared between frontend and backend. There is also a frontend desktop UI kit, but that is not the main focus (and was mainly separeted in a package because it was developed for GUI apps like API Console and Framework Debugger in Deepkit). You should use in the vast majority of cases the regular React/Angular/Vue frontend stack.
  - yodon 4y ago
    Is there a link you can share to your backend framework plans?
deleted 4y ago
[deleted]
alephnan 4y ago
This project is attempting to boil the ocean but I'm skeptical it can do each of these things well, considering information the dozen listed libraries don't have documentation. Including: - D.I. https://deepkit.io/documentation/injector https://deepkit.io/documentation/injector - Topsort "A fast implementation of a topological sort/dependency resolver with type grouping algorithm" https://deepkit.io/documentation/topsort https://deepkit.io/documentation/topsort - Templates https://deepkit.io/documentation/template https://deepkit.io/documentation/template I'll stop there, I'm too lazy to do their work for them. Other red flags - why is a very specific sorting algorithm bundled in? - its claimed their RPC implementation is 8x faster than gRPC, specifically gRPC-js. Don't you think Google has the resources and the incentive to make gRPC faster? It's likely this is not an apples-to-apples benchmark. - MongoDB ORM. It's a fine database, but it's also proxy indicator of web developers who only breath JavaScript. - Message broker. Very opaque, but it's likely this is coupled to a very specific pubsub provider. - API console for testing HTTP calls. This is a solved problems with tools for testing APIs like Postman. The fact that the team is trying to solve all sorts of problems, each of which is standalone product, makes feel they are trigger happy at reinventing the wheel. - For the view layer, it seems hard-coded to Angular. That's probably a no-go unless you don't care about what component library framework you have to use. This project seems to be a single author project. Kudos for being ambitious, but I would heed caution at trying to solve every problem all at once. Maybe lean into the ORM aspect and make that best in class first.
- vosper 4y ago
  > considering information the dozen listed libraries don't have documentation. I don’t think this is a “Show HN” or “Launch HN” posting. It’s possible the author is still working on code and docs, and has no idea the site’s been posted here.
  - primering 4y ago
    That's right. It's still being worked on, so a lot of documentation doesn't exist yet. But work is also being done in parallel on a book/new docs that covers all areas.
laurent123456 4y ago
This seems very interesting and I feel such a cohesive framework is needed in JS/TS, as an alternative to cobble together various unrelated packages. On the other hand, I wonder what will be the level of support for each of these libraries - just the ORM or desktop UI seem like a lot of work.
- vcryan 4y ago
  One man's cobbling together is a another's choosing the best library for the job ;)
  - oehpr 4y ago
    How on earth did selecting coherent, focused, modularized libraries become taboo for so many programmers? I will never understand. Nor sympathize.
    - lenkite 4y ago
      A bit late but I need to answer this: Because several of those coherent, focused and modularised libraries get un-maintained after a couple of years. Then your team needs to make another selection for many coherent, focused and modularized libraries. I suppose some developers enjoy doing this again and again. Many don't.
tekkk 4y ago
It looks really cool but I feel it's too much to take in a one bite. Making the framework do (almost) everything makes me think it won't be able to cover all the nuances of single-purpose libraries. I'd be much more open to trying it if it was just a general wiring around Fastify & Prisma for a better Node.js backend rather than a one tool to do everything.
- RoryH 4y ago
  They do have the option to just pick and [choose from a variety of libraries](https://deepkit.io/library https://deepkit.io/library). I like the look of @deepkit/type
- primering 4y ago
  That is a non-goal. One of the biggest advantages of Deepkit and its runtime type feature is that you can reuse TypeScript types throughout your whole application stack. This does not work with Fastify and Prisma. Let me give you an example. Let's say you build a little user management app and need a `User` type. So you define one: interface User { id: number; username: string; created: Date; email: string; } If you want to build a REST API that returns that user, you can just do that: router.get('/user/:id', (id: number & Positive): User => { //... }); Deepkit automatically serialises the object into JSON using the type information in `User`. You want to accept a User object for creating a user in the database? No problem: router.post('/user', (user: User): User => { //... }); You probably want to enrich the interface with additional constraints: interface User { id: integer & Positive; username: string & MinLength<3> & MaxLength<32>; created: Date; email: Email; } And with that the framework automatically validates all incoming requests against the User object and its containing validation constraints. It also deserialises it automatically from JSON for example. If the `User` is a class, it instantiates a class instance. But you don't want to require all fields, like id and created should be set by the server: router.post('/user', (user: Omit<User, 'id' |'created'>): User => { //... }); This works equally well. And the best part: you get API documentation for free with the Deepkit API Console, just like you know from Swagger UI. Ok, but we need to save the User in our database, right? We do not need to duplicate the User in yet another language like with Prisma. Just re-use the User interface and annotate the fields. interface User { id: integer & PrimaryKey & AutoIncrement; username: string & MinLength<3> & MaxLength<32> & Unique; created: Date; email: Email & Unique; } We still use the very same interface, but have added additional meta-data so you can use that exact same type now also for the ORM. router.get('/user/:id', async (id: number & Positive, db: Database): Promise<User> => { return await db.query<User>().filter({id}).findOne(); }); Next, let's go to the frontend. We obviously have to request the data from our rest API. We can just do that and reuse the `User` interface once again. const userJson = await fetch('/user/2'); const user = cast<User>(userJson); `cast` automatically validates and deserialises the received JSON. We import `User` wherever needed and this works because the meta-data is not tightly coupled to any library, so you won't pull in for example ORM code just because you use database meta-data. You can literally use TypeScript's powerful type-system to your full advantage in many small to super complex use-cases and let the framework handle all the validation, serialisation, and database stuff. And like that you are able to reuse types everywhere: From database to http router, configuration, RPC, API documentation, dependency injection, message broker, frontend, and more. That's not possible in this form in any other framework or when you combine lots of third-party libraries and glue them manually together. Deepkit separated the functionality in libraries which would allow you to use their features in Fastify and Prisma, too, but that would mean you lose one of the biggest advantage of all: Reusing types.
sandGorgon 4y ago
reminds me of Python's Fastapi - https://deepkit.io/framework https://deepkit.io/framework
ricardobeat 4y ago
The special compiler for runtime types is available separately at https://deepkit.io/documentation/type https://deepkit.io/documentation/type, this is great! I will definitely be testing this in our RN app.
phpnode 4y ago
I just want to say that this looks fantastic, especially the runtime types stuff - the idea that types are values hasn't caught on yet but it's great to see movement in this area. A long time ago I did something very similar to this for Flow (https://gajus.github.io/flow-runtime/#/try https://gajus.github.io/flow-runtime/#/try) but typescript is a much more suitable target. Congratulations on an amazing job, I really hope you have plans to sustain this project for a long time, because it's very ambitious but very compelling.
- szines 4y ago
  Great to see a new option in the TypeScript ecosystem. A fully featured framework. Brilliant. Could be a great alternative to Adonis.js which is one of my favourite nowadays: https://adonisjs.com/ https://adonisjs.com/
- lloydatkinson 4y ago
  TypeScript's type system can be very powerful and flexible - creating types at build time in a manner of speaking. Here's an article I wrote on an aspect of this called mapped types. You can see how types can be composed of other types. https://www.lloydatkinson.net/posts/2022/going-further-with-typescript-part-1/ https://www.lloydatkinson.net/posts/2022/going-further-with-...
nikeee 4y ago
I'm not a fan of the idea of leveraging TS types at runtime. This is just a lock-in to TS, even if type annotations become a thing in JS. I don't like ORMs that use runtime types either. Most of the time, I want to write raw SQL. So as an experiment, I created a library that statically types raw SQL: https://github.com/nikeee/sequelts https://github.com/nikeee/sequelts The idea is to parse the SQL queries using TS's type system. The parsed query is combined with the database schema and therefore, we know what type the query will return. This is especially useful due to TS's structural type system. It's also zero-overhead due to the entire functionality being just TS types, which vanish as soon as we compile. It therefore also works JS-only. However, it's just a proof of concept. I'm working on an ANTLR target for TS types, so that the SQL parser can be generated. A game changer will also be the integration with sql-template-tags [1] (which would make this actually usable). This is just for selecting data. Time will tell if it's feasible to also type-check mutating queries. The primary use-cases will target SQLite/D1. [1]: https://www.npmjs.com/package/sql-template-tag https://www.npmjs.com/package/sql-template-tag
- czx4f4bd 4y ago
  Wow, I was literally thinking about this like a week ago, wondering how viable it would be. This is great work. The ability to compile ANTLR to TypeScript types would potentially be a game-changer.
- phpnode 4y ago
  author of ts-sql[0] here, this looks great (and a way more practical approach!) [0] https://github.com/codemix/ts-sql https://github.com/codemix/ts-sql
- seer 4y ago
  Hah a few months back I released https://github.com/ivank/potygen https://github.com/ivank/potygen Similar idea - statically typing queries. Mine was mostly me playing around with recursive decent parsers seeing if I can actually parse SQL with it, and it seems to work OK, at least for Postgres. It does require a "build" pass to generate the types, but I've added some additional bells and whistles like auto formatters and on hover info about columns / views / tables etc. Once you have the sql AST its pretty easy to build a lot of cool stuff around it. It's all pure TS and doesn't use parser generators like ANTLR. We've been using it in prod for a while now and seem to be working alright - its mostly types anyway, but does have a runtime component, since sql parameters in node Postgres are too basic for our use case. It all started from the amazing https://github.com/dmaevsky/rd-parse https://github.com/dmaevsky/rd-parse which showed me that you could build crazy complex parsers with like 100-200 lines of code.
lukeholder 4y ago
Noob question here, but why do this: `string & MinLength<3> & Unique;` When one could use a Value Object Type?
creakingstairs 4y ago
This looks very ambitious and at first glance looks amazing. I’m quite cautious of using node frameworks but I’m definitely trying this one out. I like elixir/phoenix but I miss types and loving that this project is embracing types at its very core.
- fatboy 4y ago
  This was on HN a few weeks ago and may be of interest to you: https://github.com/floodfx/liveviewjs https://github.com/floodfx/liveviewjs
  - creakingstairs 4y ago
    Thanks for letting me know! It does look interesting but the “killer features” of phoenix for me is easy tests with SQL sandbox and exmachina + mix code gen. I’m not too into LiveView through I should work with it more.
    - fatboy 4y ago
      Ah fair enough! I've never used elixir/phoenix, and I was under the impression that it _was_ LiveView. Now I get that Phoenix LiveView is just one component.
__alexs 4y ago
> Precisely aligned, gently optimised, solidly engineered. If you write junk like this to describe your software project I am immediately going to assume you are completely hopeless and not to be trusted at all. Not one of these 6 words convey any meaning at all. It's like the bad old days of calling everything web scale.
pelorat 4y ago
Can we just let JS/TS die and compile something better to WASM already?
- klysm 4y ago
  I don't think JS/TS would die if you tried to kill it.
joshstrange 4y ago
One thing I think TypeScript is missing (on the server at least) is a Laravel-like (in that it covers everything, not it's exact style) framework. I'll be interested to keep an eye on this. I wish it had serverless support but I know that's a whole other beast, I have really enjoyed the majority of my typescript on serverless work and would love a formal framework instead of what I've cobbled together.
- AntonyGarand 4y ago
  NestJS[0] is the most popular framework to solve pretty much this exact issue. It does support serverless[1], as well as many other features you can expect from such a framework. [0] https://nestjs.com/ https://nestjs.com/ [1] https://docs.nestjs.com/faq/serverless#serverless https://docs.nestjs.com/faq/serverless#serverless
  - primering 4y ago
    To be honest, I don't think NestJS is even remotely comparable to anything like Symfony/Laravel.
- primering 4y ago
  Serverless is being worked on. We indeed plan to be Laravel/Symfony/Spring boot in the TypeScript world. Time will tell if we will be successful.
  - Onewildgamer 4y ago
    It already looks like SpringBoot at first glance. You'll have troves of Java devs flocking to something like this. There's a general dislike towards Java/C# code nowadays, you can't argue that spring/springboot brought stability to the language and its mainstream usage. Something like this in TS makes it feel familiar, and after trying the examples I am quite excited!
- ham-sandwich 4y ago
  You’re looking for Redwood
vonnik 4y ago
I just want to put a word in for Marc Schmidt. He's a great engineer, with great product sense. This project will move fast, and if you think it's missing something essential, it's probably on the roadmap and will be realized quickly.
- primering 4y ago
  thank you so much!
abraxas 4y ago
ORM, DI, reflection, config, validation, events... So... a hipster SpringBoot then? The history doesn't repeat but it rhymes indeed :)
- primering 4y ago
  If people say this is a modern version of Spring Boot, then I'm all for it.
stereocodes 4y ago
> A runtime type system for JavaScript, powered by TypeScript types. why would I choose this over Deno?
- primering 4y ago
  Curious, why would this be related to Deno?
beardedman 4y ago
This look interesting, but a bit of a headache to scale.
- primering 4y ago
  Can you explain why this gives headache to scale? I ask because it is designed to scale well.
mpalmer 4y ago
The logo bears a striking similarity to Lightspeed's...like, flip it along the vertical axis and the resemblance is uncanny. https://www.lightspeedhq.com/ https://www.lightspeedhq.com/
IceDane 4y ago
I remember seeing this before and as far as I can tell, nothing important has changed since then. It's still a project where the bus factor is extremely low: the author has 95% of all the commits. The project is basically reinventing every wheel in the typescript space, too, and it's going weird ways with a custom compiler and crazy reflection. It's dogfooding hard, so it's all built on its own things, and all of those things are definitely going to have bugs because one guy wrote all of it, and it's just him to fix them. I think it has a lot of neat stuff and cool things I'd otherwise like to have, but there is basically no way I can adopt this framework for anything serious because of the reasons above.

251 points by nikolay 4y ago

I closed the page after waiting about 5 seconds for the page to load. Yes, I realize that the "loading" was really just Javascript effects to present each element individually. I'm sure that artists and designers love that stuff. But the people interested in a programming language framework are people who have things to do and value their time - otherwise they would not be looking for a framework.

nikolay 4y ago
I agree. You can jump straight to the framework docs [0]. [0]: https://deepkit.io/framework https://deepkit.io/framework
deleted 4y ago
[deleted]
Xevi 4y ago
Not to mention that the landing page says absolutely nothing about what it is. Just saying that it's a framework means nothing. A framework can be a lot of different things. Sorry to sound so negative.
- kevsim 4y ago
  I think if they lifted the diagram from the docs [0] to the front page it would make things a lot more clear. 0: https://deepkit.io/framework https://deepkit.io/framework
  - Xevi 4y ago
    Yeah it appear that they made the framework page their home page now, which is much better.
- norman784 4y ago
  I agree with you, the landing page is very poor, if they are trying to sell the framework to someone it need to have more clear information. Maybe they can learn from next.js, remix.run and redwoodjs landing pages.
  - primering 4y ago
    I agree. We will do that once we shift focus on marketing/website, which is when we are out of alpha. Currently its a pragmatic low time-budget site that has only as purpose to tell that this exist, not to sell it like the companies you linked.
dmitriid 4y ago
They've removed the animations now. The page still loads ~2MB of Javascript, but at least it doesn't faaaaaaaaaaaaaaadeeeeee iiiiiin ooooooone woooooord aaaaat aaaaa tiiiiiime.
primering 4y ago
I agree, so I removed it. Designers sometimes recommend something that will not work out in the real world, so I have no hard feeling removing that. Website is still not optimised though. It's a big SPA that loads most things in advance and followed a pragmatic mindset. Better done than perfect. It's low priority to make that faster, however shouldn't be a problem though as the target audience usually has big bandwidth.
- dmitriid 4y ago
  > Designers sometimes recommend something that will not work out in the real world There's also common sense. There are 33 words on that page, and it took 5 seconds for them to appear. No amount of design can justify that. Additionally, the work will be served better if https://deepkit.io/framework https://deepkit.io/framework is the home page, not the nothingness that is the home page
  - primering 4y ago
    Yeah, I thought about that, too. Will probably do that, thanks! //edit: I just did that
    - dmitriid 4y ago
      Awesome!

_7bxa 4y ago

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?

krautsourced 4y ago
Aren't the latter two definitions for the ORM side of things? Just guessing, I haven't looked into it too much.
akiselev 4y ago
> 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)
- phist_mcgee 4y ago
  CLASSIC! Replying to an unrelated comment by pointing out how unrelated that comment is.
deleted 4y ago
[deleted]
primering 4y ago
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 https://deepkit.io/blog/introducing-deepkit-framework

krypton2k 4y ago

haha Solid Engineered...

throwaway77384 4y ago
Rather than just deriding someone, you could of course offer them a way to improve, by suggesting that it should be 'and solidly engineered', or 'engineered solidly'. The whole sentence / tag line could probably do with improving, but maybe this is not a native speaker, making derision all the more unacceptable.
- tempodox 4y ago
  “Made in Germany”. Also, the grammar has been corrected by now.
Brometheus 4y ago
My goodness, I advice you to read the implementation details of this and be humbled about your own aptitude for programming.

aphexairlines 4y ago

- High performance - Scripting language Pick one.

cies 4y ago
Not entirely true. https://www.techempower.com/benchmarks https://www.techempower.com/benchmarks Has entries for JS and PHP quick high in the ranks.
- ceeplusplus 4y ago
  The only JS entry I see in the top 20 uses a custom JS runtime that has "no support for ES modules". Not exactly a production ready application.
  - woojoo666 4y ago
    Still high performance scripting though?
  - capableweb 4y ago
    That's moving the goal post though. The argument was "High performance != Any Scripting language", which is clearly not true.
  - Tade0 4y ago
    PHP achieves a decent 40% in the composite score table though: https://www.techempower.com/benchmarks/#section=data-r20&hw=ph&test=composite https://www.techempower.com/benchmarks/#section=data-r20&hw=... I suppose you'd need to have Facebook-level scale for infrastructure to cost more than development in a "faster" language.
- aphexairlines 4y ago
  There's a super interesting article from the just-js author explaining how he got a JS implementation into that top 20: https://just.billywhizz.io/blog/on-javascript-performance-01/ https://just.billywhizz.io/blog/on-javascript-performance-01...

Zababa 4y ago

The benchmark page doesn't load anything for me https://deepkit.io/benchmarks https://deepkit.io/benchmarks.

m00dy 4y ago
yeah, it looks like data points are missing.
- primering 4y ago
  It's fixed.
  - capableweb 4y ago
    I'm unable to run the benchmarks at all. If I try to run it on my local machine, there is something wrong with the TypeScript setup or something, can't even run them. If I try the provided Dockerfile, Alpine can't install python for whatever reason.

stareatgoats 4y ago

This looks really interesting. The possibility to define runtime types basically removes the need to write data object validation blocks, greatly alleviates database sync etc. I'm sure I'm not the only one to have implemented runtime types on top of Typescript for this reason, albeit not at this low level and therefore incurring a certain performance penalty. So performance would be one reason to chose Deepkit for me. The integrated framework looks interesting too. Something that make me hesitant is the relative small user base and size of the community (mainly one single developer?) considering this would basically be to commit to a new programming language. And if the Typescript team should decide to do anything similar then the project might be dead in the water?

ConsoleTVs 4y ago
I never understood the "single developer" argument. React itself does not even have more than 5 active developers (https://github.com/facebook/react/graphs/contributors https://github.com/facebook/react/graphs/contributors), Vue literally have a single one (https://github.com/vuejs/vue/graphs/contributors https://github.com/vuejs/vue/graphs/contributors). You can apply this to almost any library. I mean, what's that argument for?
- stareatgoats 4y ago
  It means that the project depends on the whims or life events of a single person - a single point of failure if you like: critical patches may not be merged, the maintainer might turn malicious etc. More people on the project means more eyeballs on the code. This seems self-evident to me (especially if the project is core in ones tech stack) so I'm really surprised at the "what's the argument for?". Am I missing something? (I don't see how you can cite Vue as an example; Evan is the main contributor to Vue, but he is certainly not the only one.)

m00dy 4y ago

one interesting thing is that it looks like the built-in debugger can also do static analysis and draw a call graph of the execution context. [0]. https://deepkit.io/assets/screenshots/debugger-http-light.png https://deepkit.io/assets/screenshots/debugger-http-light.pn...

cies 4y ago

Cool jooq[1]-query-syntax-like ORM! https://deepkit.io/library/orm https://deepkit.io/library/orm It does not seem to have the code-generation (for the db table DTOs) though. I also like typescript's "string & MinLength<3> & Email" type combining. A quick edit-test-loop must be a great selling point of this kind of FW compared to FW in more strongly types languages (that have slower edit-test-loops due to compilation) that I usually prefer. [1]: https://www.jooq.org/ https://www.jooq.org/

mmgutz 4y ago
The typing is interesting as I have been leveraging Typescript as an IDL for code generation between Go backend and TypeScript frontend. (GraphQL and gRPC were not expressive enough to define services, DTOs and JSON schema forms). Parsing Typescript's AST is simple. My guess is they generate code based on statically analyzable type arguments. I'm eager to try their approach. I am currently parsing jsdoc comments and tags for metadata which doesn't benefit from Typescript's checker. jooq is awesome. I was using that with DropWizard way back when. Now I'm just Go.
- primering 4y ago
  We generate byte-code from the TypeScript AST, embed that into the emitted JavaScript, and execute them on-demand in a virtual machine during runtime. The result is a type-object which contains the computed type of a TypeScript type expression which can then be used for various use-cases. We use them for ORM, validation, serialisation, RPC, HTTP Router, etc. You can learn more on how it works here https://deepkit.io/blog/introducing-deepkit-framework https://deepkit.io/blog/introducing-deepkit-framework and in very detail in the TypeScript Bytecode proposal: https://github.com/microsoft/TypeScript/issues/47658 https://github.com/microsoft/TypeScript/issues/47658. Soon in a new doc/ebook it is explained in great detail how it works and the API of it can be utilised to build for example your own libraries/functionalities on top of it.
  - VyperCard 4y ago
    It’s a great read. Thanks.

bernadus_edwin 4y ago

I have one silly question. Is this for backend or frontend?

aziaziazi 4y ago
There’s a library called @deepkit/desktop-ui and another @deepkit/mongo. I guess you can use it anywhere, just pick libraries that makes sense on your environnement.
primering 4y ago
Both, but for the backend it's an entire framework that replaces something like Express/NestJS and for the frontend it is not. In the frontend can be used the validator and serialiser, so that types can be easily shared between frontend and backend. There is also a frontend desktop UI kit, but that is not the main focus (and was mainly separeted in a package because it was developed for GUI apps like API Console and Framework Debugger in Deepkit). You should use in the vast majority of cases the regular React/Angular/Vue frontend stack.
- yodon 4y ago
  Is there a link you can share to your backend framework plans?

deleted 4y ago

[deleted]

alephnan 4y ago

This project is attempting to boil the ocean but I'm skeptical it can do each of these things well, considering information the dozen listed libraries don't have documentation. Including: - D.I. https://deepkit.io/documentation/injector https://deepkit.io/documentation/injector - Topsort "A fast implementation of a topological sort/dependency resolver with type grouping algorithm" https://deepkit.io/documentation/topsort https://deepkit.io/documentation/topsort - Templates https://deepkit.io/documentation/template https://deepkit.io/documentation/template I'll stop there, I'm too lazy to do their work for them. Other red flags - why is a very specific sorting algorithm bundled in? - its claimed their RPC implementation is 8x faster than gRPC, specifically gRPC-js. Don't you think Google has the resources and the incentive to make gRPC faster? It's likely this is not an apples-to-apples benchmark. - MongoDB ORM. It's a fine database, but it's also proxy indicator of web developers who only breath JavaScript. - Message broker. Very opaque, but it's likely this is coupled to a very specific pubsub provider. - API console for testing HTTP calls. This is a solved problems with tools for testing APIs like Postman. The fact that the team is trying to solve all sorts of problems, each of which is standalone product, makes feel they are trigger happy at reinventing the wheel. - For the view layer, it seems hard-coded to Angular. That's probably a no-go unless you don't care about what component library framework you have to use. This project seems to be a single author project. Kudos for being ambitious, but I would heed caution at trying to solve every problem all at once. Maybe lean into the ORM aspect and make that best in class first.

vosper 4y ago
> considering information the dozen listed libraries don't have documentation. I don’t think this is a “Show HN” or “Launch HN” posting. It’s possible the author is still working on code and docs, and has no idea the site’s been posted here.
- primering 4y ago
  That's right. It's still being worked on, so a lot of documentation doesn't exist yet. But work is also being done in parallel on a book/new docs that covers all areas.

laurent123456 4y ago

This seems very interesting and I feel such a cohesive framework is needed in JS/TS, as an alternative to cobble together various unrelated packages. On the other hand, I wonder what will be the level of support for each of these libraries - just the ORM or desktop UI seem like a lot of work.

vcryan 4y ago
One man's cobbling together is a another's choosing the best library for the job ;)
- oehpr 4y ago
  How on earth did selecting coherent, focused, modularized libraries become taboo for so many programmers? I will never understand. Nor sympathize.
  - lenkite 4y ago
    A bit late but I need to answer this: Because several of those coherent, focused and modularised libraries get un-maintained after a couple of years. Then your team needs to make another selection for many coherent, focused and modularized libraries. I suppose some developers enjoy doing this again and again. Many don't.

tekkk 4y ago

It looks really cool but I feel it's too much to take in a one bite. Making the framework do (almost) everything makes me think it won't be able to cover all the nuances of single-purpose libraries. I'd be much more open to trying it if it was just a general wiring around Fastify & Prisma for a better Node.js backend rather than a one tool to do everything.

RoryH 4y ago
They do have the option to just pick and [choose from a variety of libraries](https://deepkit.io/library https://deepkit.io/library). I like the look of @deepkit/type
primering 4y ago
That is a non-goal. One of the biggest advantages of Deepkit and its runtime type feature is that you can reuse TypeScript types throughout your whole application stack. This does not work with Fastify and Prisma. Let me give you an example. Let's say you build a little user management app and need a `User` type. So you define one: interface User { id: number; username: string; created: Date; email: string; } If you want to build a REST API that returns that user, you can just do that: router.get('/user/:id', (id: number & Positive): User => { //... }); Deepkit automatically serialises the object into JSON using the type information in `User`. You want to accept a User object for creating a user in the database? No problem: router.post('/user', (user: User): User => { //... }); You probably want to enrich the interface with additional constraints: interface User { id: integer & Positive; username: string & MinLength<3> & MaxLength<32>; created: Date; email: Email; } And with that the framework automatically validates all incoming requests against the User object and its containing validation constraints. It also deserialises it automatically from JSON for example. If the `User` is a class, it instantiates a class instance. But you don't want to require all fields, like id and created should be set by the server: router.post('/user', (user: Omit<User, 'id' |'created'>): User => { //... }); This works equally well. And the best part: you get API documentation for free with the Deepkit API Console, just like you know from Swagger UI. Ok, but we need to save the User in our database, right? We do not need to duplicate the User in yet another language like with Prisma. Just re-use the User interface and annotate the fields. interface User { id: integer & PrimaryKey & AutoIncrement; username: string & MinLength<3> & MaxLength<32> & Unique; created: Date; email: Email & Unique; } We still use the very same interface, but have added additional meta-data so you can use that exact same type now also for the ORM. router.get('/user/:id', async (id: number & Positive, db: Database): Promise<User> => { return await db.query<User>().filter({id}).findOne(); }); Next, let's go to the frontend. We obviously have to request the data from our rest API. We can just do that and reuse the `User` interface once again. const userJson = await fetch('/user/2'); const user = cast<User>(userJson); `cast` automatically validates and deserialises the received JSON. We import `User` wherever needed and this works because the meta-data is not tightly coupled to any library, so you won't pull in for example ORM code just because you use database meta-data. You can literally use TypeScript's powerful type-system to your full advantage in many small to super complex use-cases and let the framework handle all the validation, serialisation, and database stuff. And like that you are able to reuse types everywhere: From database to http router, configuration, RPC, API documentation, dependency injection, message broker, frontend, and more. That's not possible in this form in any other framework or when you combine lots of third-party libraries and glue them manually together. Deepkit separated the functionality in libraries which would allow you to use their features in Fastify and Prisma, too, but that would mean you lose one of the biggest advantage of all: Reusing types.

sandGorgon 4y ago

reminds me of Python's Fastapi - https://deepkit.io/framework https://deepkit.io/framework

ricardobeat 4y ago

The special compiler for runtime types is available separately at https://deepkit.io/documentation/type https://deepkit.io/documentation/type, this is great! I will definitely be testing this in our RN app.

phpnode 4y ago

I just want to say that this looks fantastic, especially the runtime types stuff - the idea that types are values hasn't caught on yet but it's great to see movement in this area. A long time ago I did something very similar to this for Flow (https://gajus.github.io/flow-runtime/#/try https://gajus.github.io/flow-runtime/#/try) but typescript is a much more suitable target. Congratulations on an amazing job, I really hope you have plans to sustain this project for a long time, because it's very ambitious but very compelling.

szines 4y ago
Great to see a new option in the TypeScript ecosystem. A fully featured framework. Brilliant. Could be a great alternative to Adonis.js which is one of my favourite nowadays: https://adonisjs.com/ https://adonisjs.com/
lloydatkinson 4y ago
TypeScript's type system can be very powerful and flexible - creating types at build time in a manner of speaking. Here's an article I wrote on an aspect of this called mapped types. You can see how types can be composed of other types. https://www.lloydatkinson.net/posts/2022/going-further-with-typescript-part-1/ https://www.lloydatkinson.net/posts/2022/going-further-with-...

nikeee 4y ago

I'm not a fan of the idea of leveraging TS types at runtime. This is just a lock-in to TS, even if type annotations become a thing in JS. I don't like ORMs that use runtime types either. Most of the time, I want to write raw SQL. So as an experiment, I created a library that statically types raw SQL: https://github.com/nikeee/sequelts https://github.com/nikeee/sequelts The idea is to parse the SQL queries using TS's type system. The parsed query is combined with the database schema and therefore, we know what type the query will return. This is especially useful due to TS's structural type system. It's also zero-overhead due to the entire functionality being just TS types, which vanish as soon as we compile. It therefore also works JS-only. However, it's just a proof of concept. I'm working on an ANTLR target for TS types, so that the SQL parser can be generated. A game changer will also be the integration with sql-template-tags [1] (which would make this actually usable). This is just for selecting data. Time will tell if it's feasible to also type-check mutating queries. The primary use-cases will target SQLite/D1. [1]: https://www.npmjs.com/package/sql-template-tag https://www.npmjs.com/package/sql-template-tag

czx4f4bd 4y ago
Wow, I was literally thinking about this like a week ago, wondering how viable it would be. This is great work. The ability to compile ANTLR to TypeScript types would potentially be a game-changer.
phpnode 4y ago
author of ts-sql[0] here, this looks great (and a way more practical approach!) [0] https://github.com/codemix/ts-sql https://github.com/codemix/ts-sql
seer 4y ago
Hah a few months back I released https://github.com/ivank/potygen https://github.com/ivank/potygen Similar idea - statically typing queries. Mine was mostly me playing around with recursive decent parsers seeing if I can actually parse SQL with it, and it seems to work OK, at least for Postgres. It does require a "build" pass to generate the types, but I've added some additional bells and whistles like auto formatters and on hover info about columns / views / tables etc. Once you have the sql AST its pretty easy to build a lot of cool stuff around it. It's all pure TS and doesn't use parser generators like ANTLR. We've been using it in prod for a while now and seem to be working alright - its mostly types anyway, but does have a runtime component, since sql parameters in node Postgres are too basic for our use case. It all started from the amazing https://github.com/dmaevsky/rd-parse https://github.com/dmaevsky/rd-parse which showed me that you could build crazy complex parsers with like 100-200 lines of code.

lukeholder 4y ago

Noob question here, but why do this: `string & MinLength<3> & Unique;` When one could use a Value Object Type?

creakingstairs 4y ago

This looks very ambitious and at first glance looks amazing. I’m quite cautious of using node frameworks but I’m definitely trying this one out. I like elixir/phoenix but I miss types and loving that this project is embracing types at its very core.

fatboy 4y ago
This was on HN a few weeks ago and may be of interest to you: https://github.com/floodfx/liveviewjs https://github.com/floodfx/liveviewjs
- creakingstairs 4y ago
  Thanks for letting me know! It does look interesting but the “killer features” of phoenix for me is easy tests with SQL sandbox and exmachina + mix code gen. I’m not too into LiveView through I should work with it more.
  - fatboy 4y ago
    Ah fair enough! I've never used elixir/phoenix, and I was under the impression that it _was_ LiveView. Now I get that Phoenix LiveView is just one component.

__alexs 4y ago

> Precisely aligned, gently optimised, solidly engineered. If you write junk like this to describe your software project I am immediately going to assume you are completely hopeless and not to be trusted at all. Not one of these 6 words convey any meaning at all. It's like the bad old days of calling everything web scale.

pelorat 4y ago

Can we just let JS/TS die and compile something better to WASM already?

klysm 4y ago
I don't think JS/TS would die if you tried to kill it.

joshstrange 4y ago

One thing I think TypeScript is missing (on the server at least) is a Laravel-like (in that it covers everything, not it's exact style) framework. I'll be interested to keep an eye on this. I wish it had serverless support but I know that's a whole other beast, I have really enjoyed the majority of my typescript on serverless work and would love a formal framework instead of what I've cobbled together.

AntonyGarand 4y ago
NestJS[0] is the most popular framework to solve pretty much this exact issue. It does support serverless[1], as well as many other features you can expect from such a framework. [0] https://nestjs.com/ https://nestjs.com/ [1] https://docs.nestjs.com/faq/serverless#serverless https://docs.nestjs.com/faq/serverless#serverless
- primering 4y ago
  To be honest, I don't think NestJS is even remotely comparable to anything like Symfony/Laravel.
primering 4y ago
Serverless is being worked on. We indeed plan to be Laravel/Symfony/Spring boot in the TypeScript world. Time will tell if we will be successful.
- Onewildgamer 4y ago
  It already looks like SpringBoot at first glance. You'll have troves of Java devs flocking to something like this. There's a general dislike towards Java/C# code nowadays, you can't argue that spring/springboot brought stability to the language and its mainstream usage. Something like this in TS makes it feel familiar, and after trying the examples I am quite excited!
ham-sandwich 4y ago
You’re looking for Redwood

vonnik 4y ago

I just want to put a word in for Marc Schmidt. He's a great engineer, with great product sense. This project will move fast, and if you think it's missing something essential, it's probably on the roadmap and will be realized quickly.

primering 4y ago
thank you so much!

abraxas 4y ago

ORM, DI, reflection, config, validation, events... So... a hipster SpringBoot then? The history doesn't repeat but it rhymes indeed :)

primering 4y ago
If people say this is a modern version of Spring Boot, then I'm all for it.

stereocodes 4y ago

> A runtime type system for JavaScript, powered by TypeScript types. why would I choose this over Deno?

primering 4y ago
Curious, why would this be related to Deno?

beardedman 4y ago

This look interesting, but a bit of a headache to scale.

primering 4y ago
Can you explain why this gives headache to scale? I ask because it is designed to scale well.

mpalmer 4y ago

The logo bears a striking similarity to Lightspeed's...like, flip it along the vertical axis and the resemblance is uncanny. https://www.lightspeedhq.com/ https://www.lightspeedhq.com/

IceDane 4y ago

I remember seeing this before and as far as I can tell, nothing important has changed since then. It's still a project where the bus factor is extremely low: the author has 95% of all the commits. The project is basically reinventing every wheel in the typescript space, too, and it's going weird ways with a custom compiler and crazy reflection. It's dogfooding hard, so it's all built on its own things, and all of those things are definitely going to have bugs because one guy wrote all of it, and it's just him to fix them. I think it has a lot of neat stuff and cool things I'd otherwise like to have, but there is basically no way I can adopt this framework for anything serious because of the reasons above.