I look at coding as the right tools for the right job. I'm not sure about Deno — my job doesn't involve a lot of JavaScript on the server or client at the moment; I also feel that servers are better handled by closer-to-the-metal structures. However, I disagree on TypeScript for one fundamental reason: It's easier to fail-safely.
Development is hard. Debugging and testing is hard. This is why we can command significant salaries for what is basically turning requirements into machine-langauges. If it was easy, there'd be an automated way to do that translation, but because of the inevitable number of moving parts, it needs a lot of thought, attention to detail and consideration before a simple requirement statement can become something that runs on a client or a server; and that's before you start looking at OWASP or other security requirements.
TypeScript makes it harder to make stupid mistakes. Type Security makes it harder to make stupid mistakes, is a better way of saying things. The default is to go, "Oh — this is wrong, did you really mean that?" I want that in my life, because I want to have the 'easy' to check stuff checked for me, I don't want to have to remember to write a unit test just to make sure that internal movements are right. That's the equivalent of contract testing, and should be automateable. TypeScript gives me that.
I don't really have an opinion on the other parts — I approve of more tools, but I don't see TS or JS as server-side suitable tools at their heart. They've been used that way, and they make amazing utilities and tooling, which constantly impresses me.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I look at coding as the right tools for the right job. I'm not sure about Deno — my job doesn't involve a lot of JavaScript on the server or client at the moment; I also feel that servers are better handled by closer-to-the-metal structures. However, I disagree on TypeScript for one fundamental reason: It's easier to fail-safely.
Development is hard. Debugging and testing is hard. This is why we can command significant salaries for what is basically turning requirements into machine-langauges. If it was easy, there'd be an automated way to do that translation, but because of the inevitable number of moving parts, it needs a lot of thought, attention to detail and consideration before a simple requirement statement can become something that runs on a client or a server; and that's before you start looking at OWASP or other security requirements.
TypeScript makes it harder to make stupid mistakes. Type Security makes it harder to make stupid mistakes, is a better way of saying things. The default is to go, "Oh — this is wrong, did you really mean that?" I want that in my life, because I want to have the 'easy' to check stuff checked for me, I don't want to have to remember to write a unit test just to make sure that internal movements are right. That's the equivalent of contract testing, and should be automateable. TypeScript gives me that.
I don't really have an opinion on the other parts — I approve of more tools, but I don't see TS or JS as server-side suitable tools at their heart. They've been used that way, and they make amazing utilities and tooling, which constantly impresses me.