marcjschmidt

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

> you won’t see anything like this that compiles to javascript

https://github.com/microsoft/TypeScript/issues/47658

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.

> 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 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.

No, initially they tried to trademark "Deepki" in the US. It was not me blocking that, the USPTO itself decided to block the application on the grounds of "likelihood of confusion" to which Deepki could have appealed, but they did not. I assume it's so blatantly similar, that even the USPTO clerk decided to block it right from the start.

lovely said! I think that's the right way to see things. somewhat forces me to give up on the mark, because nobody and nothing really cares about that in a few weeks, if not even days. On the other side, among the good things that you share while you are on this planes is making sure we live in justice. And I can't stop thinking about this being injustice. I could be entirely wrong though.

> "hmmmm, might be 99% non-EU, we don't care"

That is what fascinates me the most. The basic assumptions of everything I presented was non-EU. Somewhat annoying, but seeing it objectively, I think it was a skill issue on my lawyers side. They should have said to me "Marc, look, we need hard proof. Ask your fucking users on twitter, on github, an discord, we need a list of X users confirming they are from the EU and use this thing". I believe in good-will on the EU side, that they interpret data in a positive way in my favor - but the exact opposite happened.

Following this logic, does this mean if I have a project name like ABC, and some company decided to incorporate in this name plus registering the trademark, I have to give up the name when they decide to come after me? Like I have a github.com/ABC, a npmjs.com/org/ABC. All just gone, because trademarks right gives them the right, and I have nothing that protects me?

If that is the case, ok. It's just that I was naive enough to believe I could protect my little open-source project from this using a trademark. The EUPIO somewhat confirmed in their writing that you don't need commercial activities, but you need "genuine use", which is, again, hard to prove if you don't collect user data.

Right, but I think this case is interesting for the developer community as it targets specifically open-source use-cases, where you usually have neither extensive user per-country data, nor would you usually care about tracking, or have commercial offerings. This essentially means that you either cannot protect your open-source project name or have always to keep in mind to collect user per-country data, otherwise you risk getting deleted.

So, you would spend several thousands of dollars to register a trademark to protect it from other corporations, and then the first thing you would do is give out the right to said corporation for 1000 bucks? I'm not an expert, but that sounds like a bad deal to me and substantially weakens the mark.

No, I started to rename the repo and moved it to my personal account, out of frustration mainly. Not sure yet what the new name is going to be, or if I can keep the old one.

I've written Apache Foundation, Software Freedom Conservancy, Free Software Foundation, and OpenSource Initiative, and asked for help. We will see. If OSS has no value to our law makers and the trademark needs to be deleted, that's fine and I accept the loss. But I'm an open-source contributor since over decade and not only love the spirit, but my whole career is based on it. The last thing I can do is to fight for justice, even if it means I need help from bigger firms/initiatives.

That's a very good saying. I keep that in mind.

I wrote B corps an email highlighting the issue and asking if this actions align with their principles.

They seem to be very busy. It seems showing that your corporation accompanies positive social impact, fairness, and responsibility is in high demand.

> Thank you for reaching out and for you interest in the B Corp Movement! Despite our high ambition for an inclusive, equitable and regenerative economic system for all people and the planet; we are still a small team. So kindly allow us to come back to you within 2-3 weeks

> Due to a high level of inquiries recently, it may take us longer than usual to respond to your message. We will answer questions in the order received. Response times may be up to 2 weeks.

> decided to trademark your project name

I decided to protect the name because I liked it and wanted to build upon it in the future. Be it OSS, or further commercial offerings.

I hoped to get also protection against corporations that just try to register the name or very similar ones and then decided to get me deleted or sue me for infringements.

In EU it's first to file principle, which means whoever holds the mark, has the right. This means if I would not have registered it, the company could just register "Deepkit" or "Deepki" and sue me to death. Now that I lost the trademark (not totally final, I can appeal), I risk getting sued for having a too similar name - which is exactly what I tried to avoid by having a registered trademark.

Did I make some mistakes with appealing and not collecting enough user data? Likely. Was it too naive from me? Yes. But I think reasonable and the whole idea behind trademarks is to protect projects like this. I could be wrong though, am not an expert.

it's more like this:

- They started as small firm in France, registered there the trademark Deepki, unrelated to software.

- I created Deepkit around 2018, trademarked in US and EU with software category.

- They raised substantial amount of money around 2022 $150M

- Board/Shareholders likely decided that the brand is important

- They tried to register the US brand under software category. The USPTO declined automatically because of "likelihood of confusion"

- They reached out to me wanting a "Consent and Coexistence Agreement", I told them not for free, to which they never responded with an offer.

- They tried to register in EU later, which I tried to block under the same "likelihood of confusion" ground.

- They started fighting with legal terms to get my brand deleted.

- They succeeded.

It's not necessarily only their fault that the trademark is gone now. As I just learned, the EU requires very strict rules of proving you have legit users. I couldn't convince them. Maybe due to skill issues, missing data, or technicalities. The biggest danger is now though that they can get me deleted from the internet entirely once the protection is gone. It requires just one corporation to decide to start come after you with a cancellation process, and you are done.

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.