[jondubois]

I don't particularly like TypeScript. It slows me down because of several reasons:

- Compile time means that it takes more time to debug anything.

- The rigid interfaces mean that I need to spend more time researching how to use various modules/libraries (maybe code completion would offset this problem but this is only possible with a heavy IDE that has intellisense or similar - Not Atom).

- When I want to test something quickly, I often get annoying compile-time errors along the lines of 'code is unreachable...' among others.

- It requires more planning to do anything (since you have to design the interfaces before you can start to implement). This is also not good if you just want to try something quickly and then roll back later.

- Changes to one class/interface tend to have a large cascading effect on other classes/interfaces so it takes more time to make changes to code - This happens with JS too but to a much lesser extent.

- Adds lots of unnecessary dependencies to my project.

- Complicates setup and DevOps tasks, Dockerizing, (E.g. due to version mismatches and thousands of other potential issues) etc...

The reason why I don't like heavy IDEs is because:

- They're slow and clunky (sometimes they freeze for a long time in order to index content)

- The use up a ton of memory.

- They make your team lazy when it comes to structuring your source code into proper folders (since you start to rely more on search features of the IDE to find things).

- They take ages to install.

- Support fewer operating systems.

- Are usually proprietary and difficult to customize.

- More prone to bugs.

[throwasehasdwi]

Your complaints against "heavy" IDE's don't make sense. All of the points you made either aren't valid or don't matter.

- They're slow and clunky Not anything I've used. Eclipse and Visual Studio run nice and smooth on a decent machine.

- The use up a ton of memory. Who cares. Slack and anything based on electron uses hundreds of megabytes. Chrome regularly uses gigs. Most of the IDE's I use take less than 500 megabytes of ram, even phones have plenty.

- They make your team lazy when it comes to structuring your source code into proper folders Absolutely not. Your reasoning is that making things easier = making code worse. The IDE you use has nothing to do with your dev culture

- They take ages to install. Some of them do, notably Visual Studio. All the other ones I've used just take a few minutes. Also, who cares??? You only have to install it once, what is 5 minutes for an app you're going to use for thousands of hours???

- Support fewer operating systems. No. IDE's based on java run on almost anything. Again I think you're speaking from the experience of using visual studio.

- Are usually proprietary and difficult to customize. Also no. Every IDE I've used supports plugins and an unholy amount of configuration options. Every IDE I use is open source, again except visual studio.

- More prone to bugs. What? Why? How?

[tukelully]

Alot of these things do matter and it seems to me like all you're doing here is excusing bloat via hyperbole. I don't even agree necessarily with a lot of the parent comment, but I disagree with yours.

[coldtea]

>The rigid interfaces mean that I need to spend more time researching how to use various modules/libraries

Why, otherwise you'd just throw random parameters in a module's functions and see what sticks?

>Compile time means that it takes more time to debug anything.

Most people compile their JS anyway, TS or not, with Babel et al.

>maybe code completion would offset this problem but this is only possible with a heavy IDE that has intellisense or similar - Not Atom

VS Code has code completion for TS and is similar to Atom. And even Sublime Text has code completion for TS (based on tools MS itself provides for "intellisense" style predictions).

>- It requires more planning to do anything (since you have to design the interfaces before you can start to implement). This is also not good if you just want to try something quickly and then roll back later

Doesn't make any sense. It's not as if you don't need to know the interfaces before you start to implement with regular js. Only there you need to hunt for the documentation to tell you what's expected to pass -- instead of seeing what the types are directly (e.g. with intellisense).

>- Changes to one class/interface tend to have a large cascading effect on other classes/interfaces so it takes more time to make changes to code - This happens with JS too but to a much lesser extent.

It happens to the exact same extend in JS. Only with TS you are shown where the problems are automatically, with JS you have to hunt those places or discover it at runtime.

The rest goes downhill...

[superninja234]

"It requires more planning to do anything. This is also not good if you just want to try something quickly and then roll back later."

Since you can pretty much type javascript in to a TS file and it will work I don't see this being valid.

Also planning is good, if your not thinking about the structure of your code (which does not take that long) then your just producing diarrhea.

[merb]

> - Compile time means that it takes more time to debug anything.

how can this be an issue? even javascript needs to be concated minified and whatever to take it into production. it's not like that any human writes minified and mangled javascript with direct gzip.

P.S.: I'm not a fan of TypeScript. But to say you need to compile it, is just an excuse.

[WorldMaker]

The Typescript compiler is also happy to run directly inside the browser because it is itself written in JS. I've debugged projects where the TS is compiled at runtime inside the browser and F5 refresh is the entire build process.

Though it's just as easy to use a good IDE's build button (VSCode Ctrl+Shift+B for instance) or TS works well as a watch process that watches for saves and compiles them when you save.

[leshow]

> - It requires more planning to do anything

That's the idea. You think about what you're going to write in a strongly typed language rather than just throwing stuff at the wall hoping that something will stick.

> - The rigid interfaces mean that I need to spend more time researching how to use various modules/libraries

I don't understand this. In one case you have an API where the types of all the functions is available, so you can see almost right away how to use it. In the other case you have to rely on someone providing you really good documentation OR you read the implementation.

> - Changes to one class/interface tend to have a large cascading effect on other classes/interfaces so it takes more time to make changes to code - This happens with JS too but to a much lesser extent.

It's either you find the error at compile time or at run time. Don't kid yourself, there's a 'cascading effect' in both typed and untyped codebases, just in the typed one the compiler will help you find errors.

Granted, I'm not the biggest TS fan, I'd take Elm or Purescript, or even Flow. But your gripes seem to be directed to typed languages in general.

[jondubois]

>> - It requires more planning to do anything

> That's the idea. You think about what you're going to write in a strongly typed language rather than just throwing stuff at the wall hoping that something will stick.

I think this is a valid point for developers who only have a few years of experience but I've been coding professionally for over a decade now - I don't need the compiler to artificially slow me down - I'd rather spend my mental energy thinking about the algorithm/architecture in its purest form without getting caught up in trying to satisfy the compiler's tedious requirements.

For me programming in a typed language is like using software that always asks you "are you sure you want to do this?" every time you tell it to do something. It's OK if you're a beginner, but I just find it frustrating.

I spent many years programming in ActionScript 3 and then Java so I feel like I've given typed languages a fair shot.

[leshow]

> I don't need the compiler to artificially slow me down

It's slowing you down because you've written code with errors. Those type errors are still in your dynamic code, you just can't see them.

> I spent many years programming in ActionScript 3 and then Java so I feel like I've given typed languages a fair shot.

I don't think you have, you've missed many wonderful modern type system features.

Algebraic types, for one, aren't present in either of those languages and are massively useful, replacing 'null' (with a type like Option/Maybe) and exceptions (with a Result/Either concept) in many languages that have them.

Not to mention, with a language that has type inference, you don't even have to write the type in many cases, and yet you keep the guarantees of a strongly typed language.

[coldtea]

>I think this is a valid point for developers who only have a few years of experience but I've been coding professionally for over a decade now - I don't need the compiler to artificially slow me down

You'd be surprised.

There's a reason that developers after decades of dynamic languages turn increasingly to types (of which Flow and TS are examples in the JS world).

[lilactown]

VS Code (equivalent to Atom in power and scope) has the best intellisense for typescript. I use it over full-fledged IDEs (Intellij IDEA) all the time.

[danielpatrick]

> The rigid interfaces mean that I need to spend more time researching how to use various modules/libraries (maybe code completion would offset this problem but this is only possible with a heavy IDE that has intellisense or similar - Not Atom).

Obviously, to each his own.

I'd encourage you try Typescript again though. Your given reason doesn't make much sense. Regardless of whether the language is strongly typed or weakly typed, you still need to use modules and libraries correctly. "Not having to research" means you're just going to end up throwing data at a library without knowing what it's expecting. The research has to happen in both scenarios, but with typed languages it's easier. The research is just in the code already. (Try VS Code, not a "heavy" IDE by any means, but it has native support for TS code completion.)

If I have any modular interface, you need to know what to pass me. If you're receiving data from me, you need to know the structure of what I'm sending back to you.

In a weakly typed language, you can guess at what data structure I'm going to want. You can fish around in my returned data for what you're looking for with no guarantees. You have to look for docs, which may or may not be up to date.

But in a strongly typed language, the code is the doc. You and I and your IDE and my IDE are all on the same page. And the docs are always up to date. You can't pass me data that I'm not expecting and you always know how to access the data I'm returning to you.