3 ms·

Strict typing isn't always desirable, depending on the application of the language. With it you give up a certain level of developer productivity; appropriate i

Strict typing isn't always desirable, depending on the application of the language. With it you give up a certain level of developer productivity; appropriate if you're using Javascript for backend logic with Node, not so much if you're building simple views with React.

slackingoff2018 9y ago
I don't think so, or at least it doesn't feel like it. Typescript's type inference is so good that you only need types maybe 15% of the time. It also has shortcuts like constructor property initializers and support for async even when targeting ES5. I would bet money that you actually write less code with Typescript than regular javascript because of all the streamlining and shortcuts. And with the type inference you almost get static typing for free. I hear this argument come up frequently against TS and all I can say is I'm fairly sure it's from people that haven't used it.
- fearface 9y ago
  Sometimes it's also from people who use JavaScript in a more functional context, e.g. with currying. Suddenly it requires a lot of effort to still have TypeScripts benefits. https://gist.github.com/donnut/fd56232da58d25ceecf1 https://gist.github.com/donnut/fd56232da58d25ceecf1
  - tomelders 9y ago
    I've been working with Typescript for the past six months. Javascript is starting to shine as a functional programming language, and the communities who develop the useful tools that we actually need are moving in that direction too. Typescript feels like a step in a completely different direction. The problems that TS tries to solve have other solutions. Solutions more idiomatic to javascript development. Redux style architectures, grouping code by feature, libraries over frameworks, GraphQL and so on. And these solutions are solid and dependable. Unlike the made up brittle and often incorrectly defined types that Typescript and Flow demand. If you want to use Typescript, then I hope you really really REALLY like Generics, because they're absolutely everywhere in Typescript. They're the solution to the fundamental flaw with TypeScirpt, it wasn't designed with the actual job that Javascript does in mind. It's Javascript for people who don't like Javascript and don't care to learn it. Well that's fine, each to their own. But people sing it's virtues without pointing out any of the flaws in both the approach or the implementation (maybe because they simply don't see anything wrong), and that really rustles my jimmies.
    - abritinthebay 9y ago
      It absolutely is a step in a different direction. Not a bad one, but very intentionally different. I personally prefer a style/practice that doesn’t work well with TS, but I appreciate it exists and typedef files for libraries are very nice for developing in things like VSCode.
root_axis 9y ago
> you give up a certain level of developer productivity IMO the opposite is true; without types you give up some developer productivity in the form of time spent writing tests and debugging issues that the type system would obviate automatically. In my view, loose typing adds the illusion of productivity because the developer might presume they are working faster because they don't have to reason about type restrictions, however they simply end up enforcing type restrictions manually (and relatively poorly compared to a solid type system) using "typeof" and "instanceof" checks throughout their code. In general, assigning multiple types to the same variable is considered a code smell anyway, so strict typing simply enforces what is already considered a best practice. Of course, this doesn't mean that choosing typescript in particular is always the right engineering decision, but, all other things being equal, a strict type system is almost always preferable to a loose one.
- cloakandswagger 9y ago
  Maybe it just depends on the application. I've been doing frontend development with React and vanilla Javascript for the past 2.5 years, and I can't recall a single user-facing bug caused by improper dynamic typing.
  - root_axis 9y ago
    I would push back on the idea that it depends on the application, I think what's more likely happening is that your experience has codified best practices that help to minimize these types of bugs, but you're still manually doing the work to protect against these error with typeof/instanceof and unit tests that validate input parameters.
dahart 9y ago
> Strict typing isn't always desirable... you give up a certain level of developer productivity I mostly agree, I just wanted to point out that it's funny (to me, anyway) that the same argument applies in both cases. If you don't have type scripting, you also give up a certain level of developer productivity. When you have to hunt down type bugs a linter or compiler would have caught, you can waste large amounts of time. I think type bugs are usually fast to find & fix, and only occasionally take time. I like using a type checker of some sort (Closure compiler is probably my fave) for release builds, and leave it off for dev builds. I like this option even more than TypeScript, because you don't necessarily need to have a build step for running dev code at all. Then you get the best of both worlds, you can iterate quickly without adding or checking types, then you can spend a little time checking types before merging a branch. Any time a mysterious bug pops up, first order of business is check types. Even for React, I'd still rather have the option to type check than not have it. Flow is nice because once setup & running, it's really fast. I've seen it catch long standing type bugs that nobody thought were there.
fortythirteen 9y ago
You can always use the "any" type in TypeScript.
ng12 9y ago
Typescript has a config option (allowJs: true) that does exactly this -- types where you want them, regular ES6 when you don't. I type things like component Props/State, reducers, global state, and domain models. For everything else I tend to use regular, idiomatic JS.

slackingoff2018 9y ago

I don't think so, or at least it doesn't feel like it. Typescript's type inference is so good that you only need types maybe 15% of the time. It also has shortcuts like constructor property initializers and support for async even when targeting ES5. I would bet money that you actually write less code with Typescript than regular javascript because of all the streamlining and shortcuts. And with the type inference you almost get static typing for free. I hear this argument come up frequently against TS and all I can say is I'm fairly sure it's from people that haven't used it.

fearface 9y ago
Sometimes it's also from people who use JavaScript in a more functional context, e.g. with currying. Suddenly it requires a lot of effort to still have TypeScripts benefits. https://gist.github.com/donnut/fd56232da58d25ceecf1 https://gist.github.com/donnut/fd56232da58d25ceecf1
- tomelders 9y ago
  I've been working with Typescript for the past six months. Javascript is starting to shine as a functional programming language, and the communities who develop the useful tools that we actually need are moving in that direction too. Typescript feels like a step in a completely different direction. The problems that TS tries to solve have other solutions. Solutions more idiomatic to javascript development. Redux style architectures, grouping code by feature, libraries over frameworks, GraphQL and so on. And these solutions are solid and dependable. Unlike the made up brittle and often incorrectly defined types that Typescript and Flow demand. If you want to use Typescript, then I hope you really really REALLY like Generics, because they're absolutely everywhere in Typescript. They're the solution to the fundamental flaw with TypeScirpt, it wasn't designed with the actual job that Javascript does in mind. It's Javascript for people who don't like Javascript and don't care to learn it. Well that's fine, each to their own. But people sing it's virtues without pointing out any of the flaws in both the approach or the implementation (maybe because they simply don't see anything wrong), and that really rustles my jimmies.
  - abritinthebay 9y ago
    It absolutely is a step in a different direction. Not a bad one, but very intentionally different. I personally prefer a style/practice that doesn’t work well with TS, but I appreciate it exists and typedef files for libraries are very nice for developing in things like VSCode.

root_axis 9y ago

> you give up a certain level of developer productivity IMO the opposite is true; without types you give up some developer productivity in the form of time spent writing tests and debugging issues that the type system would obviate automatically. In my view, loose typing adds the illusion of productivity because the developer might presume they are working faster because they don't have to reason about type restrictions, however they simply end up enforcing type restrictions manually (and relatively poorly compared to a solid type system) using "typeof" and "instanceof" checks throughout their code. In general, assigning multiple types to the same variable is considered a code smell anyway, so strict typing simply enforces what is already considered a best practice. Of course, this doesn't mean that choosing typescript in particular is always the right engineering decision, but, all other things being equal, a strict type system is almost always preferable to a loose one.

cloakandswagger 9y ago
Maybe it just depends on the application. I've been doing frontend development with React and vanilla Javascript for the past 2.5 years, and I can't recall a single user-facing bug caused by improper dynamic typing.
- root_axis 9y ago
  I would push back on the idea that it depends on the application, I think what's more likely happening is that your experience has codified best practices that help to minimize these types of bugs, but you're still manually doing the work to protect against these error with typeof/instanceof and unit tests that validate input parameters.

dahart 9y ago

> Strict typing isn't always desirable... you give up a certain level of developer productivity I mostly agree, I just wanted to point out that it's funny (to me, anyway) that the same argument applies in both cases. If you don't have type scripting, you also give up a certain level of developer productivity. When you have to hunt down type bugs a linter or compiler would have caught, you can waste large amounts of time. I think type bugs are usually fast to find & fix, and only occasionally take time. I like using a type checker of some sort (Closure compiler is probably my fave) for release builds, and leave it off for dev builds. I like this option even more than TypeScript, because you don't necessarily need to have a build step for running dev code at all. Then you get the best of both worlds, you can iterate quickly without adding or checking types, then you can spend a little time checking types before merging a branch. Any time a mysterious bug pops up, first order of business is check types. Even for React, I'd still rather have the option to type check than not have it. Flow is nice because once setup & running, it's really fast. I've seen it catch long standing type bugs that nobody thought were there.

fortythirteen 9y ago

You can always use the "any" type in TypeScript.

ng12 9y ago

Typescript has a config option (allowJs: true) that does exactly this -- types where you want them, regular ES6 when you don't. I type things like component Props/State, reducers, global state, and domain models. For everything else I tend to use regular, idiomatic JS.