Discussion on: Reasons I'll never use Deno

[4r7d3c0]

how do you mean various npm packages? what would you need apart from actual typescript? aren't packages compiled into js with types.d.ts provided so that you don't really need anything.

// JSDoc Style
/** @type {Error[]} */
const errors = [];

// TypeScript
const errors: Error[] = [];

this i get 100% it's more natural to flow types like that (for PRIVATE code). Yet I still don't mind to write the first kind if it spares me installing 50mb binary :P

yet when you come writing APIs, in both cases you need

/**
 * Returns an example.
 * @param {string} s The first part of the string.
 * @param {string} t The second part of the string.
 */
export default function example(s, t) {
 return `${s}.${t}`
}

I mean you could've do

export default function example(s: string, t: string) {
 return `${s}.${t}`
}

But then you're not generating full doc. Maybe it's not needed to have full docs with description of params, but I like it. In any way, I believe that documentation CAN be decoupled from code altogether so that you have your types defined completely independently of implementation, and can convert them into an interface in any language, be it js, ts, dart, go... the design stage i mentioned in the post involves object modelling, which can be split into Conceptual (business stakeholders), logical (db entities) and physical (data types). So that types are not even part of implementation. By taking a step back, we can take those out of the actual source code, and design "abstract" types. This means that we can then distribute those designs between members of the team, and they can communicate and work on them in their own time, such that the front-ender will do his job in JS/TS, and back-ender can work with the same data types in say Go or anything else and they'll be consistent with each other. there are many times web development is a one-man job, but for larger, and truly scalable projects we need a better approach :)

[Basti Ortiz]

I can't really argue against your separation of concerns (as in documentation and implementation). I actually agree with it. Unfortunately, it's really just a matter of taste when it comes to the discussion of syntax.

In regard to the "NPM packages" I mentioned, I will particularly note Webpack and Babel for more advanced TypeScript projects. Testing TypeScript is a whole other beast in and of itself, too. That's what I mean by TypeScript being a hassle in the default Node environment (compared to Deno).