3 ms·

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 hav

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.
  - Brometheus 4y ago
    To be honest, I'm baffled by the utter excellence of this.
primering 4y ago
Yes, it covers a lot. But that is in my eyes necessary to provide high performance throughout the whole application and is necessary to offer something that is fundamental unique. It's a matter of providing very fast basic building blocks to get that. For example, you can not make ORMs faster without first having a very fast deserialiser, or a fast RPC implementation without having very fast binary validation and encoding. So, it all works together, is decoupled and split up in multiple packages so they can be used separately. A lot of stuff is not yet documented, but they will. We are already writing new documentation/book which is roughly 40% done that covers already a lot more than what is currently seen on the website, but this HN post was posted at a somewhat bad timing. > - 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. Yes, gRPC is fast. But not gRPC-js. I invite you to test it yourself, all our benchmarks are in the git repository. It is explained here on how to run them: https://deepkit.io/documentation/benchmark https://deepkit.io/documentation/benchmark. Feel free to join our discord so I can guide you through the process. On the reasons why gRPC-js is slower: It uses Proto Buffers which is binary, and parsing binary is notoriously slow in JavaScript. By utilising the runtime type information of TypeScript we can generate JIT binary encoder/decoder for very specific types which are much faster. > - why is a very specific sorting algorithm bundled in? Why is providing something as a dedicated package a red flag? It's fundamental necessary for an UoW ORM for example and itself very useful. My other topsort package in PHP has 4 million installations, so it's only logical to bring the same functionality to TypeScript. > Message broker. Very opaque, but it's likely this is coupled to a very specific pubsub provider. It uses its own server, but will probably be replaced soon. Again, somewhat bad timing of that post. > - API console for testing HTTP calls. This is a solved problems with tools for testing APIs like Postman It doesn't solve what Postman solves. It's a way to automatically document your HTTP and RPC API plus allows to execute/try them right in the browser. There is Swagger UI which comes closer to what API Console is. > - For the view layer, it seems hard-coded to Angular There is actually no view layer. It has a server-side DI-enabled template engine based on JSX and a desktop UI kit (which is based on Angular). Both have their own use-case and are not required.
christophilus 4y ago
It’s an in-progress project. Regarding topsort, my guess is the algorithm was useful for some part of the project, and the author decided to make it available generally. > Don't you think Google has the resources and the incentive to make gRPC faster? You’d think that, but A) Gmail, and B) having worked for a Google competitor, I can assure you a passionate developer can write more performant code than what a massive corporation will generally produce. > I would heed caution at trying to solve every problem all at once. Agreed, but I hope the author throws caution to the wind. I’m tired of having either A) 1 million npm dependencies or B) boiling the ocean in my own projects, so it’d be nice to have a batteries included project you can rely on.
Vinnl 4y ago
> MongoDB ORM. It's a fine database, but it's also proxy indicator of web developers who only breath JavaScript. Yet the author appears to be writing the parser in C++: https://mobile.twitter.com/MarcJSchmidt/status/1534323199147663363 https://mobile.twitter.com/MarcJSchmidt/status/1534323199147...

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.
- Brometheus 4y ago
  To be honest, I'm baffled by the utter excellence of this.

primering 4y ago

Yes, it covers a lot. But that is in my eyes necessary to provide high performance throughout the whole application and is necessary to offer something that is fundamental unique. It's a matter of providing very fast basic building blocks to get that. For example, you can not make ORMs faster without first having a very fast deserialiser, or a fast RPC implementation without having very fast binary validation and encoding. So, it all works together, is decoupled and split up in multiple packages so they can be used separately. A lot of stuff is not yet documented, but they will. We are already writing new documentation/book which is roughly 40% done that covers already a lot more than what is currently seen on the website, but this HN post was posted at a somewhat bad timing. > - 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. Yes, gRPC is fast. But not gRPC-js. I invite you to test it yourself, all our benchmarks are in the git repository. It is explained here on how to run them: https://deepkit.io/documentation/benchmark https://deepkit.io/documentation/benchmark. Feel free to join our discord so I can guide you through the process. On the reasons why gRPC-js is slower: It uses Proto Buffers which is binary, and parsing binary is notoriously slow in JavaScript. By utilising the runtime type information of TypeScript we can generate JIT binary encoder/decoder for very specific types which are much faster. > - why is a very specific sorting algorithm bundled in? Why is providing something as a dedicated package a red flag? It's fundamental necessary for an UoW ORM for example and itself very useful. My other topsort package in PHP has 4 million installations, so it's only logical to bring the same functionality to TypeScript. > Message broker. Very opaque, but it's likely this is coupled to a very specific pubsub provider. It uses its own server, but will probably be replaced soon. Again, somewhat bad timing of that post. > - API console for testing HTTP calls. This is a solved problems with tools for testing APIs like Postman It doesn't solve what Postman solves. It's a way to automatically document your HTTP and RPC API plus allows to execute/try them right in the browser. There is Swagger UI which comes closer to what API Console is. > - For the view layer, it seems hard-coded to Angular There is actually no view layer. It has a server-side DI-enabled template engine based on JSX and a desktop UI kit (which is based on Angular). Both have their own use-case and are not required.

christophilus 4y ago

It’s an in-progress project. Regarding topsort, my guess is the algorithm was useful for some part of the project, and the author decided to make it available generally. > Don't you think Google has the resources and the incentive to make gRPC faster? You’d think that, but A) Gmail, and B) having worked for a Google competitor, I can assure you a passionate developer can write more performant code than what a massive corporation will generally produce. > I would heed caution at trying to solve every problem all at once. Agreed, but I hope the author throws caution to the wind. I’m tired of having either A) 1 million npm dependencies or B) boiling the ocean in my own projects, so it’d be nice to have a batteries included project you can rely on.

Vinnl 4y ago

> MongoDB ORM. It's a fine database, but it's also proxy indicator of web developers who only breath JavaScript. Yet the author appears to be writing the parser in C++: https://mobile.twitter.com/MarcJSchmidt/status/1534323199147663363 https://mobile.twitter.com/MarcJSchmidt/status/1534323199147...