4 ms·

That option already exists, and we found that most people we interviewed used it more often than the default.

by lucacasonato 4y ago

brundolf 4y ago
> we found that most people we interviewed used it more often than the default That's surprising/depressing, but kudos I guess for doing user research and listening to what the majority wants
- nicoburns 4y ago
  > That's surprising/depressing Why? TypeScript type-checking is slow. Furthermore it's common when refactoring code that you break code in many places, but that you want to run the code you are actively working on and iterate on it (perhaps further changing the shared types in the process) before going through and fixing uses of that code everywhere. As long as you have CI process enforcing the type checking, there's no real disadvantage to this approach.
  - brundolf 4y ago
    I think there's something to be said for shepherding an entire ecosystem into good practices. If people have to go out of their way to get their code checked, a lot of code with type errors will probably make it out into the world. Before Deno this was more tolerable because the ecosystem was so messy to begin with; libraries that lacked types, APIs that were never designed with types in mind. But Deno is in many ways a fresh start, and given that opportunity I'd prefer it if we said "typed and passing code is the default, you have to go out of your way if you want to violate that convention". It's a shame to leave the door wide open for a slow-rot of type failures, especially when Deno already supports plain JS files for the cases where you really need to skip writing types. I can understand eg. edge providers wanting to skip running the check every time a worker spins up, but I've never felt like checks were slow enough that they needed to be skipped in a dev environment (and therefore turned off by default)

4 ms·

That option already exists, and we found that most people we interviewed used it more often than the default.

by lucacasonato 4y ago

That option already exists, and we found that most people we interviewed used it more often than the default.

brundolf 4y ago
> we found that most people we interviewed used it more often than the default That's surprising/depressing, but kudos I guess for doing user research and listening to what the majority wants
- nicoburns 4y ago
  > That's surprising/depressing Why? TypeScript type-checking is slow. Furthermore it's common when refactoring code that you break code in many places, but that you want to run the code you are actively working on and iterate on it (perhaps further changing the shared types in the process) before going through and fixing uses of that code everywhere. As long as you have CI process enforcing the type checking, there's no real disadvantage to this approach.
  - brundolf 4y ago
    I think there's something to be said for shepherding an entire ecosystem into good practices. If people have to go out of their way to get their code checked, a lot of code with type errors will probably make it out into the world. Before Deno this was more tolerable because the ecosystem was so messy to begin with; libraries that lacked types, APIs that were never designed with types in mind. But Deno is in many ways a fresh start, and given that opportunity I'd prefer it if we said "typed and passing code is the default, you have to go out of your way if you want to violate that convention". It's a shame to leave the door wide open for a slow-rot of type failures, especially when Deno already supports plain JS files for the cases where you really need to skip writing types. I can understand eg. edge providers wanting to skip running the check every time a worker spins up, but I've never felt like checks were slow enough that they needed to be skipped in a dev environment (and therefore turned off by default)