4 ms·

Lots of love here for TS. I'd like to share my personal experience with it: I went from "fast and convenient" with JS to constantly fighting against the TS comp

Lots of love here for TS. I'd like to share my personal experience with it: I went from "fast and convenient" with JS to constantly fighting against the TS compiler and linter above cryptic type errors. Man, was it frustrating and JS felt suddenly crippled because it was hard to use its dynamics. TS catched a mistake here and there - true - but that did not equal out the hours burned by writing and debbugging type structures. In the end I removed every bit of TS from my projects and continued happily without it. I found out that using JSdoc comments and relying on the linting abilities of my IDE plus writing unit tests gave me stable code as well, without pulling my hair out. I was there before TS and just went back to it. I get that TS may be a good idea if you deal with teams of mediocre devs to prevent they do stupid things but by talking with a couple of JS devs and looking at my own JS experience it seems like the desire of using TS vanishes if you reach a certain experience ans confidence using vanilla JS. It looks like the most people who embrace TS see JS as some kind of inferior thing, anyways - but that might just be a wrong observation by me.

PudgePacket 8y ago
Damn, a sweeping generalisation if ever I've seen one. Are all the people using c++, java, haskell just mediocre devs because they like the safety brought by a type system over lisp or python? Microsoft, Facebook, and Google all wrote either a type system over JS or a JS alternative because of the problems they faced with vanilla JS. Facebook is even doing both ‍️. Perhaps spending some time looking at how certain libraries write their type definitions will help you learn how to use them, if you're constantly fighting you are probably missing some fundamental concept that TS operates with. TS has also gotten much better at expressing more complex types over time and there are still more things on the roadmap. For me TS only grows more useful as the size of the codebase increases. It allows safe refactorings you could only dream of in a large JS codebase.
wwwigham 8y ago
> I went from "fast and convenient" with JS to constantly fighting against the TS compiler and linter above cryptic type errors Would you, perchance, be able to share an example of such an error? We generally strive to improve error clarity where possible~ > I found out that using JSdoc comments and relying on the linting abilities of my IDE Ah. Well, spoiler alert: if your IDE is vscode or VS that JSDoc is actually still getting typechecked by TypeScript ;)
- z3t4 8y ago
  Do you have a list of common errors that TypeScript usually will detect ?
h1d 8y ago
> TS may be a good idea if you deal with teams of mediocre devs to prevent they do stupid things I don't consider myself a mediocre dev but I can still do stupid things and TS tells me before I run it. > It looks like the most people who embrace TS see JS as some kind of inferior thing JS does feel inferior once you use TS. You sound like you're just used to your workflow if you had to pull hairs out by just using TS.
Sammi 8y ago
I don't understand how people do refactoring without static typing. If I change a function parameter in Typescript then I get compiler errors for each use. Awesome. With plain Javascript I have to run the program and get it into executing all those different invocations and hope I get meaningful errors at runtime. A nightmare. In my experience Javascript code bases end up being "add new code only", because changing anything is just too dangerous, because type errors are so hard to find. So after a while of several people working on the code base it just becomes a bloated spaghetti mess that cannot be untangled, because refactoring is nigh impossible.
- z3t4 8y ago
  There are some tricks you can do in order to break up the code base to make it more manageable using the plugin and module patterns. Each part of the code that can be useful in other code bases you can break up into modules. For example a Vector library if you are making a game. It's OK to move out even small functions if they are common enough, like the famous leftpad module. Next step is the plugin pattern, where each plugin is totally independent of other plugins, where the plugins communicate to the main codebase via an API. The third trick is to move complexity to the architecture, meaning that some part(s) of your system, often a bottle-neck that need to be horizontally scaled - is moved out into it's own code-base aka micro-service. Now it will be much easier to refactor, you can for example write the module, plugin or micro-service in another language. I've done my fair share of managing code bases with 10k LOC of spaghetti where a change of one parameter can break code at 100 other places, but thankfully there are better ways. Then there's the fifth trick that is an old JavaScript convention, that if you do change a parameter, you also make it so that you can use the public function as before in order to not break stuff, that's the true power of dynamic JavaScript, for example if your function takes three arguments, and the first two is optional, it should be possible to call the function with only one argument, and the function will figure out what parameter belongs where. Then if there's an error in the parameters, the function should throw early with a nice human readable error, debug data/dump and stack. Also see defensive programming. Then the sixths tip is testing. After a certain point, when it takes longer to manually test, then it takes to code, it's time to introduce automatic testing. It doesn't have to be unit tests. It can for example be regression test, meaning that for every bug you find, you write a test that would automatically have found that bug - before actually writing the bug fix! Then the next step is to write integration tests (not sure about the name), where the code functionality is tested from the outside, for example in a web app a button is auto-clicked, then the DOM state is checked to make sure everything is correct. There are a ton of different types of tests you can apply, for example perf-test that make sure the performance has not degraded.
dlojudice 8y ago
> plus writing unit tests gave me stable code as well, without pulling my hair out apart from the generalization i tend to agree from uncle bob's article [1]: > My own prediction is that TDD is the deciding factor. You don’t need static type checking if you have 100% unit test coverage. And, as we have repeatedly seen, unit test coverage close to 100% can, and is, being achieved. What’s more, the benefits of that achievement are enormous. I've worked on high mantainable big JS projects (+40 devs) with 80%-90% test coverage. plus we were using GraphQL so inputs were valid types somehow. if I start a new project today I would use only these technics (valid inputs + integration test) with no typed lang. [1] http://blog.cleancoder.com/uncle-bob/2016/05/01/TypeWars.html http://blog.cleancoder.com/uncle-bob/2016/05/01/TypeWars.htm...
Zooper 8y ago
I agree, the only reason I can see for TypeScript's existence is that people were coding poorly. Many of the mistakes people claim to have made as a result of dynamic typing, I simply did not make because I learned dynamic first, then static second. Also, it's solved by literally 1 test, and people are touting an extra compilation step with errors to solve that problem. This eco-system is a poisoned-well of bloat, and I'll be redoubling my efforts with Rust to leave it as soon as possible.

PudgePacket 8y ago

Damn, a sweeping generalisation if ever I've seen one. Are all the people using c++, java, haskell just mediocre devs because they like the safety brought by a type system over lisp or python? Microsoft, Facebook, and Google all wrote either a type system over JS or a JS alternative because of the problems they faced with vanilla JS. Facebook is even doing both ‍️. Perhaps spending some time looking at how certain libraries write their type definitions will help you learn how to use them, if you're constantly fighting you are probably missing some fundamental concept that TS operates with. TS has also gotten much better at expressing more complex types over time and there are still more things on the roadmap. For me TS only grows more useful as the size of the codebase increases. It allows safe refactorings you could only dream of in a large JS codebase.

wwwigham 8y ago

> I went from "fast and convenient" with JS to constantly fighting against the TS compiler and linter above cryptic type errors Would you, perchance, be able to share an example of such an error? We generally strive to improve error clarity where possible~ > I found out that using JSdoc comments and relying on the linting abilities of my IDE Ah. Well, spoiler alert: if your IDE is vscode or VS that JSDoc is actually still getting typechecked by TypeScript ;)

z3t4 8y ago
Do you have a list of common errors that TypeScript usually will detect ?

h1d 8y ago

> TS may be a good idea if you deal with teams of mediocre devs to prevent they do stupid things I don't consider myself a mediocre dev but I can still do stupid things and TS tells me before I run it. > It looks like the most people who embrace TS see JS as some kind of inferior thing JS does feel inferior once you use TS. You sound like you're just used to your workflow if you had to pull hairs out by just using TS.

Sammi 8y ago

I don't understand how people do refactoring without static typing. If I change a function parameter in Typescript then I get compiler errors for each use. Awesome. With plain Javascript I have to run the program and get it into executing all those different invocations and hope I get meaningful errors at runtime. A nightmare. In my experience Javascript code bases end up being "add new code only", because changing anything is just too dangerous, because type errors are so hard to find. So after a while of several people working on the code base it just becomes a bloated spaghetti mess that cannot be untangled, because refactoring is nigh impossible.

z3t4 8y ago
There are some tricks you can do in order to break up the code base to make it more manageable using the plugin and module patterns. Each part of the code that can be useful in other code bases you can break up into modules. For example a Vector library if you are making a game. It's OK to move out even small functions if they are common enough, like the famous leftpad module. Next step is the plugin pattern, where each plugin is totally independent of other plugins, where the plugins communicate to the main codebase via an API. The third trick is to move complexity to the architecture, meaning that some part(s) of your system, often a bottle-neck that need to be horizontally scaled - is moved out into it's own code-base aka micro-service. Now it will be much easier to refactor, you can for example write the module, plugin or micro-service in another language. I've done my fair share of managing code bases with 10k LOC of spaghetti where a change of one parameter can break code at 100 other places, but thankfully there are better ways. Then there's the fifth trick that is an old JavaScript convention, that if you do change a parameter, you also make it so that you can use the public function as before in order to not break stuff, that's the true power of dynamic JavaScript, for example if your function takes three arguments, and the first two is optional, it should be possible to call the function with only one argument, and the function will figure out what parameter belongs where. Then if there's an error in the parameters, the function should throw early with a nice human readable error, debug data/dump and stack. Also see defensive programming. Then the sixths tip is testing. After a certain point, when it takes longer to manually test, then it takes to code, it's time to introduce automatic testing. It doesn't have to be unit tests. It can for example be regression test, meaning that for every bug you find, you write a test that would automatically have found that bug - before actually writing the bug fix! Then the next step is to write integration tests (not sure about the name), where the code functionality is tested from the outside, for example in a web app a button is auto-clicked, then the DOM state is checked to make sure everything is correct. There are a ton of different types of tests you can apply, for example perf-test that make sure the performance has not degraded.

dlojudice 8y ago

> plus writing unit tests gave me stable code as well, without pulling my hair out apart from the generalization i tend to agree from uncle bob's article [1]: > My own prediction is that TDD is the deciding factor. You don’t need static type checking if you have 100% unit test coverage. And, as we have repeatedly seen, unit test coverage close to 100% can, and is, being achieved. What’s more, the benefits of that achievement are enormous. I've worked on high mantainable big JS projects (+40 devs) with 80%-90% test coverage. plus we were using GraphQL so inputs were valid types somehow. if I start a new project today I would use only these technics (valid inputs + integration test) with no typed lang. [1] http://blog.cleancoder.com/uncle-bob/2016/05/01/TypeWars.html http://blog.cleancoder.com/uncle-bob/2016/05/01/TypeWars.htm...

Zooper 8y ago

I agree, the only reason I can see for TypeScript's existence is that people were coding poorly. Many of the mistakes people claim to have made as a result of dynamic typing, I simply did not make because I learned dynamic first, then static second. Also, it's solved by literally 1 test, and people are touting an extra compilation step with errors to solve that problem. This eco-system is a poisoned-well of bloat, and I'll be redoubling my efforts with Rust to leave it as soon as possible.