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.
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.
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. ORM maps relation data to your OOP data structures. They completely misused the term entirely, which is kinda surprising.
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 about that, like Prisma is doing
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.
> 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 - just to end up running the full blown TSC type checking again. They will also write very different TS now, trying to workaround the limitation and arguably very useful features like Enums, constructor properties, etc. This has real negative effects on your codebase if you rely on these, just because Node chose to support only a subset.
It's interesting to see the strategy now and to see people even gaslighting people into believing no type checks and less features is a good thing. All just because of one root cause - TSC being extremely slow.
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 reason they regret it. This is just a strategy to increase adoption. Not because they are bad features. They are in fact very useful, and you should not stop using them just because your favorite runtime decided to go the easy way and only supporting a subset of TS by stripping types. You should rather switch the runtime instead of compromising your codebase.
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 including support full TS and not this subset of it, but decided not to do so. There is nothing inherently great to have less compile steps if you are not even aware of it. See v8 how many compile and optimizations steps they have - You don't care, because you don't see it. The only problem of TS is, you will always be able to see it because of it being slow.
I think running TS without type checks is almost entirely pointless.
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 Node supporting and "executing" only a subset of TS and lacking useful features, that's fine. But don't tell people it is executing TypeScript. That's like me saying my rudimentary C++ compiler supports C++ while in reality only supporting 50%. People would be pissed if they figure it out once they try to run it on their codebase.
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?
That just doesn't make sense. Yes, you can wait for your editor in your current open file, if you are lucky and the change in the open file doesn't break anything downstream in another file that is not yet open. In best case you have such simple code that nothing breaks, and in worst case, you have to still run it with type-checking - on top of running it in type-stripping-mode, because you got weird errors in runtime. This is a net negative.
This whole situation is there because we are trying to workaround the slow TSC. It's not a feature, it's something we actively work around. We try to whitewash now the obviously less useful "solution" of running code without its core features enabled: type checking. To me this is insane.
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 like people push this out of ideology and because TS is never going to be part of node itself (since its implementation is just way too slow)
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 inherently impossible to implement with just type stripping.
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 anything ($) back
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 display real-time data without even thinking about performance issues. Compared to Chromium's web rendering which burns my CPU already at 10FPS simple DOM text updates, this could be a game changer.