Hacker News Reader

Comment by madeofpalk | Hacker News Reader

It's probably worth taking a step back and interrogating why the actual "Why was I Anti-TypeScript?" a little bit more and use it as an opportunity for broader self development.

The author didn't use and understand something, and rather than trying to they instead just defaulted to rejection. It's midly disapointing seeing this in people who label themselves as "Senior".

View on HN

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.

If you have to rely on restrictively typed languages to produce maintainable code, I think that’s a different topic.

Typescript isn’t perfect by any means but it does a good job keeping code based easier to work with in a larger team. Much better than vanilla JavaScript

The "curse" of Typescript is that it's built on Javascript, so you can tell it to lie to you all the time. This is the problem with introducing Typescript to a larger group of Javascript developers who arent all on board (because of either experience or being stubborn) - you still need to establish good habits and patterns for how to write typescript.

I'm working through the very lie you're showing now because the disclipline wasnt established from the start to avoid these anti-patterns. Typescript isnt the perfect magic bullet that will disappear all your problems - you still need to have good developers writing good code, but TS will make it easier.

In the large this curse is true for everything. The difference between 8 u8s and an f64 is thin for all architectures I can think of.

> you still need to have good developers writing good code, but TS will make it easier

Very true. Typescript is still immensely helpful in the sense that it will complain if you pass a Thing to a function expecting a Foo, regardless of the fact that Thing is meant to be a thing but is actually an error.

But IMHO, by sticking to a decision to be lean in terms of transpiled JS, TS suffers greatly from cases like the one I showed. It would be great if the compiler enforced that these types of unsafe casts had to be explicitly specified (even if via some strictness flag), and even better if it could do a better job at refining types through runtime constructs like `if (typeof thing.name == 'string')` (it does do it to some limited extent, but not enough to cover many common scenarios, due to the curse of targeting Javascript, as you mentioned)

You can easily write your own "type guard functions" when you think TS is missing an inference from a runtime check you would like. The syntax is simple enough, it's just a slightly different return type from boolean:

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

The `unknown` type in general is still pretty new, but will be greatly helpful for cleaning up a lot of code that assumes a type or used to use `any` or `{}` because there wasn't a better type to use in that situation. The Typescript team is hesitant to change the last few cases of `any` in lib.d.ts to `unknown` directly (such as `JSON.parse`) because that would be a big compatibility breaking bug. There was a proposal for a flag to do that (treat `any` as `unknown` in lib.d.ts), but I'm not currently aware of whatever happened to that idea. I would love to see it or something like it happen.

User-defined typeguards are just fancy ‘as string’. They are not type safe.

They localize all the unsafe type casts to one place, where you can inspect the logic, though. Much better than having `as string` sprinkled throughout your code.

It's worth noting that this (good) example is unrelated to unsoundness, too -- it's related to built-in APIs using 'any'.

Within Google we include a "strict" d.ts in every compilation that shadows this API (and one other) with one that instead returns "unknown". We have talked about going through the whole TS API and removing all the 'any' in this manner for this reason.

That's a great idea! What's the other built-in that you shadow?

The definition of `new Map`:

https://www.typescriptlang.org/play?#code/FDDGHsDsGcBcAJrwLz...

(I still think this is actually due to bug in TypeScript, see https://github.com/microsoft/TypeScript/issues/31990 .)

This is an argument against strongly typed languages, not Typescript. You could do a similar thing in Java and C#.

I don't know of any language that can stop someone from being a sloppy coder.

It's actually the opposite. This would throw an exception in a strongly typed language. It would silently return the wrong thing in javascript because it's not strongly typed.

The point of the argument is catching errors at compile-time. Typescript doesn't make (and can't make) any guarantees at runtime.

In case it wasn't clear, that example compiles without error, whereas a more strict compiler would complain that a any is not a Thing, or some similar error.

The code doesn't even throw runtime errors, but you wouldn't be able to tell something is wrong unless a) a request providing the json string actually responded with the error string in the example (an edge case that is very easy to overlook during regular development) and you managed to catch the problem in tests, or b) you specifically went digging into the file that defines getThing looking for the implicit any cast that the compiler didn't tell you about or c) there's a compiler update that turns that any cast into an error

What others are saying is that Java and friends do c) (throw compilation errors when implicitly casting between incompatible types)

Java would absolutely stop you from returning a JSON object when you're supposed to return a Thing. You could cast it but you'd still get a ClassCastException. Now I haven't written JS or TS, so maybe I'm not understanding what you're saying?

Just like Generics in Java, Typescript only exists at compile time. Talking about what Typescript doesn't do at runtime is moot.

Typescript permits you to write code that does implicit unsafe casts at runtime. Type-safe languages don't. Java Generics don't let you implicitly do unsafe casts[1]; erased generics mean the unsafe cast wouldn't necessarily fail visibly at runtime (though there are warnings and linters to alert you to that, and techniques to work around it), but it would enforce that it was explicit in the code (and you would then know to add extra test coverage etc.).

[1] You can implicitly do unsafe casts using arrays, but arrays aren't really using generics, they're a special-case builtin.

The example above is equivalent to gson.toJSON(string, Thing.class)

It'll just return an empty Thing right? No ClassCastException.

No, those languages actually enforce type checking at runtime. The libraries for parsing JS that support parsing into a custom type will blow up right there if the provided JSON cannot be parsed into the provided class, not 5 steps later when you try to use something from that class that isn't actually there.

Typescript doesn't exist at runtime.

If you're not using a bunch of generics, check out typescript-is [1]. It takes little work to get it setup, but it generates run time type checks for you. I understand why typescript decided to not add this functionality to the core of the language, but it's starting to feel like the largest missing piece of typescript is a built-in way to generate run-time type-checks for user-defined types from just the type definition.

The happy medium we've found with that module is using the runtime type-check on anything "unsafe" to bless the result using typescript-is's equals functionality, but still allowing programmers to use casting with a comment justifying its necessity. For us our list of unsafe is results pulled from the db, anything parsed from JSON, and incoming request bodies (which can be a special case of parsing from JSON, but not always).

[1]: https://github.com/woutervh-/typescript-is

Doing runtime-typechecks really is a blessing, and it would be great if typescript would provide this as a language-feature. There are two more libraries I know which are great for that:

* Zod: https://github.com/colinhacks/zod * io-ts: https://github.com/gcanti/io-ts (for the more functional-programming-oriented)

We decided against io-ts because we'd still have to write the validator ourself (unless we used their type system as the source of truth, which wouldn't easily work for our project because we generate most of our types from an openAPI schema), which is exactly what we wanted to avoid doing.

I hadn't heard of Zod before, but i really liked the "parse don't validate" blog post linked. Turns out that's exactly how we've been using typescript-is. But it still suffers from the problem of expecting to be the source of truth and thus not working well with generated types.

I like io-ts, but I've moved mostly to runtypes: https://github.com/pelotom/runtypes

I forget why Zod didn't pass muster for me now, but I've looked at it before and didn't find a compelling reason to jump to it. Thought it seemed good, though.

I really wish at least one of these let you emit JSON schema back out, though. That'd be way easier for dealing with stuff like OpenAPI.

We go the other way. We start with openAPI, use dtsgenerator to spit out typescript types, and then use a library (typescript-is) that will generate run-time type check function as part of compilation.

A downside to this is that you need to compile type changes before you can use the change in code, but it gives us a single source of truth for our type definitions and let's us generate a more exacting request and response verification functions that use the (sometimes) more precise open-api definitions (eg a an array with a maximum number of elements and specific string formats), and it's really easy to add a run-time type check to the result of calling into a 3rd party library as well.

For runtypes, you could write a script to use its Static function to spit out the interfaces in pure typescript and then use something like typeconv or ts-to-openapi to make your openapi definition, and then use that script inside your build script to output the openapi schema.

Interesting! How do you wire it into validation, etc. for your web layer?

If you've got an example I'd love to see it. I've long been not a fan of OAS-first, but I'm always down to learn something new.

We like OpenAPI first because it's more exact than pure typescript types. I suppose there's libraries we could use to give us a similar level of exactness that would also get us typescript types and OpenAPI with similar exactness to openAPI first, but then that's another dependency that's not giving us anythign extra compared to openAPI first.

So the way we do it is a little meh because we have two separate run-time type validators, but it's because of the path we took where we adopted request and response validation almost from day 1, and other runtime validation came much later.

We're using express and express-openapi as the base of our project. Express-openapi has built-in request validation and type-coercion, and an example of how to quickly bolt on your own response validation, so for request and response validation we're using that. And it works. It's damn solid. But the docs for how to use the underlying tech to do similar run-time validation for say pulling values out of the db is lacking and I don't have enough expertise in the underlying tech to stand it up quickly, especially compared just dropping in typescript-is changing tsc to ttsc and adding an tsc plugin to our tsconfig.

If I were to do it again I'd either bite the bullet and spend the time figuring out how to get express-openapi's request validation infra to also do general type validation on just the schema, or i wouldn't use their run-time validation at all and just make my own middleware to do it, just so that I've only got a single run-time validation library. The nice thing about express-openapi is that since it "knows" the open-api definitions it can programmatically apply the types needed for validation, so rolling my own would require that functionality, because I don't want our team to have to remember to add the same middleware to every endpoint using a factory function that takes the typescript-is validator function as an argument, and the nice thing about typescript-is is that i can give it a typescript type and get a validator function exactly where i want it with no muss.

Anyway, our build looks like this: 1) compile typescript 2) compile the openAPI to a single file (we put the endpoint definitions in the endpoint file) using express-openapi (just initialize and then write out the JSON.stringify of the apiDoc field) 3) run dtsgen against the output of step 2, and pipe that through `sed 's/declare//g' | sed 's/namespace/export namespace/g'` and into some file.ts 4) compile the file from step 3 with typescript

step 1 gives us typescript compiled to js step 2 gives us a single openAPI.json file we can pass around or import into postman step 3 gives us all the types from openAPI in a ts file with a bunch of recursive exported namespaces step 4 gives us those types in a .d.ts file

We do 3 and 4 in a subdirectory so that we can publish the types as an internal package, which means we can give front-end a types package to consume for all the calls we want to make to backend. Well, we actually publish an sdk package that wraps the types and encapsulates the logic for making the HTTP request to the right endpoint, so we don't have to worry about calling POST when the endpoint is PUT or fat-fingering the response type cast through the entire front-end and can instead just call a function with well-defined types. Plus, now it's super easy to test the interface, because we have a single thing we need to test. So we write an exhaustive happy-path (ie 2xx status codes) integration test against the sdk that actually calls into backend gets the response and checks the response against the type and then the values we expect for each field.

Just a quick tip that helped my team with such issues:

- For every call to an API, or input from the user, there should be a few tests checking for unexpected data

This rule alone forces us to fix the majority of runtime errors such as this example (since JSON.parse() is usually called when handling an API response)

You're not wrong. That's a good example of why someone might have beef with typescript. But as others have been saying, tooling enabling faster dev is one of the main reasons people use typescript. Safety comes second for most folks. And the tooling works just fine in that example.

This particular example is close to my heart: the definition files for things like JSON.parse() were written before the "unknown" type was introduced as an alternative to "any"

And because this "any" is coming from an external definition file, it can't be caught by tsc's --noImplicitAny nor eslint's no-explicit-any

Those two rules allow us to protect us from our own code, but not external definitions/libraries. Relevant GitHub issue here — https://github.com/microsoft/TypeScript/issues/26188

Looks like eslint is working on a new set of rules that would help with these currently-unprotected any cases: https://github.com/typescript-eslint/typescript-eslint/issue...

> Create a rule which uses type information to determine when you're inadvertently breaking type safety by using an any, potentially without knowing.

> Often libraries (or even the typescript defs themselves) can have weak(/lazy) types which return any. If you're not careful, you can inadvertently introduce anys within your codebase, leading to bugs that aren't caught by the compiler.

> (e.g. people wasting hours trying to write a "function" that takes an enum and outputs another enum w/ a fixed prefix...

Metaprogramming shouldn't suck so much that this takes hours.

Sure, but you also should never just blindly trust a JSON.parse, and if possible you should avoid typing functions for exactly this reason, and let their return types be implied instead. If you didn't type `getThing` then its return type would be `any` and you'd get an error in your IDE on the last line.

sorry but i feel like this is backwards. the error - incorrectly assuming an `any` will be a `Thing` - is in `getThing`, and that's where the error message should be. getting an error in code that calls `getThing` instead would just obscure the real issue.

also, i think "avoid typing functions [...] and let their return types be implied" is terrible advice. argument and return types are the thing you should type explicitly, because it makes the errors local. otherwise you'll get all the fun of tracking down where that `null has no property "blah"` error came from, just at compile time

If you don't annotate the return value you open yourself up to another class of mistakes because the compiler can't check that each branch returns the correct type, especially if type inference decides the function returns `any` which swallows `undefined` in type hints, while also losing the self-documenting aspect without an IDE.

Check out io-ts — it can take a minute if you’re not familiar with functional programming, it’s built on top of fp-ts.

Being able to encode/decode IO safely has been a huge blessing when working with JSON.

This is the one thing that bothers me about TypeScript as well. I've ended up using frameworks like `zod` to do runtime type checking of endpoints. It has gone a long way towards decreasing edge case failures -- I just wish they had something like this built into the language.

Not doing runtime checks is a deliberate decision: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Desi...

So Zod it is. I like it.

To me, the solution is simple: use a single source (some IDL format) to define objects at API boundaries and have your frontend and backend use it.

It will make it a lot harder to return wrong types from your calls. Personally, I like gRPC + Protobuf.

Wait... so I assume `JSON.parse()` returns `any`, yeah? TS automatically downcasts (in function returns and assignment)? How is that at all useful?

It's a historical artifact of Typescript's development. The `unknown` type wasn't introduced until Typescript 3.0 and since `JSON.parse` is part of the Javascript "standard library," changing it now would be a brutal breaking change across almost the entire ecosystem.

this seems to be an issue with bad typings - ideally `JSON.parse()` would return `unknown` and then it wouldn't lie to you, but that would probably break a lot of people's code.

EDIT: https://github.com/microsoft/TypeScript/issues/26188

I've always told folks that no technology will save you from your own developers.

A good application can be written in any technology, just like a bad application can be written in any technology.

Certain technologies will try to guide you to a better place, but it's up to developers to take advantage of it. Or to do crazy stuff like the above. . .

The problem in your example isn't TypeScript. It's the JSON parser. If you used GSON in Java, you'd get the same result, despite being statically typed with runtime type checks.

You can implement the JSON parser to be type safe. For example, this is how nest-dto can prevent this.

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.

Strong typing is not shiny or new and, even if you're a javascript guy, not being remotely familiar with any strongly-typed language (or generics?!) is a red flag.

(edit: red flag is a bad description, because he ended up being self-reflective and looking deeper, which is just about the furthest thing from a red flag.)

Agreed. But some people have an attitude of Strongly Typed == Needlessly Verbose. Probably because most developers have only experienced Strong Typing via Java.

I'm in neither camps (I don't have anything against types in places but I also don't try to put them everywhere). Could you explain how TypeScripts types would be more/less verbose than the types from Java? At a glance, TypeScript looks a bit more flexible, but mostly the same.

Then Java is a verbose language in general (forced directory structure, one-class-per-file and yadda yadda) but that's besides the point as you're pointing to TypeScripts types being less verbose than Javas.

1) TypeScript has local type inference, meaning that `let x = returnsComplicatedThing();` will work, where in Java it would be `Complicated<Generic<Type>> x = returnsComplicatedThing();`. (At least up until the last few years)

2) TypeScript has type aliases, meaning you can write `type MyTable = List<Map<string, number | string | Foo>>` and not have to repeat yourself everywhere.

3) TypeScript has anonymous unions and tuples, so instead of writing `Triple<Integer, String, Foo>` you can just write `[number, string, Foo]`, and likewise instead of `OneOf<Integer, String, Foo>` you can write `number | string | Foo`. These are also built in and very ergonomic, so you don't have to write a OneOf4 class whenever you want to have one of 4 things, and you don't have to write helper methods to convert between different sized OneOfs.

Don't know about the other two, but the first one is available in java 10 and later.

Worked on a project with an old (12+ years?) - but still being developed/used - Java system. Just last year a move was made up to Java 11 (from 8). Decent test coverage, but moving multiple systems is still a big task, but... they did it. Java 11. Yay.

But... teammates were running in to issues with 'new' stuff - like, using 'var'. There were others, but this was sort of the archetypal argument. "Well, it doesn't match the rest of the style of the file/app - it'll make it hard to read". Well... hrm... any new feature literally doesn't match the style of what came before it, because you have new keywords/features/syntax to handle processes a new way. It's definitional. But just because there's a new feature doesn't mean it'll be adopted (for better or worse, I supposed, depending on your stance).

Java-the-language/JVM has picked up pace hugely in the last few years, but Java-the-ecosystem tends to lag quite severely. Not least because these systems tend to be entrenched systems that move quite a lot of money around... or are highly business critical in some other way. This leads to extreme conservatism wrt. upgrades, etc.

(That part has also gotten better, but especially the Java 8 -> anything later upgrade has been extremely painful because of modularization. Past Java 9 it usually isn't that much of an issue. However, JDK 11 was the first LTS release after 8, so most shops basically delayed the transition until JDK 11.)

This BS made me want to tear my hair out:

    VerboseTypeName foo = new VerboseTypeName();

The reading or the writing part? The reading is easier with explicit types. The writing is a non issue considering tooling auto completes the second instance almost always. modifying later can be cumbersome but the tooling makes it somewhat easier too.

Both, and not interested in tooling to help me repeat things. :-)

This, and usually Java from 10-15 years ago before the `var` keyword and diamond operator.

I definitely fell in this camp. To be fair I was fairly junior and was used to JS.

It wasn't until I started using Haskell that I saw the benefits of knowing exactly what I was working with. It also helped me be more deliberate and thoughtful as you had to define everything up front.

Strong typing can be both needlessly verbose and useful, or the total opposite. My experience with java compared to Typescript, is that the tools largely compensate for Java's verbosity, while that is less true of TS or JS. For example, generating strongly typed method definitions from field declarations.

> red flag is a bad description, because he ended up being self-reflective and looking deeper

No, red flag is fair since it's just a warning sign. Even if we take it as a mark on the guy, it's true that he ought to get outside the scripty bubble.

I built websites and wrote JavaScript for a long time before discovering generics by returning to school and being forced to build data structures from scratch in java. Other than that, there's no way I'd have ever come across them. I was just turned down from a senior position because someone had more years of React experience, so we're not exactly in the most sophisticated hierarchy here. Seniority should probably not depend on your exposure to technical language mechanics, especially those that weren't related to your area of expertise.

The author actively describes themselves as being "Anti-Typescript" and "hating" something they have no experience with. That's not skepticism.

Being skeptical shouldn't mean being ignorant. Being skeptical should mean Trying to understand the pros and cons and believing it's not worth it.

Or alternatively waiting it out a bit until it's more obvious what the pros and cons are (because others have tried it out in depth and shared their experience). Still a far cry from actively dismissing it.

Also more efficient. There's an endless, constant supply of new things not yet worth fully exploring.

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

Typescript is hardly "new", it's fairly widely accepted now. It might be worth thinking "why do all these people enjoy using Typescript?".

or idk just say that no, its the kids that are wrong.

All the kids enjoyed using Javascript too. Language popularity is a bit of a random walk.

I mean, Coffeescript was fairly widely used at its peak, and now it's all but dead.

Front-end fads are fickle. At least TypeScript has Microsoft backing it so they'll likely continue to support even if the rest of the webdev world moves on to the next shiny object.

I don't think I've ever heard of any in-production, large apps in Coffeescript, even from when it was at its peak. I know of a handful of companies that tried it and even enjoyed it quite a bit but none of it was for mass consumption.

Typescript, meanwhile, is used for hugely popular apps, is used by very large companies, has Microsoft's full backing, etc.

The two are not comparable.

Edit: Clearly I'm misremembering its popularity.

At one time, Dropbox and Github were all-in on Coffeescript e.g. https://web.archive.org/web/20130815075924/https://github.co...

Wasn’t CoffeeScript the preferred way to write JS in Ruby on Rails for years?

I think the Rails resource generators still default to creating Coffeescript files. I could be wrong though — I switch between Rails 4,5 and 6 projects right now. I’ve been on over a dozen Rails projects at different companies and only ever worked one project that used Coffeescript in production, and that was an app built pre-2010.

HAML and coffeescript.

I miss the elegance of Haml. Moving from an indented syntax for DOM literals to the likes of JSX felt like a step backwards.

Maybe for you, but that is not a popular opinion. JSX's rigor is a breath of fresh air in a world that constantly generates low quality html due to loose constraints. HAML had those same problems.

JSX is kind of xml done "right". Differences between children and attributes in xml is very hard to grasp, but JSX has a much better defined structure to it and is super well suited to generate html because of that.

This sounds like an orthogonal point. (I agree with it, so it feels odd to see it presented as a rebuttal.) Surely an indented syntax could have rigor if we wanted it to?

Sure, if we wanted it to, but HAML wasn't that.

Yes.

A significant portion of Airbnb was written in Coffeescript, including most of the complex app-like stuff used by hosts to manage listings and calendars.

We ported off of Coffeescript when ES6 and Babel came out, and you could start writing `class` and using `() => {...}` function expressions with lexical `this` scoping.

Coffeescript lost because it stood still next to the ecosystem and next to the new Ecmascript language standards, which obliviated its advantages. The only advantage Coffeescript had over ES6 was “some of your code is already written in it”.

Once Ecmascript formalizes a type system, we’ll see the same process happen with Typescript. But, I think it will be many years before that sort of feature is standardized. In the mean time, I’m happy to use Typescript today.

PagerDuty’s front end was 100% coffeescript until at least 2016

Square's entire merchant dashboard was in CoffeeScript. Half a million lines of code.

Took over a year to convert to ES6.

I also have fond memories of painstakingly converting hundreds of coffeescript files back to JS. There's something to be said for using the native language.

Browser support and consistency got a lot better.

JavaScript was a minefield of compatibility problems. Many intentional, cough: Microsoft.

Jquery was awesome because it dealt with most of that

JQuery dealt with DOM and browser stuff. Coffeescript dealt with syntactic language stuff. I can't think of a case where Coffeescript helps with the same thing JQuery does, although it may exist.

Yeah as best I can tell, Coffeescript was a thing because Ruby was very popular at the time, and some Ruby devs had to write JS but they wanted to write Ruby.

I think everyone except JS devs wishes they could write something other than JS for the browser.

Maybe eventually with WebAssembly...

That was definitely the case before ES2015. I think many of the non-JS devs that still hugely wish they could write something other than JS for the browser haven't kept up with ES2015+ nor Typescript. ES2015 is a much improved language and vanilla JS isn't painful anymore, especially with type="module" support now green enough in caniuse statistics that we can finally kill AMD and CommonJS for good in greenfield vanilla JS projects. The sky is quite sunny and ES2015+ is a better language than a lot of non-JS devs think JS is.

It will still be a while before all the brownfields in the larger ecosystem get cleaned up (if some of them ever do), but that's no longer a language problem, that's a a long tail ecosystem problem.

Yup. I don't find myself using classes much, but some of the other new features remove the vast number of issues you tend to face.

Is scoping an issue for you? Just use arrow functions!

Is callback nesting an issue for you? Just use `async/await`!

I love it so much.

I use classes a fair amount, but there's still some weird stuff in the language I'd take out if I could.

Sparse arrays, all object keys are strings (or symbols), crazy coercion rules, the existence of `null`, weird float vs int rules.

You can use `Map` instead of object which allows keys of any type, or typecheck your objects with `Record<K, V>` and let typescript warn you about any weirdness. Typescript can also warn you if you do some weird implicit coercion. You can typeguard against `null` (although I admit it is annoying, I just want to use an optional†). And if you really want to use integer types there is always `BigInt`.

---

†: I haven’t checked, but I bet there are some libraries out there that provide proper optionals using Proxy.

I use BigInt often, but you can't (for example) do most substring operations with it, even though floating point indexes make no sense.

Map goes part of the way to what I want. But I really want to control which objects are considered equivalent keys, rather than being limited to reference equality.

There's a Stage 2 proposal before TC-39 to add immutable Record and Tuple types [1] which would be structurally compared and perfect for complex Map keys.

It's also easy enough to find or write quick simple Map wrappers that use a hash function on an object as keys when provided (either piggy-backing on the existing Object.prototype.valueOf, which always exists on every object and easily falls back to the reference-based current behavior, and expecting classes to have custom overrides for that, or using a Symbol named function of their own to avoid polluting own-property-keys/name clashes with other libraries).

[1] https://github.com/tc39/proposal-record-tuple

Scala.js actually works really well. Frontend people aren't very aware of it, but if you're a backend dev who just needs to write a bit of code that has to run in the browser then I highly recommend it.

Even as an engineer happiest in Scala almost forced to write Typescript, I'll be the first to admit that the Scala.js library is still a bit lacking in comparison for real world productivity.

I had exactly the opposite experience. I kept trying to make Typescript work and it just wouldn't, eventually resorted to Scala.js and found (to my shock) that everything just worked and there were far less random rough edges.

That’s great :) Scala.js has such potential. I hope that my next opportunity to try it out (versus TypeScript) will be a similar experience to yours!

I was never a fan of the Rubyisms in Coffeescript. But it's sad nothing else ever implemented the YAMLisms.

Typing up constants in Babel JS is so much uglier than it needs to be.

But Coffeescript also introduced things like arrow functions that bind `this` to JS. Transpiling to ES5 allowed JS to evolve.

In my private projects I always write in JavaScript and provide static typing using JSDoc comments (which typescript can check). Then I run the type checker with `--noEmit`. I have yet to run into a problem with this approach.

Coffeescript was a good thing when we only had ES5. In fact many of the things it championed made it into ES6 and beyond. I think with TypeScript it isn't just a shiny thing. If it does substantially change I believe it will be to break the forced compat with JS. As WebAssembly gets more adopted it will be possible to not have JS targets, and thus remove a lot of the weird JS things that have been kept for compatibility. Typescript has the gravity to continue.

CoffeeScript served a purpose, and was not a fad. It got deprecated by an ECMAScript that adapted most of the good parts.

TypeScript brought something good for the JS ecosystem (although Flow did it too, in a different way) and it doesn't look like anything will be able to replace it at what it does anytime soon.

I am really hoping TC-39 starts considering optional static types (similar to python), using a simpler syntax then TypeScript (e.g. no enums). However I don’t have high hopes they will any time soon.

Typescript is not accepted. How AngularJS stuck on 1.* is the best proof, and an illustration for the problem. Pretty serious people are working in Angular community, it's immensely popular in the enterprise webapp space, so I will not take the "Ah, it's just amateurs who are stuck there."

It adds to countless attempts of other transpiled *scripts to extend Javascript.

They, and Coffeescript in particular, are good historical references to what will happen to TS in a few years.

I don't recall most major projects shipping with support for Coffeescript. Looking at my projects, the amount of "@types/*" I have are pretty small compared to a year or two ago because most projects ship types directly in their package now. Personally, I think it's here to stay.

About 95% of React components I see in the wild are in TypeScript. The most rapidly growing JS backend framework (Nest) is in TS. Deno, the evolution of Node, is based on TS. Pretty much everything in the JavaScript OSS world has TS options or is based on TS.

I doubt Coffeescript ever saw this scale of adoption.

We only use TypeScript on frameworks that make it a requirement, the language is starting to look like Haskell.

As much as I like Anders work, it is impossible to understand modern TypeScript without looking into tsconfig.json before looking into source code.

I don't understand what the tsconfig has to do with understanding the source? Maybe when using different path resolving or different tsconfigs to compile test files vs. production files?

Many toolings make it so you don't even need to worry about the tsconfig anymore (though in reality it is very helpful to understand it).

To avoid breaking existing source bases, many features or corrections across the language versions are opt-in, so in some projects it looks like GHC feature pragmas.

This does not align with my experience of writing Typescript at multiple companies of varying sizes and open source projects.

Lucky you for not having devs that would rather be using Haskell Lens and stuff like that.

Looking at GitHub statistics, I would dare say TypeScript is pretty accepted: https://madnight.github.io/githut/#/pull_requests/2020/4

Out of all pull requests on GitHub in Q4/2020, 18.8% were JavaScript and 6.7% were TypeScript.

For reference CoffeeScript was at 0.25%. At its peak in 2014 it was at around 1.5%, when plain JavaScript was at over 20%.

I wrote AngularJS 1.x in TypeScript in an enterprise application. Being "stuck there" ("there" meaning pure JS for Angular 1.x) is a choice.

I'll second that. We used AngularJS 1.x with TypeScript in an enterprise application.

I took over a legacy AngularJS 1.x MEAN app early last year. One of the first things I did was to convert it from using Gulp to building the client with Create-React-App's build tooling:

https://blog.isquaredsoftware.com/2020/03/codebase-conversio...

That unlocked the ability to add React and TypeScript code embedded directly in the existing AngularJS UI, using the `react2angular` library, as a short-term migration approach. I was also able to migrate some of our existing AngularJS controllers and client logic to TS to get a bit more safety.

Since then, I've set up a new Next.js subproject that sits behind the existing Express app server, and was able to show content from Next by inserting iframes into the AngularJS templates and proxying those URLs from the Express app to the Next app. That's let us build new features from scratch inside of the Next codebase while showing them seamlessly in the AngularJS UI, giving us a long-term migration path.

I'd really like to hear what alternatives you have in mind for code in the JavaScript family that needs to have types. At my workplace, types are an important part of our workflow.

We've been using Flow as a type checker but are converting our code to TypeScript for the tooling, ecosystem, support, and hopefully improved performance.

TS has been running as a project for quite a while and a whole lot of folks have a stake in it. I think it's a pretty good bet.

Additionally, I was there when Angular 2 was announced, and the community had no idea what to do or when it was coming out and didn't know whether to dig their heels in and stay on 1 or what the migration path to 2 would look like. I think that's a slightly different story given the context.

> Coffeescript in particular, are good historical references to what will happen to TS in a few years.

The thing is that many good ideas of Coffee ended up being integrated in newer versions of JS, so of course the need for it decreased; one could argue that Coffee's legacy lives in ES201x.

But there are no types in JS, and none planned.

Yeah, it would be great if TC39 made type hints syntactically valid but semantically ignored (ala Python's PEPs to that effect) so that type erasure was no longer needed as a "build step", but so far TC39 is still hugely aware of the controversies surrounding ES4 (the "lost" version of JS) and still very hesitant to do anything type related in JS.

I myself am quite fond of it actually! I was initially suspicious of Node at first and of TS as well, but like the author, I eventually gave it a try and liked it a lot. (Probably after many of the pain points had been worked out!)

That's my personal heuristic and why I continue to reject TS just like I avoided coffee script, flow, clojurescript, and so on.

But this article reads like "Developer who only used dynamic typing learns about static types." You could sub in any two such languages and get the same article.

One of the things you listed is not like the others. Why didn't you give Clojurescript a chance. It's like being in Hell and then someone brings you infinite amounts of cold fiji water. Hell becomes more bearable ;)

Clojurescript is the worst offender on that list from the point of view of "needlessly complicated." I can't imagine a dependency I want less than the Google Closure tools. I swear Closure is probably the only tool with fewer devs who understand it than autoconf.

I'm not critiquing any of those languages, in a perfect world any of them in the browser would have been preferable to Javascript. The issue is the tower of dependancies we are building, and you have to stop somewhere.

With advanced optimisiation turned on, the Clojurescript compiler will not include any of the Closure code that you do not use. But my point was about language superiority. For me it's obvious why Clojurescript wins the client side.

My issues is not the runtime dependency but the development dependancy. As the production apps I am responsible for keep getting older and older my opinions on ruthlessly cutting decencies get stronger and stronger.

Somewhere there's probably an optimal expected lifespan of a program where the line between preferring a better language and fewer development dependencies is crossed, but I'm also starting to learn that software stays around years longer than I ever anticipated.

Heuristics shouldn‘t really be a factor when you are a senior. Make a decision based on your competence and experience.

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.

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.

> Senior probably means they've been doing JS for decades before TS was invented.

JS has only been around for 25 years. I’m a “Senior person” and I’ve been seriously working with JS for less than 5 years.

Well, I'm Senior too and I've been working with JS for 23-24 years. So I guess I'm projecting my own experience.

I cannot wait to be the type of developer who just never makes typos.

Your IDE should be catching any typos. But it's not about typos, it's about understanding the quirky nature of JS and knowing what things not to do. For instance, an inexperienced developer might try to use .sort() to sort an array of numbers. It wouldn't even occur to an experienced developer to try that since they know from vast past experience that it won't work (or, at least, won't do what the inexperience developer is thinking it might do).

Does does my IDE know what functions should be called without types?

Why not use something if you have an added benefit? It‘s like writing code in „ed“ just because it worked for decades

I've been programming JS for 13 years (professionally, and some more as a hobby) and I'm pretty aware of its warts. And as a firm believer of TDD, most of my code is pretty well tested.

Unit tests have similar advantages to types: they catch errors early and let you refactor your code with confidence.

But unit tests go even further, because they test the _correctness_ of the returned value, not just its type.

And a massive turnoff for me is that the types are compile-time only.

So you see, if your code is tested, and the types are just partial static checks; I feel like it's just not worth it.

I enjoy using types in other languages, for example it feels nice to add type hinting to old PHP codebases. But in PHP, types are much simpler (less work) and more effective.

If they added optional run-time instrumentation like "spec" in Clojure, I would definitely use TS. But for now, I'm out.

You should be testing regardless of the strength of your type system.

But testing with a weak type system isn't going to give you anywhere near the guarantees you'd get from a well-designed type system in addition to testing: https://kevinmahoney.co.uk/articles/tests-vs-types/

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.

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".

Sure, like all systems, there are overhead costs involved. But with something like a typed system, the overhead costs are minimal compared to the benefits you reap from them.

One of the projects I worked on during my transition to typescript was to convert an existing project into it. Sure there was a lot of head banging against walls at some point to get the types to work out, but during that process I finally really understood how everything fit together and gained a sense of assurance that I could use a return of a function with complete confidence. Developing on that project afterwards was also a breeze, moving faster and more confidently knowing that the object types were set, and that guardrails were in place to prevent myself from shooting my own foot.

It's a new system to work within the guidelines of, but guardrails are there for a reason, to prevent you from falling off a cliff.

You are either going to catch the bugs in the type checker or you are going to have to write unit tests to catch them.

For me, typed python saves me a bunch of time.

Typed python takes ages to validate, and Python is much slower to run than Node.js, even with hacks like uvloop.

I've barked up that tree so many times, I don't think I'll ever go back to Python for that stuff in the future.

The problem is, Javascript was never meant to be typed. It was never meant for what we use it for, even. When you start adding guard-rails to a language that already has guard-rails, what are you left with?

We spent more time screwing around with our Typescript types, getting the compiler to be happy, working around bugs with type assertions, etc. than we did focusing on the app logic at some points.

This kind of stuff, to compare, never really happens with C++. The type system is simple enough (compared to TS) that you can pretty confidently fix type errors quickly. I don't like Rust, but I know that the same occurs with Rust's type errors, too. Why is TS so difficult?

Because Microsoft created a type system that is so complex it can represent (almost) any type in a dynamically typed language. It's impressive, but not at all practical.

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.

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.

I understand the sentiment, but a better comparison would be if your tool of choice had to be shared between everyone on your team.

Would that imply that the GP needs to reconsider their willingness to use TypeScript, or is it just a friendly reminder that there is utility in finding teams with shared values?

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 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.

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

I am a TypeScript fan but I do acknowledge the existence of the tax. TS is another cog in the machine that does useful work but can sometimes confusingly interact with other cogs (e.g. miles long unreadable TS errors coming out of React). Using or not using TS is not a trivial decision to me and should be made with consideration to the complexity of your stack.

I don't believe whether or not using TS has to do with the rest of your stack, but more about data consistency and the like.

I for one am building a large CRUD application with dozens of models spanning hundreds of fields, and Typescript is helping me (though not a panacea) keeping things correct.

I'm comparing it to a project I did years ago, first Backbone, then Angular, but both before 'typesave JS' was a thing, and that one relied heavily on reading and comparing keys and a deep knowledge of the domain.

But nearly ten years later, I don't have the mental capacity for that anymore and I need the crutches that typed languages offer me. By crutches I mean securities, safeguards and IDE assistance.

It makes sense for anything nontrivial IMO. Types allow you to be able to free up mental space. You can trust the type checker instead of having to rely on your own abilities.

Can relate about illegible React stack traces in production builds. One of the reasons in my case was Create-React-App obfuscating ES6 class names, which is just insane! Just why???! Why throw all code structure away just to save a couple KBs. The worst part is CRA folks acting like dictators when asked to provide an option to toggle that: "Why in heavens earth would you need that?". "You can fork our 30K+ line repo [just to toggle minification] if you want".

Sorry for the off topic rant!

P.S: Yes I know source maps exist. They suck/aren't reliable.

You could also use customize-cra and skip on minifications in about 10 lines of code

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.

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.

My senior moment came when we were talking about graphics and I mentioned some various things and CGA. My coworkers let me ramble a bit and then one politely asked what CGA was.

Yes, type checking do not require a new language.

Reply on news.ycombinator.com