primering

5 ms·

1.
by primering 1y ago
I think that summarizes it well. It's not 10x better that makes the risky bet of going into vendor lock from a VC-backed company worth it. Same issue with Prisma and Next for me.
2.
by primering 1y ago
No, that is exactly what an ORM is, plus mapping it back. Anything around that is additional toolings that no ORM needs to be ORM, but is nonetheless usefull.
3.
by primering 1y ago
Yeah it's funny they even mention ORM while at the same offering something that has nothing to do with ORMs at all. Yes, many ORM libraries offer additional tools like migration and querybuiler, but that's not the point of an ORM.
4.
by primering 1y ago
Well said. Please never be silent over this fact. It's important to educate people on what an ORM is, what it means and especially what it doesn't mean. Especially in times where VC-baked companies misinform and manipulate people
5.
by primering 1y ago
> you won’t see anything like this that compiles to javascript https://github.com/microsoft/TypeScript/issues/47658
6.
by primering 1y ago
That is the real reason we get a less feature-rich TypeScript in the future and Node not supporting full TypeScript. Because they want to be supported by browser.
7.
by primering 1y ago
> I think this is a great step in the right direction by node I think it's the opposite. It will be a net negative, since people will now run TS by default without type checking. Wasting so much time chasing weird runtime errors - j
8.
by primering 1y ago
Yes, they regret them because they hinder adoptions. Why? Because nobody chose to add TSC with all features in their runtime because TSC is extremely slow. They know they can skyrocket adoption by limiting the language. That's the reas
9.
by primering 1y ago
There is always a compile step (JS -> Bytecode -> Machine code). The question is only if it is visible to you or not. They could have made it totally transparent to you by fully support TS including type checking under the hood includ
10.
by primering 1y ago
This is misleading. It is not transpiling TS in JS, it is transpiling a subset of TS into JS. If my normal TS code can not be "executed" by Node, then it is not executing TS per definition but something else. If you are good with
11.
by primering 1y ago
Except it doesn't. In anything serious, you have to wait for a full type check to happen before you run your TS code. Why would you run code that has not been checked yet and could throw very weird errors like undefined property access
12.
by primering 1y ago
> because I find it's useful How useful is it exactly that you accept to not use DX improving syntax like constructor properties, enums, etc? To me, someone who uses these features _a lot_, this would be a terrible trade. Seems more
13.
by primering 1y ago
It's not able to execute TypeScript, but a subset of it. The claim in the title is misleading if not totally wrong. This will unfortunately drive people towards using TS only as a linter, and not use its powerful features that are inhe
14.
by primering 2y ago
you are probably right, but you know it's just that I really want to have a crazy fast typescript checker myself but can not justify the work when I know either nobody else will use it or those who use it steal my time without giving a
15.
Ask HN: Would you pay for 100x faster TypeScript type checker?
12 points by primering 2y ago|18 comments
16.
by primering 2y ago
That's really cool! Would love to use it in my c++ projects. One thought that came to my mind: How is the performance? Could you render a relatively complex page at high frames per seconds? I usually use ImGUI which is excellent to dis
17.
by primering 4y ago
It makes the types available in runtime. You can take a look at the current WIP version of the new upcoming Deepkit book which explains it in great detail: https://deepkit-book.herokuapp.com See section "2. Runtime Types&qu
18.
by primering 4y ago
If people say this is a modern version of Spring Boot, then I'm all for it.
19.
by primering 4y ago
To be honest, I don't think NestJS is even remotely comparable to anything like Symfony/Laravel.
20.
by 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.
21.
by primering 4y ago
I'm really bad at marketing, but I regularly tweet [0] and chat with the discord [1] community. I'm trying keep the followers up to date with the C++ typescript stuff. Feel free to join [0] [url-redacted] [1] [url-redacted]
22.
by primering 4y ago
thank you so much!
23.
by primering 4y ago
Can you explain why this gives headache to scale? I ask because it is designed to scale well.
24.
by primering 4y ago
Curious, why would this be related to Deno?
25.
by primering 4y ago
It's not an anti-pattern to reuse types, it's an anti-pattern to apply something you don't need or apply too much of it, which is exactly what you are talking about. There is of everything a "too much". It's up
26.
by primering 4y ago
Good point. That's why I'm working on a C++ version of TypeScript's type checking./computation so it can be used in all languages. That would allow us to use TypeScript types literally everywhere and remove that barrier.
27.
by primering 4y ago
They surely can be used in the app, but a) requires that code generation and b) you are limited by the expressiveness of Prisma's DSL. The DSL supports much less than TypeScript. The last time I looked: No support for generics, conditi
28.
by primering 4y ago
Yeah, I thought about that, too. Will probably do that, thanks! //edit: I just did that
29.
by 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
30.
by primering 4y ago
Thank you!

More ›