I feel like Typescript is hindering me more than helping me...

I've never been a fan of Typescript. I'm working on a ionic project (that uses Typescript then) recently and I can confirm I still don't like it that much...

It actually hinders me. Once in a while I get prompts of silly Typescript errors that make no sense at all, and I find myself wasting time on google just to put the right configuration at the right place and so on...So far my experience with Typescript has only been frustrating and a wastage of time. The thing is, if I group all these "wtf? gota google that weird stuff" moments I'd have built the app already with vanilla JS.

Not sure how that thing is so popular. I like typed programming languages as much as I like JS, but the experience typescript offers is more frustrating. Maybe I am doing something wrong...

This is one of the shorter, yet more useful, responses on this thread. Very rarely does typing result in something being a bug that would otherwise be okay. Much of the time, it reveals something deeply broken in your assumptions about how a codepath works.

I once had to live with a codebase where occasionally something was a comma-separated string, other times it was an array, and many of the functions were written with an implicit toString() to reduce my array into a comma-separated string. It was passed around inside a mongodb, sometimes as an array and other times embedded deep in a nested object. It would get serialized to the frontend into json, where sometimes the client would have a string and sometimes an array. Methods that existed on both String and Array would run (like includes), and sometimes give the correct result if it just happened to be a string, and sometimes wouldn't (e.g. [1, 22, 3].includes(2) === false, but '1,22,3'.includes(2) === true.

For the dev who wrote it, his code "worked", but did it really? Experienced devs know that "working" isn't a binary state. Any updates we wanted to make would be a pain, accounting for all the weird state mutations that could flip this thing from being an array or a string. We'd have to put wrappers around any access to this thing, and check for type before using it. New code could do that, but old code would need to be refactored. We could go and "fix" old code so it would consistently treat it like an Array, except that many use cases actually relied on this thing being broken for them to "work".

I would have been much, much happier had his shitty code failed from the start. It would have cost him maybe 3 seconds of typing the first time he wrote the code, and probably saved at least 5 minutes by the time he committed it.

occasionally something was a comma-separated string, other times it was an array

To be fair, there's already something wrong with the practices of this developer anyways. A function that sometimes takes one type of data and sometimes another is already a bad idea and reveals a level of unskillness type safty cannot fix either.

I would guess that it was not a single person that decided this was a good idea, but rather a collection of different people or teams trying to design solutions to problems within the constraints they were working with at the time over the course of the life of that body of software.

By attributing the blame to a single, imaginary bad developer we lose sight of the idea that the systems we work on are large and span multiple process boundaries (data in js in memory -> serialized to a format for the network -> serialized to disk in a database -> read from another system on another computer, etc). Of course everyone wants their code to be clean, to have single well scoped behaviors like a function that always accepts or returns data of one type, but we sometimes have to come up with solutions that more closely model the reality of the problem we're dealing with than the problem we want to solve.

If we blame the person that committed the code, we'll never be able to untangle the tech debt that's already bogging down a system.

Sometimes I was the bad developer that wrote the bug (actually, I always am). But I'm also the developer who finds the bug later. If you fire me for writing bugs, your software will always be broken.

It's incredibly common, though, and often less a result of "this was intentional" and more "this made sense at the time". Code debt is a real thing for projects with changing requirements and many developers.

I've worked with incredibly smart people in startups that had this sort of depth. We were acquired by a tech giant. The others were frankly geniuses - of course they knew the code had issues, but software engineering in real world is always about keeping debt manageable - not eliminating it.

I feel like these situations could be solved with unit testing. The benefits of writing actual unit tests are far greater than a typing system since you can make much greater assumptions than “is the output an array?”

I had to deal with that exact same situation where a dev was all about “It works on my machine” and produced some really garbage ad hoc spaghetti code. His code was bad because he was too lazy to write robust code and was more interested in closing as many tickets as possible to get praise from project managers. Switching to Typescript would have just made him change his params and returns to “any” and keep pulling the same crap.

I think the only true solution is to have robust automated tests that run before each merge. That way you can account for things like inconsistent source data formats if you discover them to be a known quantity.

Typescript is a catch-22. I don’t have to worry about crap code because I write jsdocs on each function that explicitly state that input should only be a string or a certain object and output is going to return a promise that resolves a number. Knowing this, I can police myself to make sure that is always the case and even write some tests to make sure that this assumption is always correct.

This is because I made a conscious effort to organize my code, and if a developer is fully embracing typing, then they are likely to do the same thing without the tooling. Devs who don’t organize their code are likely to cheat typescript to just “get it done” and return generic objects or use “any” if the toolset ever gives them friction.

I don’t have to worry about crap code because I write jsdocs on each function that explicitly state that input should only be a string or a certain object and output is going to return a promise that resolves a number.

I think you've missed the point of what he said about devs who "cheat" typing. We see this throughout development. Force developers to write unit tests and you see a bunch of expect(true).toEqual(true). Force them to use linting and you find a bunch of /* eslint-disable */ in your files. You see it on PropTypes in react where people just put .any on everything. That kind of mentality is all over the place, especially in large development shops with lots of contractors and tight deadlines.

I'm not saying don't use the tools, but be aware that they're not a panacea. Dogma isn't helpful. All these tools become less valuable when you don't have a culture that promotes them in the right way. You also have to identify where the boundaries are and which boundaries might be softer than others.

I'm not really debating that. I think it's more a cultural issue, identifying the pain-points of a tool, and promoting best practices than it is specifically a tooling problem inherently.

For example - I know of a shop that is fixated on tooling. They're constantly looking at what better tools are out there. However, no matter what tools they provide their developers they are still producing sub-standard code. They fail to see that the tooling is not the challenge, the level of developer they are hiring and the culture of "get it done now" versus "get it done right" is killing them.

Mostly, I agree with you, but the misconceptions in the writing... They don't "cheat" typing, just the static type checks.

ES it self has types, remember? Array is a type, for example, and you can't cheat it to behave like a string (no, this is not a challenge for someone to re-implement a string through array :)

What they do "cheat" is the purpose of the tool. If you use TypeScript, do strict types (I don't like them, I wouldn't use TS), but if you just slap :any to every line of code, how about you just spare you the trouble of dealing with TS at all?

Arguably, TypeScript is for type checks, so either you use it fully, or not at all.

Half-assed usage just gives you the pain of supporting yet another language and tooling with none of the (not worth the cost, according to me) benefits of static type checks.

If that enforcement requires deviating from standard syntax, lacks support from third-party libraries, adds a build process that may not be necessary (in my case: nodejs doesn't require babel), and occasionally needs you to spend an hour googling for some weird edge case tooling configuration issues - is it really worth it?

It was a tongue in cheek decision to counter a false dichotomy with one of my own.

What?

Often I see the comfort of typing, or the tooling that comes with it, allow people to make nonsensical design decisions under the CYA guise of "the ide makes it easy to navigate the noise". This is the sort of thing that can lead to more bugs (through added complexity) and as many in here have mentioned it also leads to more time spent wrestling errors.

If you can write untyped code without falling prey to the classes of errors usually avoided by using types, then you should publish a book because people would pay good money to be able to do that as consistently as a compiler could without the overhead, both cognitive and build-time.

So I tend to agree with you. I've used Flow and TS before and found that it doesn't catch that much for my needs. That said, I think the vast majority of programmers for the vast majority of applications do run into these problems, and there's a certain risk vs. reward here. That is to say, while using TDD and a functional approach works in almost all cases for me, the risk that it may one day fail catastrophically in production might make using types the entire time worth it. Plus, there are just a lot of programmers who either don't understand or don't care to understand either of those concepts and want the language to hold their hand, and I think that's valid.

It's a little bit like saying "No one needs Rust because RAII in C++ will eliminate almost every kind of memory issue", but there are other benefits and it's not always possible or practical to use RAII 100% of the time.

"Plus, there are just a lot of programmers who either don't understand or don't care to understand either of those concepts and want the language to hold their hand, and I think that's valid."

I could be wrong, but I think that's why I was down-voted to oblivion. People want to encourage a breadth of knowledge.

Or they're greedy and these people want to work with juniors that read these things and want to program in the safest way possible, so they can do the seniors can do their job faster without fixing as many errors with juniors.

It's risk v reward. I understand the concern of "fail catastrophically" and if I were making a product that MUST NOT EVER FAIL, I wouldn't use JS, I would use C++ or one of it's fancy new similar languages [ie. Rust]. For web development and even data processing, a failure usually means having to re-run code. Maybe you'll lose a day of processing time. meanwhile how much development time did you save building in babel-preset-env. I'm willing to bet the cost savings would be much better for the preset-env team.

Strongly typed languages are a trade off between now and the future as in it's a pain in the ass when initially starting a project, but reduces complexity as the project grows since it's self documenting and tells you what parameters it takes and what it will return.

I partially disagree with this. Depending on the language I generally find strongly typed languages faster to get started with as the superior developer tools allow you to move faster, and this is especially true when interfacing with 3rd party libraries.

I agree with you though specifically when it comes to Typescript. There is a feeling of going against the grain when using Typescript and until most of the application structure is in place it feels a bit like an uphill battle. Still worth it though I think.

I've been sticking with ES6, myself, but if there was any single reason I would move to Typescript it'd be the static analysis. Having intellisense tell you exactly what that one property was called (along with some documentation even) is extremely valuable. The main thing that keeps me away from Typescript is just the messiness of it. Whenever I read it, I feel like I'm trying to read a book that a toddler's scribbled all over. I mean... those scribbles are the backbone of the intellisense but it seems to me that it's not worth it.

That doesn't sound so bad. Perhaps I should give it a second look. So basically it's javascript but you can give the compiler hints here and there to help out with the static analysis? You say you have to declare input parameters? That's acceptable but how many other type declarations are mandatory? And do you have to go full generics on it, declaring the type of the items in a list, for example?

So, I said “have”, but that’s actually not entirely true. TypeScript has two modes:

Strict - in this mode you are not allowed to have any “implicit any”s. This means that you have to annotate arguments to a function, since otherwise they would be of the “any” type. You also have to declare types on variables that you do not immediately assign a value to (e.g. if you do let foo and then assign to foo later).

Non-strict - when not running in strict mode, all valid JavaScript is also valid TypeScript. This is great! It means that you can easily convert an existing code base by adding TypeScript, and then slowly start adding type annotations to your function declarations.

And do you have to go full generics on it, declaring the type of the items in a list, for example?

Yes, e.g. Array is a generic type with 1 required argument. Thus you need to specify e.g. number[] (or Array<number>) and not just Array.

If you have a function that can work on any array, you can make it a generic function:

Thank you very much for the information! I have a feeling I'm slipping down this well and I'll find myself using TS here in a year or two. Though as someone who went down with the CoffeeScript ship, I'm a bit squeamish of transpiled JS languages.

You can set tsconfig with implicit any which means all types will be considered "whatever" that aren't explicitly typed (input parameters included). That being said you'll quickly turn into a crack addict writing interfaces, if I hit the period on my keyboard and a comprehensive list of methods and properties don't appear I go back to see why the object isn't typed.

Typescript can also check string constants as though they were types. We've got a c# backend that takes sql input parameters that define a complex tree structure of sql field names + sort + comparison operator + value. If in any callback you're writing you specify a string that doesn't exist as a field name on the table typescript will red underline the string. It's amazing.

I think in 2 years of using it the only "oh my god why isn't this working" bug I've had has been isolated to updating webpack configs and a couple rouge "as any" declarations in typescript. You don't realize how many silent errors you make until you use either flow or typescript.

The flip side to this is that when you are implementing your function, if you specify the return type in advance, your body must return the correct type.

In my opinion this is preferable, because some mistakes, like accidentally returning undefined, are prevented right away, rather than your Type | undefined” return type making its way deeper into your application.

You can define/declare types. I mean, it's a core function of the type system... who wants to do have everything inline? Even apart from the waste of space and typing, who wants to maintain code where you have to manually ensure that the types in various places/modules are the same?

I was thinking on this topic and it occurred to me... are there JS features you're unable to use in TS due to the need for types? An example that came to mind was variadic functions with parameters of multiple types, but further reading indicates that one's not impossible to achieve. I guess my question is... are you ever writing TS and think to yourself "man... this would be so easy in JS" - does it ever cause a road block you wouldn't otherwise experience if you were dealing with JS? Sorry to be so inquisitive - I'm heavily considering moving over.

Well, technically you can always use any to allow you to ignore types, but I don’t think that’s what you mean.

There almost certainly probably are instances like you suggest but that’s more likely if you’re writing some kind of functional utility library or something. There definitely are times where it would be “easier” to not bother with types, but that doesn’t necessarily make it a problem with TypeScript. It’s usually a gap in my knowledge which I then look (usually to the guy who sits to my left at work!) to fill.

If you’re thinking about switching, I would say just do it. It makes you think much more about what you’re actually doing when you construct a program, to the extent that I now visualise programs in my head slightly differently. There are plenty of other excellent benefits too, such as “squiggly line driven refactoring”, Type First Development, etc.

Having written JS for 6 years and TypeScript for 1, there is no way I would start another project (that wasn’t just a quick node script for automating something, perhaps) without TypeScript. And it gets better every release.

I think so. I’m not at a computer right now, so I can’t say this with absolute certainty. But I have been telling myself for a while that I add the type annotations only because I like to practice Type Driven Development. So I usually define all of my contracts before working on the implementations. I’m like 99% sure that unless you are returning multiple types, or an optional or something though, type inference is gonna get you most of the way there.

What I don’t understand about typescript is the decision to go with the let varname : type syntax. If you’re going to make a strongly typed language & you’re going to have to transpile it to js anyway, why not just match the syntax of every other c-like language and use type varname declarations?

I spent many years writing AS2 & AS3 and the types always felt like a hacky addition there, too. Also, they used that syntax b/c declaring type was optional. There was a performance gain for using “strict mode” meaning you had to declare type, but if you were ok with a slightly slower app, the language handled dynamic typing just fine.

AFAICT, the only reason someone would want to use typescript instead of es2015 is static typing. Why allow dynamic type at all? Inferred type is fine, but it’s still static type at compile time.

I think you misunderstand. I have no problem with inferred type. I just don’t like the visual noise introduced by having the type declared after let varName. The let is superfluous when declaring a type. Compare:

let count : number = 0;
number count = 0;

Inferring type is also allowed in C#, Rust and Swift, but when not inferring, they all use Type nameto declare

1.) Functional languages generally use this syntax - it reads like a typed lambda statement. f -> (x:type, y:type2) : type3 2.) Removing the types to have an untyped function is a lot easier. f -> (x, y) 3.) Variable declarations can be typed or untyped without changing the syntax or introducing a specific keyword ("var", or "dynamic", or "auto", etc).

I started out a long time ago with C++ and I currently work with Javascript, Typescript, and C#. I'm used to the C-style syntax and I do like it, but the functional lambda-style syntax has grown on me quite a bit. I think I've come to like that the type definition is divorced from the declaration statement.

Interesting. I’m coming the other direction. Started with Actionscript (which used the same style as ts) then vanilla js for a long time, and now more C# and Java. Maybe it’s a case of liking what you’re using, but the languages feel so similar in other ways that it feels like a miss to me. When I use lambdas the return type is pretty much always inferred.

Should probably not have used the word mutable since I was talking about a mutable binding and not mutable data.

I do almost always use const, and I think that that should be the preferred style. Unfortunately it doesn’t look great, that ship has of course already sailed but I would have loved if we could have let as const works now, and var for how let works. That’s how it is in Swift, which I think is a beautiful language.

Of course we don’t need anything to replace var since that behavior is not needed at all.

Anyhow, I agree that we should use const in the majority of cases in TypeScript/JavaScript, that’s what I’m using at least...

I believe, from memory, that this makes type inference easier. I can't remember the details though! I think there was a discussion about it in the last year or so. Perhaps it just makes parsing easier. Can't quite remember. I do remember there being a good reason though that a lot of languages do it this way.

Read through it, but the explanations seem wrong to me. I still can't see how let i : int = 0; would be easier for either the IDE or compiler to parse than int i = 0;.

The main argument seems to be that the type identifier, because it's optional should come after the declaration, and it's easier to strip optional arguments that come after. I can grok that.

The problem with that argument is that there's an assumption that all variables need to be declared using var or let or whatever before the type declaration. In C# you use the typical Type name style declarations, but if you want to infer type you just declare as var name. This seems even easier for the compiler to parse b/c it doesn't have to look for optionals. The declaration is either explicitly typed or inferred, and that info is in the same spot every time, at the beginning of the declaration.

If the a language were to drop the requirement for let and instead prefer name : int = 0; I could see that being a valid argument. TS, though requires let or var or const just like es2015.

Did I just uncover the real reason TS prefers this format? Is it b/c of the block scoping difference between let and var? If so, that's an easy fix: kill var like all js best practices recommend doing anyway, and just assume a declaration wants to compile to let. Maybe that decision was made b/c when ES2015 hadn't been finalized, they wanted TS to be "just javascript" and the TS transpiler just looked for :s and stripped the next word.

Today the TS class structure is pretty different than that as TS class structure is not the same as ES2015 classes so they need to do some extra transpiling there anyway...

my bad, it's reducing ambiguity to the compiler, not the person writing the code :)

in the compiler it is not as singular as you might think. there are many rules of how to recognize what the code is meant to do.

think of the C++ example:

int a = 0

the compiler will have a rule that says: "if line starts with int, it is a declaration and the variable type is int" like, the type is there from the get-go, you can't alter it.

so they had to add another rule that said "if it starts with auto expect the variable type later on"

and because there are competing rules as to int* a, b, you migiht think it will declare two pointers a and b, but in fact it declares one pointer a and one integer b...

so, many competing rules in the compiler makes you get unexpected results.

user centered design is to not shove types in the programmers' faces like C++ i.e. let the compiler infer the type, you as a programmer shouldn't specify it is a string type since you already give it a value of 'some string'.

so, in user centric design, the type declaration isn't the most importaint thing, not to you, it's what you do with the value.

that's why, types come at the end, so you can omit them when compiler does the proper inference for you.

You would drop the let so normally it’s just Type variableName = 2. I think that is more concise and easier to read than let variableName:Type = 2

C, C++, Java, C#, Swift, even weird-ass Objective-C, all declare by type. I have no issue with inferred types. C#, Rust and Swift can infer type so it’s ok just to declare var variableName = 2 if you really want to avoid declaring type, but I think that defeats one of the main advantages of a staticly typed language.

Personally, I’ve written very large applications and frameworks in es5 and es2015 and have never had a single issue with mismatched types that wasn’t just a typo in the variable name (linting solves this). People say static typing helps avoid runtime errors, but again I’ve never experienced that using dynamic languages. It’s pretty easy to know that numElements + offsetX is a number and message + numElements is a string even without seeing a declared type.

The ONLY benefit I’ve experienced for staticly typed languages over linted js is IDE integration. Proper intellisense is far superior to emmet.

Typescript is a strongly type wrapper around Javascript though, which is the problem.

Somehow I never have problem with types in Java. They're always there, they're always right*, I don't need to figure out types to use other people's code, the VM will actually enforce the types which each operation at runtime.

edit: * almost always, except for Generics, which are not totally dissimlar to TypeScript in that they're very leaky abstraction.

The reason JavaScript is so popular with new devs is that there are no compiler errors. They just hack it until it works. Compiler errors are a huge deterrent for new devs, so avoiding them at first makes getting started much less aggravating.

For old devs we usually don’t get compiler errors on purpose. And when we do it’s always like duh. Also more experienced devs are constantly refactoring. That’s where the usefulness of a compiler really comes out.

When you know what you’re doing a compiler makes you muuuuch more productive. Writing solid code, faster.

Running typescript with Webstorm is the bees knees. It gives you all the parmeters, their types etc. So you get autosuggested and typeahead completion. It feels like writing compiled code, yet I can still override whenever I feel like it. Also, I find typing just makes things easier, especially when you are not the sole developer.

I think Visual Studios probably works well too but I can't speak from experience.

VS Code uses the Typescript language server which is more advanced than what the JetBrains products currently offer with their own implementation (as far as I understand from reading issues on their tracker). There's an issue on the Webstorm YouTrack to integrate the Typescript language server though, so soon (I hope!) Webstorm and related products like PyCharm will have the same level of editor integration with Typescript as VS Code enjoys.

Vs Code. I am reading it's supposed to be awesome with Typescript. I think the issue is that in my case Typescript needs to coexist with vanilla js. But even the angular http modules, which have type definitions caused me some troubles.

Webstorm (having been born from IntelliJ) has a couple extra tools for OOP, like those arrows besides class methods indicating they are overriding something.

Most of the TS editor features come from the language service, not the IDE, so the bread and butter will be mostly the same. Recently I've tried TS on sublime (on an older, slower computer) and was surprised on how complete it is.

I love es6 in Intellij, and the jsdoc functionality helps a lot to highlight possible bugs, but I wouldn't say it's the same as static-type checking (at least in my experience). Also, not everyone uses Intellij so they might not get the nice "possibly a bug" highlighting that comes with it.

I hate having these conversations cause it always seems like im calling someone wrong :'(

vscode figures out most of it for me let string = ''; and so on. I dont think I need an IDE especially one I'll have to get licensing for(?)

setting up tooling to do checks per typing per file?? you are literally writing typescript and then an implementation file?

yep but its wholly detached from the code so going/*** @param {jqueryXHR} xhr*/queryDatabase(xhr, args, cache = false)Seems pretty dumb when we already know its a param, we already know its name all we want is a type

I don't want to write a declarative file I want to have one file cause this is javascript and I rarely need to write multiple implementations and if I am I'm going insane and so will the person who has to maintain my code.

@Annotations are not declarations of types, though they can be used to sort of declare the intent by the nature of decent naming conventions. They are just functions AFAIK.So if you had@loggedqueryDatabase(xhr, args, cache = false)it would apply he 'meta'function called logged which would, say, write out something to a logger. Angular relies on it heavily to turn an ES class into a component or a service by attaching metadata and transforming everything.

If you don't hate yourself and just use typescript as JS with types you're golden in my eyes.Finally I really do need the transpile process cause IE is still a thing in the enterprise world.

In fact the only thing I dislike about typescript is it moves too damn fast with monthly releases, but then so does everything in the web world.

Vscode is not up to pair to Webstorm, and it is an IDE with all those plugins. I just don't mind getting a license for something that I consider an essencial work tool (one that allows me to be more productive i.e. get better salary). So IDE/Editor/whatever, that's what you need static type checks done by

You're also setting up tooling for TypeScript/Flow/whatever that isn't the standardized supported ES, so no argument there

JSDoc is code, albeit not idiomatic to ES, and especially latter years there's no development there, still, I put it there as a reference, not as a recommendation to be used (helps me though once or twice when IDE complains)

When you're writing TS you're writing a declarative file (along with imperative code), one that gets transpiled to JS, so yeah, TS is not JS (the tooling argument). And the people who will need to maintain your code more or less will go insane whatever the code does, it's legacy after all, foreign to them.

@Annotations (named decorators in the ES lingo) are everything you want them to be. Considering there are @NotNull annotations in Java, you can also imagine a decorator of the kind @types('Xhr','string[]','boolean') like you noted in number 3. That decorator will be:

part of the idiomatic ES

declaring just the types (no unnecessary repetion)

no need of another language bolted on top of ES.

Time will tell.

On few tangents (just to provide context of my different view on things):

Please don't mind how awkward Angular is, it's just how Google/Python/Java institutionalized people understand the world, thus make TS/JS code that looks like it.

I can say I don't want to use TS just because of the transpilation step, but that's just part of the problem. The other one I have is with the way big companies push for type systems to be(have).

I mean, if you look at SOLID, the I there stands for many specific interfaces, usually a bundle of a method or two... well, another way of looking at it is duck typing with an interface keyword :)

Big companies that support the platforms/ecosystems don't need artists in the programming art, they need biological parts in the code generators (I wrote in some other comment about this), so the mantra, nay, the dogma is "we can't reason, we need static type checks, then we can feel safe". It's just not for me.

Typescript shines when used in a group setting, when you refactor code, when paired with an IDE and when you’re consuming a well typed library. It’s especially helpful if you’re writing a library that others will consume.

It doesn’t sound like a lot of that applied to your experience, so I’m not surprised you weren’t sold.

there are a few standard ways of telling TS to leave a statement alone if you know what you're doing.

there is a learning curve, and you have to think about things you previously didn't.

I think you get the most benefits when working on a large project with multiple folks.

If you're the type who'd rather dip your toes into the pool rather than diving head first, I'd recommend using Visual Studio Code (or configure another editor to do the same javascript type checking stuff), then start adding // @ts-check at the top of your javascript files, and occasionally mouse over your function and variable names and see if the editor has good types/signatures to show for them.

Then if you don't like seeing any on most types, start adding JSDoc documents to help things along. Then see what becomes red in your editor, and whether you can make the red go away by adding another JSDoc comment, or if it actually found a bug for you. If you're not in a hurry to fix it, you can leave it be, the little red squigglies will still be there next time you look at the source file, but your code will continue to run as before.

If you find yourself developing a taste for being able to see types in your JS code, catch a whole lot of potential dumb mistakes, and you start wishing there were a less verbose way of doing what all those JSDoc comments do, then you'll know you're ready for typescript.

Not trying to be a jerk, but if types are getting in your way you don’t understand them well enough or don’t know how to design and use them well enough. Give it more time, learn types in general, and spend some quality time in other statically, strongly typed languages.

Edit: I stand by this statement, but I realize it’s not all that helpful or actionable. I’d be happy to take a look at your code and provide feedback about your types.

My boss pushed me towards TypeScript for my project at work, and for a few months it just sat in the background occasionally getting on my nerves. Then I went on holiday and learned some Rust. By the time I got back I saw it all differently, and as I've utilised TypeScript more I've begun to really understand JavaScript's (fucking weird) type system as well.

I refuse to work on a non-typed project now. Strict TypeScript is just so so so nice. Also, this is just me, but I also really enjoy writing typings for untyped libraries. Generics are fun. I don't know, they're just so logical, it feels like such a pleasant break from the typical randomness of the web platform.

Hey. I started with C++ and I really enjoyed it. I also made funny projects in C# with Unity. That went very smoothly. In all the typed languages I have used, Typescript is the one that makes me most wast my time. Solving "errors" that really aren't.

I don't think that's necessarily true. Types do get in the way, that's their whole purpose, to restrict. It restricts your design choices and makes things harder in profit of safety and assurences.

Frankly, it's an overhead that can be more damaging than helpful when inforced too much, since it makes your design too sensitive to it and brittle. However, Typescript is built around gradual typing so you usually won't see those downsides. Most strongly-typed languages don't offer you that luxury and there are times when it's just awkward to work within the type system.

I know this is an unpopular opinion since type systems are all the rage nowadays, but they have downsides too and acting like "you just don't use them well enough" is not a constructive way of thinking.

If you don't write type parameters in code then you'll need to do it in comments for your own and for your coworkers sanity. But there's no guarantee those comments will be kept up to date with your code. Types solve both problems at once with less work.

Types used sparingly are good. I actually like TypeScript quite a bit since as I already mentioned, it does not force you to use types when you don't want to. So it's a sort of gradual typing, which to me is the best of both worlds.

But when you have to cram everything into the type system, you can hit trouble.

First and foremost, even vanilla JS has types. That’s right, every piece of code you’ve ever written has types, but in dynamically and weakly typed languages it’s largely hidden from you. But even though it’s hidden, you are still always bound to the contract of the types of your variables. We’ve all experienced the result of breaking that contract.

Explicit typing (static, strong for the sake of my argument) just makes you tell the compiler/interpreter/IDE your intention. The variable has a type either way. But now your IDE can do smart things for you and your team now knows what you know.

Static/strong languages typically have more expressive type systems as well, which I think is where people tend to get into trouble and misuse types the most. Experienced JavaScripters are used to the loosely typed and free form nature of Object, and TypeScript asks you to be more explicit. But consider this: all your code that checks objects for properties, all your typeof’s and instanceof’s, these are your types encoded into the program in a much more free form and, to be honest, bug-susceptible way.

Being a skilled user of an expressive type system is difficult. It comes with practice and study like any other skill. But the benefits, when used correctly, are that you and your team of 50 other engineers, and your IDE, know exactly what to expect from every variable at first glance. After much practice, I don’t feel like types slow me down. And the benefits compound for every other engineer working on that code.

I thought we were talking about strongly-typed systems. Weakly-typed systems by definition will change the underlying types of the variables for you so you don't have to worry about them. So, really, it doesn't make you decide on a type, therefore doesn't restrict you. The fact that underneath it uses a type system is irrelevant, compiler and interpreter contributors can use whatever tools they want.

Static typing is explicit, you mark your intention and then it restricts you to it. If you can't express the full extent of your intention, then you have to force it somehow or simply work against/around the type system. My "type encoding" via the checks you mention has the benefit of being very flexible. Granted, it's a bit unsafer than types but not as much as everyone here seems to think.

Obviously by using the guarantees granted to you by the types, you can do some powerful stuff. Sufficiently strong type systems grant you powers akin to magic. But they all contain the overhead of you trying to convince the type checker, wherein lies the restriction. They slow you down with purpose, but they will still slow you down.

Humor me and don't mention experience with type systems as if it's a pro of using them. Just cause you can get used to them, doesn't make them good. People got used to OOP as well, and we all know how that turned out.

Weakly-typed systems by definition will change the underlying types of the variables for you so you don't have to worry about them.

You always, ALWAYS have to know what is the type of a variable that you're using, even in a weakly typed system. The ONLY "benefit" of a weakly typed system in this regard is that you can perform runtime type checks and branch your logic accordingly.

But if what you truly WANT is to have the same variable contain values of different types at different times, you are asking for trouble and for other people reading your code to be thoroughly confused fairly often. That's a great way to increase WTFs/s.

it doesn't make you decide on a type, therefore doesn't restrict you

Again. Just use two variables. Rather than

var id = "123";
id = parseInt(id, 10);

do

var idString: string = "123";
var id: number = parseInt(id, 10);

It's type-safe, self-documenting, AND happens to be a better representation of what is actually happening.

The fact that underneath it uses a type system is irrelevant, compiler and interpreter contributors can use whatever tools they want.

I know what you mean by this.

Static typing is explicit, you mark your intention and then it restricts you to it.

Just make another variable.

If you can't express the full extent of your intention, then you have to force it somehow or simply work against/around the type system.

You CAN express the full extent of your intention in a static/strong language. That's my whole point. If you are more skilled with types, you can express any intention with them and you'll be better off for it.

My "type encoding" via the checks you mention has the benefit of being very flexible. Granted, it's a bit unsafer than types but not as much as everyone here seems to think.

You say "flexible", I say "eventually bug ridden" and "all the information is in your head".

Obviously by using the guarantees granted to you by the types, you can do some powerful stuff. Sufficiently strong type systems grant you powers akin to magic.

Something we agree on.

But they all contain the overhead of you trying to convince the type checker, wherein lies the restriction.

Again, this is the wrong way to think about it. Don't "try to convince the type checker". It's not a nanny. It's a tool. USE it to your advantage to prevent yourself and your team from making a whole host of non-runtime mistakes, and to express meaning to the rest of your team, which, by the way, includes future you.

They slow you down with purpose, but they will still slow you down.

I would argue that types are slowing you down because you are thinking about them all wrong and need more practice expressing what you want in them.

Humor me and don't mention experience with type systems as if it's a pro of using them.

Your wording here is slightly strange. I never say "experience with type systems" is a "pro of using them". I said if you don't have experience with them, you won't know how to use them correctly. If you don't have experience with C++, you won't know how to use it correctly. If you don't have experience driving a car, you won't know how to drive a car correctly. If you don't have experience cooking, you won't know how to cook a meal correctly. It's really not that difficult a concept to grasp.

You always, ALWAYS have to know what is the type of a variable that you're using, even in a weakly typed system. The ONLY "benefit" of a weakly typed system in this regard is that you can perform runtime type checks and branch your logic accordingly.

But if what you truly WANT is to have the same variable contain values of different types at different times, you are asking for trouble and for other people reading your code to be thoroughly confused fairly often. That's a great way to increase WTFs/s.

Weakly-typed systems are a non-issue. Your point of always having types in your head is irrelevant since that's just a way of organizing things in your head, not your code. We're talking about whether there's benefit to explicitly mention the structure of these data structures, not that we're organizing our thoughts around them.

As for primitive types, which I thought is what you were alluding to in the previous thread, the compiler/interpreter solves it for you.

It's type-safe, self-documenting, AND happens to be a better representation of what is actually happening.

That's a pretty small example you have there. I think you'll agree everything looks like a good idea in the small. It's frustrating that we are talking so abstractly and as such it is harder to come up with examples that showcase exactly what we mean, but we're just gonna have to trust each other that we aren't talking out of our asses.

But to actually respond to your example, I think the types are unnecessary. The names of your variables seem to do just fine at documenting everything I need to know.

I know what you mean by this.

I'll assume you meant you don't know what I mean by this. I meant that the beautiful people that implement these languages have the choice of using stronger type systems inside the compiler while making the language itself usable at weakly-type level. As long as it is not exposed to the user (aka the developer that uses the language), it's inconsequential.

Again, this is the wrong way to think about it. Don't "try to convince the type checker". It's not a nanny. It's a tool. USE it to your advantage to prevent yourself and your team from making a whole host of non-runtime mistakes, and to express meaning to the rest of your team, which, by the way, includes future you.

Haskell users tend to compare the type check akin to a friendly rival that they propose types to and that it fights back until they found a good type representation. They often have to come back in code and "adjust" types so that their programs will work. The drawbacks are accepted since they offer them a lot of safety and benefits.

I would argue that types are slowing you down because you are thinking about them all wrong and need more practice expressing what you want in them.

Your wording here is slightly strange. I never say "experience with type systems" is a "pro of using them". I said if you don't have experience with them, you won't know how to use them correctly.

Yeah, bad phrasing on my part. I meant that you mention types are good but people don't see that because they are inexperienced. First of all, that's an assumption you shouldn't make about someone. Second of all, experience with anything will make that thing easier to use. How is that going to convince anyone said thing isn't actually slowing you down? I could make the opposite argument and say you don't have enough experience working with weakly-typed languages.

Also, please don't take my comments as being ill-intended. It's just my perspective on things, and there is no reason to heat these arguments up, since neither of us win anything material out of this.

EDIT: Just saw the OOP thing I didn't answer to. My point was people got enamoured with the corporate-version of OOP (not the Alan Kay's original proposition) and then realised the types they conjured up are not so true to life.

Your point of always having types in your head is irrelevant since that's just a way of organizing things in your head

What I mean is, any time you access a variable you do have to know the type of that variable to know how you can use it.

We're talking about whether there's benefit to explicitly mention the structure of these data structures, not that we're organizing our thoughts around them.

Every data structure is explicit. They all have a structure in memory that was explicitly defined in your code, whether you declared a type or simply constructed it out of random objects and arrays. Declaring types makes it trivial for anyone reading that code to know exactly what every variable contains at a glance, something that cannot be said for languages like JavaScript.

That's a pretty small example you have there. I think you'll agree everything looks like a good idea in the small.

Absolutely. It's not a representative example of everything. But I don't agree that "everything looks like a good idea in the small".

It's frustrating that we are talking so abstractly and as such it is harder to come up with examples that showcase exactly what we mean, but we're just gonna have to trust each other that we aren't talking out of our asses.

Indeed.

But to actually respond to your example, I think the types are unnecessary. The names of your variables seem to do just fine at documenting everything I need to know.

In a small function, I would say it's not as important to be explicit about your types. But in library or framework-level code, I think it is.

I'll assume you meant you don't know what I mean by this.

You assume correctly.

Haskell users tend to compare the type check akin to a friendly rival that they propose types to and that it fights back until they found a good type representation. They often have to come back in code and "adjust" types so that their programs will work. The drawbacks are accepted since they offer them a lot of safety and benefits.

I can't really speak about Haskell because I don't know it. I'll just qualify all of my points by saying they are within the context of widely-adopted OOP languages like Java, C++ and JavaScript.

Yeah, bad phrasing on my part. I meant that you mention types are good but people don't see that because they are inexperienced. First of all, that's an assumption you shouldn't make about someone. Second of all, experience with anything will make that thing easier to use. How is that going to convince anyone said thing isn't actually slowing you down? I could make the opposite argument and say you don't have enough experience working with weakly-typed languages.

Point taken. Appealing to authority is a bad argument and I usually know better.

EDIT: Just saw the OOP thing I didn't answer to. My point was people got enamoured with the corporate-version of OOP (not the Alan Kay's original proposition) and then realised the types they conjured up are not so true to life.

What I mean is, any time you access a variable you do have to know the type of that variable to know how you can use it.

Every data structure is explicit. They all have a structure in memory that was explicitly defined in your code, whether you declared a type or simply constructed it out of random objects and arrays. Declaring types makes it trivial for anyone reading that code to know exactly what every variable contains at a glance, something that cannot be said for languages like JavaScript.

You don't have to know the whole type of your parameters in weakly-typed languages. You just need to establish an interface. If I'm adding 2 variables in my function, I don't care if they are of a certain type or not, just that they can add. Nothing more. And so, I verify just for that.

It's as if I'm defining interfaces for each parameter of the function, but implicitly and with arbitrary precision (for example, I can specify arbitrary conditions on nested properties of the said parameter; imagine translating that in a type system while still trying to keep the type as generic as possible).

Now you could argue that these weak-types are still types, and well, they are. But they are far removed from what most would call a type system, especially when compared to the languages you just listed. That's why I avoid saying the word "type" and just say "data structures", since the type checking is done by the programmer and only if he wants it.

In a small function, I would say it's not as important to be explicit about your types. But in library or framework-level code, I think it is.

True, types become some sort of guards / tests that the user of the library can be sure are passed. But this does mean that the API of the library is limited to the expression power of the type system (which is what I meant by types making code "brittle"). This is why many libraries tend to break the type system via metaprogramming when trying to get more non-standard APIs.

Now, to explain my position a bit better:

Type systems were created as restrictions on the language. The goal is to avoid invalid programs by making them not compile. Those invalid programs include the programs we would consider to have bugs (wherein lies the safety granted by the type system).

But the expressiveness of type systems is limited, and you have to conform to the rules in order to gain the benefits. It's just inherently slower, by definition, to code up. You annotate variables, you define entire type hierarchies and only after, you gain the benefits of having done that.

And if by lack of luck you end at the expressiveness frontier of the type system you use, you just can't code your design, so you'll have to change it. The languages you listed are really just (a weak subset of) System F-sub lambda calculi, which is, for most things, enough. But imagine you didn't have generics, stuff like map/filter/reduce can't be coded without breaking the type system in that case. In JS, which is essentially an untyped lambda calculus, you can code anything you want (and probably in fewer lines of code).

Type systems are useful and can prove black magic-worth properties of your programs. But it rubs me the wrong way to see them put on a pedestal with no mention of drawbacks. They are not as much of a hassle thanks mostly to IDEs and type inference but they aren't untouchable either.

I also hate the amount of seemingly useless repetition re: things like explicitly declaring a variable's type. For example if I declare a member on a class with an explicit type, even if I assign it a value in the constructor, it can't infer that the corresponding argument provided in the instructor should match that type. Leads to needless repetition I find.

In my experience the place Typescript sucks is when it's interacting with regular javascript.

But really, as will all static typing, it's for the next person who comes along, not for now. And that next person could be you in several months after you forgot all the nuances of your code.

So yeah, Javascript is almost always easier initially, but unless this is one-off, experimental, or simple enough that only you will ever need to understand it, the static typing of TypeScript will pay off.

If you isolate your typescript code properly, you can start small and then spread your type-bootstrapping progressively either by converting existing js code to ts and add only the necessary type annotations slowly or with latest typescript you can import types into js (I don't remember the syntax but you write it as a comment) and then use the imported interfaces in jsdoc.

If it's a brand-new project and coexisting with js is a requirement, you should write the infrastructure code (domain interfaces, domain specific utilities, common services) with typescript and then you can leave the consumer code in javascript.

Yes, this is a pain point for me as well, but I’d consider it much worse that “8/10”. Even relatively common dependencies often have outdated, broken or low-quality typings. A few months ago I’ve been checking GraphQl, and one of the common libraries used by Apollo (itself typescript) used “any” instead of genetics. Other times typings will lock out entire features. I’ve learned to dread third-party typings, but sometimes even bundled ones were supplied in a pull request 2 years ago.

So one of the core frustrations of TS is that whenever you hit an error you don’t get, it’s almost as likely that the issue isn’t you, but 3rd party code.

It’s not too surprising – the side effect of JS dynamics is very complex “actual” type systems that are often tricky to express in the typings. But it does mean interoperability often feels like pushing a square peg into a round hole.

Like anything else, there's a learning curve to TS. It's very possible those wtf-class errors might be actual problems if you let them through, or maybe the type definitions are not right even though it's possible to stumble through eliminating any errors (e.g., just using any for everything).

I agree with OP. Typescript and all its ide magic feels like going back to Java and Eclipse for me (my old development tools). And I don't think that is a good thing.

I think a lot of the power gained only facilitates more rapidly creating complexity.

A lot of the issues people are mentioning to me would be better handled by making more simple predictable testable functions. Typing really isnt that scary in JS. I can figure out what is inside of an object by ... you guessed it... looking at the object. If your object needs all these safety nets maybe its doing too much, maybe its too complicated.

I prefer dumbing down the system over introducing more power tools. Just my personal flavor of choice.

Again totally agree - the #1 reason people seem to have for using TS is "it's a pain now, but when you or someone else comes to refactor it, it's a breeze". Hey, how about you don't write spaghetti code with functions that return gibberish now without TS?

I'm sick of people coming to JS and saying the language is broken, then trying to turn it into Java. JS isn't broken, you just need to adapt to a slightly different way of programming. I've never seen anyone make a superset of Haskell that is object oriented, or a functional version of C BECAUSE THAT WOULD BE INSANE

Agreed wholeheartedly. When I go to use a third party library, I don’t need my IDE to tell me what to expect from a function call as soon as I type it out. I just spin up a test page and make some test function calls (with all the argument combinations I can come up with), and inspect the object with console.log. Either that or I can spend an hour reading the always up to date and precise documentation, and if that fails, spend a couple hours reading the library’s source code, learning the code flow and patterns and figuring out the output on my own. It’s so much easier!

Or reference existing implementations and inspect living objects with chrome dev tools. Turns out there is autocomplete on real objects. Whoda thunk. And spinning up a test page and working with real living code doesn’t sound like a negative to me.

You’re acting a bit disengenuous to support your workflow. The best flow is the one that gets you personally generating quality code. I don’t struggle with my flow the way you outline. Just like you probably find your comfort zone with strong typing and the accompanying ide tools.

The compiler is your friend, not your enemy. What I like about typescript is that if there's some weird problem you don't know how to fix you can just put an as any and it will work most of the time. And even though you spend a little more time and effort understanding how to get the code to compile, you save much more with the autocomplete it provides and type checking (as most problems in JS are caused by some undefined thats passed through your code until it crashes in an unrelated place)

I like flow.js more than ts. Begin to write in plain js and plug types in when this is really needed. The best part for me is FlowJS comment types. I even do not need to change the build system. Error messages are sometimes cryptic, but I was amazed for a few times how smart it is.

You're right. The responses here remind me why I don't like visiting this sub anymore. Everyone is completely on board the typescript hypetrain and bashing you for not 'getting' it.

At first I didn't understand where this influx of typescript fanboys came from, but I think it's the massive influx of .net and other microsoft related devs to javascript. I suspect it's also a big part of why vscode has become so popular, as that reminds them of visual studio and the IDE that they're used to.

They're used to static typing, and see the absence of that as a weakness. However, for javascript the protection from type errors has a cost. For one, it increases complexity (as you've experienced) and more importantly, locks you into the typescript ecosystem.

Typescript is a superset of javascript, like coffeescript. As with coffeescript, I expect it to eventually lose popularity or be integrated into ecmascript, forcing people to refactor their existing codebase, at great cost. Just wait. There are going to be quite a few of abandoned typescript projects in a couple of years.

This is what I've seen a lot with apps built on the microsoft technology stack. Horribly outdated codebases being kept alive just because it's too expensive to refactor. So it makes sense that these microsoft devs don't see this as a problem, as that's what they're used to.

In my opinion typescript solves a javascript problem, but not in a javascript way. The added cost is not worth the benefit. It's not really that much of a problem. I don't think I've ever spent a significant amount of time debugging type errors, and I've worked on some large, heavily used applications.

My recommendation would be to drop typescript. You don't need it. Just deal with your problems in ways that are more native to javascript. Look to devs that are building big node and js apps without typescript, and see how they're dealing with the problems they encounter. Personally it made me a lot happier and more productive. Hope that helps!

between linting and unit test coverage, I dont miss any bugs that type analysis would catch

Far easier to make generics/functional code that is type independent, no casting

Downsides of dynamic types:

IDE not as good at auto-completion.

Dynamic programming is not just "making a mess undocumented classes and types". Its a different way to approach programming. If you keep programming the same way as before, but turn of the type checking, sure it seems worse. but thats not what we do.

I agree with you as well. I fail to see how the complexity Typescript adds is of any help. Yup I am looking for an alternative to Ionic/angular which oblige Typescript. I have a large project I am working on since two years now, basically made from scratch with PixiJS and seriously, vanilla JS is fine.

You may not realize that ES6 is more or less Typescript. Whether you like it or not the future of Javascript is all of the functionality of Typescript. The purpose of typescript is to enable apps to be built using the new ES6 features that can be transpiled to older versions of Javascript. You literally do not need to use any of the mature ES6 features if you don't want to (good luck with that), TS and ES6 are supersets of Javascript, so all of the advanced features are optional.

If you're resorting to caricaturing those with whom you disagree then you should probably reassess the validity of your argument.

I started out on PHP, then moved over to JS with Babel. I've since fallen in love with TypeScript with the help of learning the strongly typed Rust on the side as a hobby.

For me, it is significantly more complex to enter a JS codebase without type information because you can't trust any of the code, and nor can you refactor with any real level of confidence that it won't break something else.

I get the Microsoft thing. I also feel uncomfortable using React which is developed by Facebook. But the fact of the matter is that these technologies are fantastic, and should an issue ever arise they're open source with an enormous community of enthusiasts behind them. So I'm not really worried about that.

If you have any questions specific to TypeScript then please do feel free to ask.

Most people here that are negative about TypeScript appear to be using it wrong, frustrated that it isn't exactly like JavaScript or just don't understand that although it is a statically typed language, when compiled, it's boiling back down to JavaScript.

Knowing the last part is key to writing some really good Typescript. It's the difference between deciding to use a class or an interface for that type you want to define. (Do you need to know about the type at runtime? If so, an interface isn't going to help!)

Typescript is key in writing maintainable and scalable code. You can do this a lot easier than if you were to use JavaScript.

You just need to sit down with TypeScript and learn it first.

Decorators? Love them.

Knowing that response data is going to be of a certain type so I know that the property in looking for exists on that object? Love it!

Type casting!?

IntelliSense!? This is one of the best things when working with other libraries, nevermind in a group of Devs.

Need more convincing? Google has their own language which transpiles to JavaScript, Dart. Yet they abandoned this to go 100% TypeScript (a Microsoft creation) for Angular, probably growing to be one of the most popular JavaScript Frameworks around.

Hmm I can't say that for me. I recently had to build a Password strenght indicator with multiple requirements to fullfil the TÜV (Association for Technical Inspection in Germany). They gave us specific requirements at which specs a password should be indicated as secure, weak, very strong etc.

The goal was to build a scaleable Password Strength Indicator.I had an initial Idea, but wasn't sure if I could do it a "clean" way with VanillaJS and I also wanted to get better at ES15 etc..I could choose something like babbel or.. Typescript, which I used in VS2016 back then.So I choose Typescript and it didn't took me a long time to have a perfect working indicator (let's don't talk about the script itself. I am not a fan of strength indicators.. noone should care which password I choose, especially don't force me to pick something else.. this would lead me to take something easier to guess and less strong, but probally indicated as stronger).

Errors.. well, I admit the initial tsconfig configuration wasn't the easiest. It was easy, but I had to Google here and there. The Typescript documentation I found was very helpfull too.. every possible configuration with a small explanation.

Another error was that I didn't used referencing within the config, so I got an error, because the IDE couldn't know with files belong to which. Luckly I knew this error from past time and could Google for it. It's just one line you add at the top of the file, which is a reference to the abstract class I use (while extending from it).

Back then I also had to find out how to configure PhpStorm to automatically compile the script, which took some time too.

In the end it didn't took me so much time.

What types of error do you get? Are this your own fault or Typescript fault? Do you use a proper IDE, which can be very helpful (I recommend PHPStorm or Visual Studio)?

Overall I enjoy TypeScript, but it does have one aspect that pisses me off. Adding to the window object. It tells me there’s no such property. I’m running an app inside Electron, and it tells me there is no such property as require. Mother fucker, yes there is. Those kinds of things should be WARNINGS. Not errors.

It’s not really a hack at all. By design, TypeScript needs to know about the execution environment you are targeting since the execution environments can vary. For example: browsers have the global window but Node.js doesn’t. If you rely on window then you tell the compiler by configuring it to use lib dom in tsconfig.json. The TypeScript compiler has a lot of different options but most projects will set the same few common ones only.

I've been forced to use it here and there and in every team they were misusing TypeScript. The consequence is endless amounts of interfaces for every bit of data, including API data that often changed its output by adding values, at which point the front-end development just crashed and we had to figure out what ___v and ___pt meant in the API.

It was time consuming and unnecessary. The project itself was rather simple and didn't benefit even from a rightly used TypeScript implementation.

That said, I'm 100% sure it can be very useful if you don't set it up to be too strict. There's a sweet spot for TypeScript that makes it a bliss to work with.

Most teams are too strict or, worse yet, too forgiving.

Also, I'm using React.js at work. There I think propTypes are more than enough for all our needs. I think TypeScript is never welcome in React because I've literally seen it in several big companies: Developers regretted ever getting started with it.

K.I.S.S. = Keep It Simple, Stupid. If you want your props to be typed, propTypes does it perfectly. Your component code should be human readable and understandable and should not need strong-typed code. If it does need to, then your code is shit. Variable names should be self explanatory.

Don't call things 'user' but call it objUser or strUser or userID or whatever it actually is. I should NOT need intellisense in my IDE to figure out what's going on.

I'm not a fan of strong-typed JS. I've never seen it done right. But I do understand it in bigger projects. Still, it's a very delicate setup that is easy to fuck up.

I'm working on a ionic project ... I find myself wasting time on google just to put the right configuration at the right place and so on

Can you give examples? It sounds more like the kind of thing that specific framework needs rather than anything caused by being in Typescript, which (to me) doesn't add much more "configuration" code over plain Javascript.

I was going to come in here and dunk on you but then I realized you're probably not running TS with an IDE like Webstorm or VSCode. I can fully understand why you would be frustrated if you're not being given some sort of linting assistance with TSLint or that the IDE you're working in isn't actively giving you code errors as you write them. When you pair TyepScript with something like Webstorm you begin to understand WHY people, myself included, absolutely adore TypeScript.

On a personal note, I learned TypeScript as a result of learning Angular, and I'd actually say I'm better now with TypeScript than I am with Vanilla JS.

It's probably more the unexpected errors, at least that was it for me. I just wasn't used to getting type checking in JS. Which, unfortunately, was derived from bad habits and a comfortable ignorance of proper programming methods. But once I muscled through the OMFG moments, it worked out even better. Actually, there is a good course on edX that helped me quite a lot, as well.

I wouldn't expect Ionic to be hard to get on typescript, since Angular is a lot simpler in terms of typing (OOP). I've tried to jump back to untyped javascript and raged hardly on stumping into stupid runtime errors and also on writing extra tests for things the typings usually cover. You'd rage even more when jumping into someone else's codebase and having to dive into a function to find out what parameters does it take.

On the other hand, React on typescript definitely feels quite immature.

The type system itself is still lackluster for some of the heavy inference cases of React (mostly HOCs);

You rely on 3rd party typings that sometimes are not first-class for the developer who wrote the lib;

The language is constantly adding new features to address item 1, yet the 3rd party typings have to follow up. Also, DefinitelyTyped has no thing like a "type definition TS version target", which makes things even more messy.

Fundamentally, I think what you are getting wrong is the same thing that a LOT of programmers, both new and experienced get wrong — falling prey to the illusion that you can save time in the long-run by getting something up and running as soon as possible first, and then take the time to clean it up when the need arises.

This "get it working, fix it later" approach is as deceptively logical as it is ubiquitous.; I don't think I've ever worked on a team that didn't have at least one strong advocate for this approach. The problem is that, in my experience, developers end up having to pay that time back orders of magnitude higher by not having well designed, self-documenting foundational code base to work off of.

The advantage of TypeScript is that it encourages a "do it right the first time" approach to JS that inevitably slows down the initial development process, but pays off exponentially as the code expands and matures.

You should try using a jsconfig with vscode. ITV uses vanilla js only, but runs it though typescript your checker to find the most obvious mistakes. That's the lowest common denominator and no friction.

I suspect the projects where you see no benefit are smallish or don't contain large/important interfaces or domain models.

I have a small project that doesn't benefit much from TypeScript.

I also work in a very large project where TypeScript is clearly invaluable.

eg a response from the server containing a large/nested domain model object. We use a tool that converts C# classes/interfaces to TypeScript. This allows us the practical nirvana of having the same model/objects on server and on client.

For this project, the main benefit, that is obvious to everyone on the team, is mainly the use of interfaces - making the code much clearer (what method is receiving what, and what it's returning), as well as getting safe refactoring benefits from the compiler. I have fixed countless bugs just by converting to types, suddenly realizing that the method that returns an important "Schedule" object, can also (accidentally) return an object that doesn't contain all the required properties.

But it's not just picking the mistakes, it's "being able to clearly see what's' going on" in terms of domain model objects.

And in the end it all compiles down to bloody JavaScript If you want to deliver your software over the world wide web, it's all JavaScript learn JavaScript well enough it will pay even better in the long run.

Fault is not in our stars, it lies in ourselves.

Typescript just like any other thing is a tool it has flaws for the human is flawed.

So is JavaScript .

But that hasn't deterred as from developing some great products in JavaScript even before typescript.

But both can mastered and leveraged efficiently over the time with discipline and practice.

However, what I think type systems can't simply alone make all your problems go away and make your apps reliable and resilient and easier to reactor or meet the main purpose of software ware which is supposed to be easier to change compared to hardware or machine code.

It helps, but certainly not the end game.

I believe a strong TDD suite is more essential for large teams and to support rather encourage new developers to change or refactor code.

If you don't have this as part of your development culture, typescript can't really do magic.

Personally I have found running bunch of angular1.x in es5 apps along with new react apps in es6 and one in react and typescript inside a peaceful PWA shell written in vanilla js.

Everything minus typescript application runs behind a webpack build process which uses google closure compliler and each application has their own test suite.

I feel like you are trolling with this post. Full disclosure, I'm a full stack .Net developer. So I'm using Visual Studio 2017, which has awesome TypeScript support. We use JQUery, KendoUI and Twitter Bootstrap 3. Our main web application is 15 years old. We LOVE TypeScript and do not write JavaScript anymore. The only problem we have had is that developers all have to have the same version of TypeScript installed and selected to use for compilation. If someone upgrades the compiler, everyone has to upgrade or it won't build sometimes. What IDE are you using? What are the weird errors you are getting?

Your setup sounds terribly wrong if it depends on developers' local package versions. You should at least use package versions from package.json to avoid it and ideally, have a separate CI/build process that doesn't live on developer machines.

I use vscode. I don't have the project right now before me but I had a lot of trouble making Typescript es6 compliant (making Object.entries works, for example), and I had a few issues with the http angular modules.

Sucks. In Visual Studio you select ECMAScript version on the TypeScript build properties page. We actually compile to ECMAScript 5. Never had any issues. What version of TypeScript are you using, we are using 2.6 for a while now without issues.

i too, found typescript to be buggy and just a horrible experience to work with.

if you want a statically typed language that compiles to js, i would suggest elm, purescript, or kotlin.

im currently learning elm, and after i got over the initial learning curve, it has been a breeze to develop stuff quickly and without a lot of 'wtf does that error mean???'. pretty much completely painless and actually has been a pleasure to work with.

I mean, what is this? You're not asking for help to solve a problem or to understand anything, you're just moaning.

Typescript has a lot of difficulties with setup, especially when you use 30+ deps with different version and different sets of typing.

Honestly it doesn't seem you understand why TS is used in the first place, sure it takes more time to setup, to create interfaces and so on. But in the long run you earn time and sanity. Type hinting makes it possible to instantly see what an object contains. Restricting props and objects to interfaces removes building the app and testing the app to see a simple mapping error.

It also reduces the need of unit testing, you can be sure certain variables will be what you tell them to be, if you change an object, the entire app can break before you can even compile it, because there's a reference error to that single object, going through the entire app.

Typescript is an investment for your future. It is extra work to setup, but if you revisit your project or work with multiple people, you can save much time in the future.

It also prevented a lot of bugs for me by warning me about mismatching types. Properly defined types act as a contracts between functions, modules and classes. Writing contracts take time and effort, but contracts can save your ass in the future.

I like Typescript because it plays nice with existing code-bases. It allows incrementally adding types to your codebase. It also works great with VSCode.

Disclaimers:

I write native apps, hybrid apps & Vue/Angular/React apps for a living

I have been working on a Node + React app for almost a year now, there are around 4 programers in the team on average (there were some changes in the team structure a few times) and I can't begin to describe how happy I am we are using TS. A lot of new functionalities the client asks from us involve adding or refactoring something in a controller you haven't touched for a month but someone has possibly refactored it completely, or reusing a complex component with around 20 props that you took no part in developing. And from experience, the more specific the types were in the code (no any, or Object, or Function without parameters and returns defined) the easier and faster I could write the new feature. And if the task was a bug fix, half of the time somebody somewhere wasn't specific with the types and another person made some wrong assumption on what something is and the thing propagated God knows where and caused some unpredicted behaviour. And yes, we had typing issues, around once a month we add something larger to the project or do a major package update, but losing that 1-2 days of a single persons time to fix the typings (or write our own) and possibly refactor something is a lot better than losing around 3-4 days of everyone's time on finding an error that could have easily been avoided or noticed earlier by using types.

You're not alone, I find that in practice I stumble over the holes that exist in Typescript.

Some of the benefits are nice, when creating an API for some library for in-house tooling. You get type completion, and so do your coworkers.

When you're on a path in Typescript that is "sound" and you're not tripping over the holes in the type system, I find that I code for longer before execution. It's a lot less short trip iterations between coding/checking.

Having coded for 25 years, in various languages typed/untyped(or dynamic)/compiled/scripted - I find that I have massively different behaviors in the typed/untyped languages.

In untyped language, I'll write smaller functions with tighter contracts - things that are quick easy to write tests for and then I'll combine these functions to get my primary goal done.

In typed languages, I find that I can get away with much longer functions, trusting the typing system to enforce parts of the contract for me. I find that I also skip writing tests.

Typescript while doing what it says it does, and enabling static analysis of your code, to me, tends to feel like it's in the way more than it's helping.

One of the biggest issues that has plagued me, is if I have strict typing, I want strict typing! I want to announce the purpose for some elements quite explicitly. This has been shot down in code review as being "overly pedantic"

type RecordID = string;

because in some cases due to sharding, our record id's are actually

type ShardRecordID = { shard: string; id: string };

The prior can be decomposed into the latter

function toShardRecordID(id: RecordID) {
}

I get a bit annoyed here because, I can't stop typescript from allowing any old string from going in there. AFAIK there's no way to say "look don't allow anything that isn't a RecordID from going into this function" - If someone wanted to cast a string to a RecordID when calling this function, be my guest, but don't allow it by default!

Which leads me to RTTI, we type all of this stuff into the system, and what do we get for it? Notta! It's lost after compile. FUCK THAT, I want the option for this stuff to be composed into the JS files.

I would love to be able to create pieces that do run-time validation of values, especially the parts that interface with legacy back-end API's Think of all of the rules your interfaces declare that are .... basically useless because you're legacy backend DGAF! Would you like a string in your number field?

I see a lot of "you need typing to build complex system" and it boggles my mind. I've build huge comprehensive systems with and without it, and I don't run into any of the issues that people seem to scream about.

I think the biggest benefits are probably there, but more obvious on teams with more people and with varying amount of skill, and capabilities. Where the type system prevents you from shooting yourself in the foot, but until the above type strictness is solved for me, it adds another layer of cumbersome domain knowledge to a codebase, while eliminating some other.

This reminds me of a thing I did back in the PHP days, trying to enforce parsed type safety on a small team of juniors. I'd created a few functions to do safe parsing of a value from the post/get that returned something like this.

array( parsed => 'pass', value => parsed );

The service layer I was responsible for would reject if any value passed to it was not safe. It was annoying to work with at times, but so were the bug reports from security validations. :/

Oh that feels kinda dirty but I see whats going on. the _recordIDBrand: never - is just thrown out, it's not referenced anywhere else.. correct?

In your opinion, Is it overly pedantic to declare these? It's just extremely formal to me, and makes a lot of sense to do so. In some fairly particular use cases.

In this case I would have been justified - What I was doing was refactoring some API code to handle technical debt, so I was using a big hammer - enforcing types - and noticed some variable reuse of the string id due to naming, so I wanted to wipe the slate of the variable reuse issues. (No bugs related to it, but ... ffs WHY!)