How an Anti-TypeScript “JavaScript developer” like me became a TypeScript fan (chiragswadia.medium.com)

Agreed, though at least there's one less developer writing about the "TypeScript Tax".

The heuristic of "new JS tech is just needless complexity/over-engineering" is not a bad one to have in the JS ecosystem imo :)

Yes, type checking do not require a new language.

I find your interpretation and subsequent extrapolation on his qualification as senior unfair. He clearly tried TS and was frustrated by his initial experience, because there were certain things he had a hard time understanding or justifying. There's no opportunity for broader self development here. I try stuff out and I scratch my head, should I risk sticking with it or should I move on. It's a gamble. Others have made the alternative bet with a different tech du jour and lost. So your results may vary.

I think moment when I really could call myself "senior developer" came when I realized annoying things I was struggling with are not stupid, it is just that I don't understand them very well.

I’d consider myself senior. I’ve been using Javascript since it was beta. I like Javascript. I don’t mind TypeScript. I mean, it’s nice and all but it doesn’t strike me as the be-all that others make it out to be. Maybe I just don’t use it for the types of project for which it was designed.

It’s like I’m a metal worker and I get along fine with a ball peen hammer. You come along and give me your claw hammer with great excitement. Sure, it can mostly do the same job, but my ball peen hammer is what I’m used to so I’m sticking with it.

Senior does not mean "all around great zen person". It means an experienced person.

Seniors occasionally rejecting this or that, seniors occasionally blindly accepting this or that are both completely normal in majority of seniors.

Senior probably means they've been doing JS for decades before TS was invented. They got along just fine without it for so many years, why rock the boat now? Or maybe it is more of a Senior person has a ton of work to do and not enough time to do it in so there isn't time left to learn a whole new way of writing JS. Or maybe many of the errors TS is meant to catch, the Senior developer has already learned over the decades not to do that bad thing, so they don't see the need to adopt TS. Or maybe they are just jaded and tired of learning new things.

I think the skepticism of new shiny things is healthy. Of the set of things that exist, most things are worse than the things one already uses/prefers. Most new things solve a specific problem that may not overlap with the problems one is trying to solve. With software development, a huge part of the puzzle is tooling (as the article points out), so even if typescript is obviously superior as a language, the tooling needs to catch up before it's a reasonable/useful alternative. In this case, the tooling quality, enabled by the static typing, shot typescript way past the thing it was replacing.

    VerboseTypeName foo = new VerboseTypeName();

Agreed. A senior engineer should know when they don't understand something and keep an open mind about it rather than rejecting it outright.

If this article started with legitimate reasons for not wanting to adopt TS it would be different. "It is hard for people to learn" is actually a legit reason but "I don't understand it" is probably not!

That doesn't imply all new things are good or that senior engineers need to understand all new things either. I think there is some confusion about this.

Skepticism !== reject everything without grokking.

I think that he is presenting his prior attitude towards typescript a certain way for dramatic effect / so that it was easier to write a blog post about it. In reality he probably was not as skeptical as he sounds here -- otherwise we wouldn't be reading an article by him about how great typescript is.

Ironically, as someone who has experience w/ both fast-and-loose JS and with "properly" statically typed languages, my beef with typescript is precisely that it allows people to be fast and loose, sometimes in ways that are not super obvious. For example:

    type Thing = {
        name: string,
    };

    function getThing(): Thing {
        return JSON.parse('{"error": "invalid id"}')
    }

    const thing: Thing = getThing(); // lie to me!
    console.log(thing.name);

This is a trivial example to illustrate the idea that it's relatively easy to make a type that cascades through a very large app but which is backed by a complete lie.

I definitely think that there's also something to be said about meta-programming yak shaving (e.g. people wasting hours trying to write a "function" that takes an enum and outputs another enum w/ a fixed prefix, when simply writing out the enums would've taken 30 seconds w/ VSCode's multiple cursor feature)

Personally, the value I see in TS is in cementing documentable facts about a system: e.g. such and such function takes such and such well-defined entity, dot not treat this `options` argument as a generic bucket for pass-through garbage.

    function isThing(value: unknown): value is Thing {
      return typeof value === 'object' && typeof value.name === 'string'
    }

As a "senior" I'm still not sold. Running across bugs in the type checking that blocked us for a while (trying to avoid Broken Windows to boot) and the fact our development times skyrocketed (including on personal projects) or that the answer to poor tooling was "just use VSCode" is not something that really screams "developer friendly".

Senior here. I was afraid if typescript will follow C# or Java's type checking. Both are too strict, verbose and inflexible.

I was afraid to introduce complex generic types because it isn't easily represented in typescript, or to change a struct from "person" to "employee" will need to map each properties individually.

Thankfully that wasn't the case.

I can't speak for the author, but I can speak from a similar path. Speaking for myself, I was self taught, and to even have a toehold in any kind of career I had to learn to prioritize advancement. Not having an educational or theoretical background, that meant evaluating "what seems most effective right now". I was late to adopt TDD, late to static types, late to FP, late to a zillion things... because I was prioritizing not being sent back to broke/poverty life. Once I had enough air to breathe I realized all of these things help serve me staying out of that misery, but the urgency of learning in the field doesn't always give room for that analysis.

Naming is incredibly hard, though. And refactoring is hard.

It's a pain in the neck when something starts out as bla_list or whatever and you discover that after half a decade of changes bla_list isn't actually a list anymore, it's a dictionary, and that it doesn't only hold Bla these days, it can also contain Foo or Bar. This type of stuff is immediately obvious with modern static typing.

I guess static first is a chore because at that point you have no idea what invariant or structure is required for the task. After prototyping you know where to tighten the bolts.

SQL is not typed, it is just text sent over a network or whatever and then parsed...

Seems like an easy cutoff is when you add a build step as opposed to just including your script on the page. If you need to use Webpack for a project, you might as well add TypeScript as well.

> I also think static typing has the benefit of enforced self-documentation a bit, so other developers know just by checking the type what sort of data they should expect to see in there, and not trying to give it garbage to begin with. Granted good variable naming and proper documentation would alleviate that, but that's never been fully consistent at any organization I've ever worked for.

I don’t think naming is fully alleviated by static typing; however, on the other hand, static typing allows IDEs to offer better refactoring capabilities, since they can presumably build such functionality on top of the compiler’s structured syntax tree representations.

As an example, lately I fairly frequently find myself using VS Code capabilities to rename TS identifiers as my code evolves. It always handles correctly the scope and everything, I’m sure it’d be more error-prone with plain JS.

Agreed about statically typed code being more self-documenting in general. It’s a bit of a double-edged sword in that it may give an illusion that your project is easier to understand than it actually is, but it usefully shifts the focus of documentation from minute details of code itself to subject domain specifics and how you represent them in your architecture.

I use type annotations in Python no matter what. It really helps skim the code faster and mentally understand what values I am expecting. Its very useful to know which var is a List[dict] and so on.

I don't like TS because javascript is just a silly language to do anything serious with (besides front end), and its so stringent it takes forever to write quickly.

This argument also holds for backend development. I've spent days trying to get a big Java app working with Jboss at a new place, it was more or less a rite of passage when joining the team. Also setting up some local obscure Microsoft IIS setting because reasons.

These days I find frontend tooling quite delightful, Typescript for instance Just Work(tm) our the box.

> You have to set up so much

I think tooling has mostly addressed this, or at least provided a mostly braindead path for 90% of needs. For example, npx create-react-app $YOURAPPNAME sets up practically everything you need to get a reasonable react app going, at least in terms of the transpiler/set of plugins. It makes very few choices re: actual react libs though (no preferred router, flux, etc). The preact equivalents are somewhat more opinionated, and go a bit farther in setting up routing/splitting nicely for you.

> This makes me feel very insecure about my code.

I get this. While I stand by what I mentioned above, it also makes me nervous that I understand so little of my setup given how much of it was setup automatically for me, which makes me trust the environment less. FWIW, outside of web dev it seems like _most_ people have no idea how their setup works re: compiling a project. How many devs for say postgres understand the make file or configure scripts? Probably not that many. Maybe that's getting better with newer tools like cargo, but web dev always seemed like the exception wrt understanding the bundling environment, and we're just now catching up to the level of complexity that other types of dev have had for decades.

Edit: apparently that was a bad example. Postgres's make file is very simple: https://github.com/postgres/postgres/blob/master/Makefile

The configure script is less so: https://github.com/postgres/postgres/blob/master/configure

I've spent the last two years writing my own framework because I hated React so damn much.

It really doesn't have to be that complicated. Granted, I still use a bundler, but it's really easy to set up. I had my friend walk through it all... he seems to think it's great.

I should probably release this project some day.

If you're anything like me, once you've swung back in the other direction for a while you'll synthesise and realise that engineering is choosing trade offs and that every tool has an area where it shines - so its worth applying that tool to that area and not treating every problem like a nail to be hammered.

Of the languages you listed, Java is the new kid on the block. Python is older than Java.

> but overall it reads like a typical transition from thinking static typing is a burden to realizing type safety can be incredibly useful.

I got this impression too, I was just like the Author in that I hated static type checking as a Junior, but as I gained more experience it flipped from "I hate this" to "this is the first thing I implement in a new project".

To your point of thinking that newer languages being "better" than older ones. I think that also comes down to experience. At first I thought the same way, but the most experience I gained the more I realized that each language is a specialized tool for using in specific cases, some tools are very very specialized (WASM for example) while others are broad (like Javascript).

In my team people object to TS due to a few things: additional complexity, additional build step, build time increase, copy-pasting code around (to console, code snippets etc.) does not work anymore (but last time we talked it was soon after coffeescript -> esmodules migration and I guess everyone was tired of coffeescript which might have affected the mood).

There's no unanimous consensus that TS is all gold; some people who are fine with types don't like certain TS implementation details and in fact some devs start saying out loud that sometimes it's very difficult to fight TS with certain constructs.

Something that's gaining popularity and what I'm trying lately is using JS + jsdoc annotations more thoroughly, which gives the niceties of TS (when using vscode) without the downsides and heavy compilation step:

https://www.typescriptlang.org/docs/handbook/jsdoc-supported...

Typescript is more popular now because projects are migrating more and more business logic layer to front end. Thus the need for type safety and static analysis.

I’m agnostic about Typescript. Bare JavaScript is very efficient and optimized language, well suited for smaller projects.

However, when project scope balloons up, then Typescript becomes more useful. It’s way of enforcing descriptive comments a code, than trying to be a type safe language.

The value of TypeScript is a function of the codebase size, size of team, and length of time for maintaining this codebase.

If you're an individual, putting together dinky little web sites that you don't need to maintain for years - the value of TypeScript over JavaScript isn't as pronounced.

If you have a web application that counts hundreds of thousands of lines of code, maintained by team of developers over many years - JavaScript does not cut it ... at all.

Do you use a different solution for frontend web development, or is frontend web development a domain you get to avoid?

what are alternatives?

python's tabs?

    function foo()
        doSomeStuff
    end

that's an odd take considering the article is comparing JS/TS which have an identical amount of curly brackets

Oh boy do I have a programming language for you. Enjoy! https://en.wikipedia.org/wiki/Curl_(programming_language)

Yep, I'm a firm believer in using TS pragmatically. Type the obvious code (React component props, API responses, function arguments), and start by aiming for an "80% sweet spot" of type coverage. Don't get into arguments with the compiler, and avoid writing really complex types unless you've got a key spot in your code where adding that type now makes it a lot easier to infer types in other places:

https://blog.isquaredsoftware.com/2019/11/blogged-answers-le...

> Like you have a react hook and some components that you can compose, and the typedefs just become unwieldy and impossible to get right. Often they end up not even catching what should be compilation errors.

I’m curious - how do Elm and Kotlin solve these problems in a way that balances the often competing goals of “add types to reduce errors” vs “have a high productivity environment where it’s quick and easy for engineers to write new code”?

Basically in the same boat, although I still use TS as it's become kind of defacto in JS land, I'm not sure that I dislike it so much as am not sure it's always worth it. Maybe I tend to approach it too much like Swift or Kotlin and get annoyed when a dependency is missing typings or the compiler is so easily tricked/lax about a lot of the actual type-saftey.

Maybe putting Typescript it into the bucket of a "better linter" is the mindset to have.

I had this too - when I first started I fought typescript quite a bit. I struggled through this because I kept finding more and more code on github that was TS, kept seeing more articles that were TS, kept seeing big improvements from MS on TS, etc. So I kept learning the best practices and trying to understand why I shouldn't use "any[]" or "{key: string?}" and so on - trying to get past the parts where I wanted to be lazy. Eventually on one of my projects I had to reorganize my model structure, where some classes held other classes and so on. I had to both move one and rename one. This was early on, but since I did a reasonable job with typescript, I was able to just run `tsc -p .` over and over and it found all of the places I missed, which were far more than I would have guessed. It only took maybe 20 minutes to do that massive refactor. From that day forward, I really enjoy working in typescript. I think it's different from (some) other strongly/statically typed languages because it allows you be be a little more expressive in what you're defining. Perhaps expressive is the wrong word, but I find that it's quite flexible in this area, and I really enjoy that because if I take the time to flesh things out it can really help me find or prevent bugs.

TS has a bit of Java feel to me. Forces me to follow all kinds of hard compiler requirements that take some time to implement, like generics, but then there's still all of these edge cases like null-pointers that make it feel like you're still building a house of cards.

Kotlin and Elm are more functional, don't know about Elm but Kotlin has non-null pointers as a base feature of it's language, not some later bolted on tie-wrapped solution.

Not all type systems are created equal. I could see how someone whose only typed language was C++ could think that it’s a waste of time.

> Maybe for small scripts, static typing doesn't provide that much value (although even then I don't really buy it - why wouldn't you want to know what you're working with at any given time), but for sizable (web) applications that need to be maintained for years, it's critical.

It's common for web devs to spend a lot of time dealing with semi-documented lumps of JSON. If you don't have any guarantees about the data in the first place then static typing ends up being a lot of pain without much benefit.

Sure, the situation is far from ideal. But when you're in that situation static typing isn't solving your first problems.

What exact value does this comment add other than some weird attempt to give off some air of superiority?

A lot of of people are "discovering" TypeScript because it is the first widely used and well supported attempt to bring static typing to a language that is currently the only mainstream option for programming to web.

I have 15 years experience and I agree with you completely. The TS propaganda is so intense that I'm seriously wondering if Microsoft is paying people to shill TypeScript... I just can't figure out why they would do this but the degree of misinformation and downvoting is so intense that I can't think of any other explanation.

That would be the way to get the JS ecosystem out of the mud. But it would be great if there was a way to ensure nil and type safety on the level of Kotlin, Swift, Rust etcetera and build from there. TS is more like Java in that aspect.

I kinda like what you are saying, but it's not that clear-cut in my experience / skill-level.

One can write code that would work correctly, but trying to express the types as precisely as one would like may be painful and doesn't necessarily be productive.

Sometimes when I feel it is cumbersome to express my intent in typing, I may feel satisfied enough to make a runtime check, (and perhaps add a note but depends...). Especially if that functionality is used in scoped area (e.g. module) and not exposed to the rest of the app.

When trying to make a generic and flexible functionality, the typing experience seems get harder and more time-consuming for human to grok, and it may not even be that useful when you look how the code is used.

So I usually try to make typing as good as I can by finding documentation related to what I'm trying to do and banging my head to the wall from a couple of angles, and for some specific parts I may give up and type any.

Perhaps sometimes when typing feels hard it may tell that the abstraction is just plain wrong, so there's that plus side!

Same. Lead dev here.

Part of my problem stems from the lack of typed libraries across the JS ecosystem. Party supported typing leads to more issues, I've found.

Then there's the IDE. I don't use code hinting. In fact, I find it irritating. So, I draw no benefit from TS in this regard.

Then there's the cryptic error messages. They've gotten better over the years but I always seem to spend more time debugging TS than writing code.

And finally, I just don't run into the kinds of errors people talk about solving with TS.

That said, I did enjoy the strong typing that AS4 provided back in the day. But TS is intolerable to me and I've worked with it for years.

> I haven't worked on any projects that were large enough to warrant type checking or where I felt it would make a huge difference.

Can I esk exactly how you're considered senior if you've not worked on any projects large enough to warrant type checking?

Same here. I still do not get it. I see the benefits of typed languages for use cases controlling binary data, like hardware controlling, drivers or binary file formats.

And actually you can write very type safe code in pure JavaScript.

1. (arg) => if (typeof arg !== "string) throw new Error()

Of course, this is executed during runtime (which could have benefits too sometimes) and not at transpile time.

Yes, you can laugh at me. But.. You should be always aware of the types you are using, which data is coming in and if the function is type critical, which is only the case for some functions, it is even more fault safe doing it this way, because your app is spitting an error during runtime, which will definitely be fixed very quickly. :) To validate data, use typed structs.

2. You need to write good tests anyway. Tests should test with malformed and faulty data always.

I and the teams I had, maintained and coded big JS applications. I can remember only one case, where TypeScript could have been helped with typing. But also, we had no test written for it, so..

This is my problem with TS. The underlying JavaScript peeks it's gross head through the cracks way too much. I end up not bothering with types since they're often wrong at runtime anyway.

If "| undefined" is spreading through your code like a virus in cases where it's not actually optional, then I'd argue that the problem is upstream where the data is ingested, and the code should be enforcing "must be defined" at input validation so that you can carry a clean "Color" type everywhere else.

If it's about optional parameter weirdness and TypeScript's lack of method overloading, I suspect that's inherited from JavaScript's laxness with method signatures. I don't like it either.

assuming you meant

  let myColor: Color | undefined;

I don't understand what the problem is. Native JS would require you to define the starting scope of the variable (unless you're relying on global scope!).

Then you declare what the type is: Color or undefined. The state of the variable can be one of two things. Perhaps I've been writing TS for too long but I think I'm missing the problem here.

Yep. My experience as well. In a large project, the types often end up being pointless since you can easily just ignore them at any time, and the "compiled" JS will just happily go along with it all. Eventually I hit a point where I wonder why we're even bothering using types.

bingo.

TypeScript had absolutely no excuse to keep JavaScript, beyond the misguided idea that because so many JavaScript developers exist that it should be easy to get them to learn types.

First, they introduced a compiler. At that point, you may as well toss out JavaScript for a better language that actually has nice type syntax. TypeScript syntax is horrible. It makes JavaScript completely unreadable in many places.

Second, JavaScript developers tend to be the type that have never learned another language beyond JavaScript. They come from bootcamps and elsewhere that only teaches JavaScript and that's all these developers know. They do not have the experience necessary to not make a mess of TypeScript's structural typing system. You'll end up with incoherent ad hoc types all over the place. You still have JavaScript's ad hoc data flow all over the place, but now you have TypeScript yelling at you while trying to formalize the mess and failing badly at it.

What I find is that often when people say they like TypeScript they really mean they like VSCode.

TypeScript is unnecessary. Type incompatibility is not a big problem at all... It's the easiest kind of bug to find and fix. The simplest tests will typically catch those bugs even when the tests are not explicitly looking for them.

On the other hand, issues related to parallel async state mutations which involve race conditions are very common in complex projects and are very challenging to debug. Type incompatibility issues are a walk in the park. You don't need a type checker for that. Just because your boss is incontinent doesn't mean that you also need to wear an adult diaper!

Yes.

I write large Node projects and Electron apps and TS has been a huge help.

Looking at the Internet Archive for typescriptlang.org, most (but not all) of their original samples are doing something in a browser[0], so while it definitely became popular with backend developers, I don't know if I would go so far as to say it was created for non-frontend developers who were forced to deal with the frontend.

[0] https://web.archive.org/web/20121004030106/http://www.typesc...

I don't understand any arguments of this variety because TS just compiles to JS

TS hasn't changed the way I write applications too much, besides giving me a bit of safety/enforcement of good practices and productivity boost

If you are working on the server side, ts-node has been a huge timesaver. It removes the extra step of compiling and lets you just run your script with `ts-node script.ts` or even `#!/usr/bin/env ts-node` at the top of your file works.

https://github.com/TypeStrong/ts-node

FYI, tslint is deprecated since 2019.

Most people use eslint. But eslint on TS is excruciatingly slow.